HCI and accessibility
Introduced
Vocabulary
| English | Meaning |
|---|---|
| states/steɪts/ | The possible configurations or conditions of a system at a particular point in its operation. |
| transitions/trænˈsɪʃnz/ | Changes from one state to another in response to events or actions. |
Design in states
- The borrow flow has five states (browsing, detail, confirm, done, error) and labelled transitions. Every reachable state needs a visible way out — the error state keeps the member's input and returns to detail.
{exercise:uni-cs1203-states}
Practice
Every reachable interface state needs —
Difficulty 1/5 · 100 coins + a small bonus on first completion today
No exit = a trap; the error state returns to detail with input kept.
Accessibility as mechanics
- WCAG's core: perceivable (contrast $\ge 4.5{:}1$ for text), operable (keyboard reachable, focus visible), understandable (labels, not placeholders), robust (semantics).
- The course prototype measured: body text 7:1 passes; the grey disabled button at 2.9:1 fails — replaced by 4.6:1 with an underline affordance. Accessibility is measurable or it is decoration.
{exercise:uni-cs1203-contrast}
Practice
Text contrast must be at least —
Difficulty 1/5 · 100 coins + a small bonus on first completion today
WCAG AA: 4.5:1 for body text; 7:1 comfortably passes.
The keyboard path
- A member completes a borrow with tab and enter only: focus order matches visual order, focus is visible on every control, confirm is announced. Hover-only menus fail this path — the test finds them before users do.
- Error states that discard input and placeholder-as-label are the recurring defects.
{exercise:uni-cs1203-keyboard}
Practice
The keyboard path fails when —
Difficulty 1/5 · 100 coins + a small bonus on first completion today
Hover-only affordances are unreachable by tab.