Accessible UI Design: WCAG 2.2 and Usability Testing

Introduction

This is lesson 3 of chapter 7, aligned with course 7 of the Meta Front-End Developer pathway ("Principles of UX/UI Design", domain ux-ui). You have researched users and given a page structure and hierarchy. Two questions remain before a design is ready for the capstone: can everyone use it, and how do we know it works?

Accessibility means that people with a wide range of abilities, devices, and situations can perceive, operate, and understand your interface. It covers permanent disabilities (blindness, deafness, limited mobility), temporary ones (a broken arm), and situational ones (bright sunlight, a noisy train, one hand holding a child). Usability evaluation is the practice of checking, with people or with a set of principles, whether a design supports its tasks. Consider both during design and implementation: early review can avoid rework, while many barriers can only be assessed in a working interface.

The original scenario uses the fictional Harbor Workshops booking flow. All participant counts, observations, scores, and quotations below are simulated teaching fixtures. The examples describe checks a project team should perform; they do not report tests conducted on a live product.

Learning objectives

By the end of this lesson you can:

1. Explain the four WCAG principles (POUR) and the A, AA, AAA conformance levels.
2. Apply contrast, text size, focus, target size, and non-color cues in a design.
3. Describe how accessible design decisions map to semantic HTML and ARIA.
4. Review a design using Nielsen's usability heuristics.
5. Plan and run a small moderated usability test with task scenarios.
6. Record issues with severity and turn them into prioritized fixes.
7. Use simple metrics, such as task success and the System Usability Scale.

1. Accessibility fundamentals: POUR

The Web Content Accessibility Guidelines (WCAG), published by the W3C, organize requirements under four principles, remembered as POUR:

WCAG success criteria have three conformance levels: A, AA, and AAA. AA conformance requires all applicable A and AA criteria, including complete pages and processes, not just the checks in this lesson. We use WCAG 2.2, which adds nine criteria to 2.1 and removes 4.1.1 Parsing. A quick design review is not a conformance audit. Accessibility focuses on disabled people's access; temporary and situational constraints can benefit from the same design decisions without being identical to disability.

2. Accessible visual design

Contrast

Text must be distinguishable from its background. WCAG measures a contrast ratio from 1:1 (no difference) to 21:1 (black on white).

Check actual foreground/background combinations with a contrast checker or developer tools. An input border need not itself meet 3:1 if it is not needed to identify the control; meaningful state and focus cues still require review. Inactive controls and unmodified browser-controlled appearances have exceptions. Placeholder text in an enabled field is not exempt merely because it is secondary.

Do not rely on color alone

Users may not perceive a color difference because of color vision, contrast, display conditions, or other factors. Do not encode an error only with a red border: identify the error in text and associate it with the field. A decorative icon can reinforce that message.

<label for="email">Email</label>
<input id="email" type="email" aria-invalid="true" aria-describedby="email-error">
<p id="email-error" class="error">
  <svg aria-hidden="true" width="16" height="16"><!-- icon --></svg>
  Error: enter an email address such as name@example.org.
</p>

The same applies to links inside text (underline them or give another cue besides color), to charts (labels or patterns), and to required fields (a text marker, not just a red asterisk).

Text and zoom

• Use relative units so text scales with user settings.
• Check text resizing to 200% without losing content or functionality (1.4.4, with exceptions such as captions and images of text).
• For vertically scrolling content, check reflow at 320 CSS pixels wide, equivalent to a 1280 CSS pixel viewport at 400% zoom (1.4.10). Parts whose meaning requires a two-dimensional layout have exceptions. Responsive CSS helps but does not guarantee conformance.
• Check user text-spacing overrides without clipping: line height 1.5 times font size, paragraph spacing 2 times, letter spacing 0.12 times, and word spacing 0.16 times (1.4.12, where those properties apply). These are override checks, not mandatory default styles.
• Do not disable zoom with user-scalable=no in the viewport meta tag.
• Avoid images of text.

Motion and timing

For automatically starting movement shown alongside other content for more than five seconds, provide pause, stop, or hide unless essential (2.2.2); automatically updating information has a related control requirement without that five-second condition. Avoid flashing; 2.3.1 specifies a three-flash or flash-threshold limit. Respect reduced-motion preferences as well, for example by removing nonessential decorative motion:

@media (prefers-reduced-motion: reduce) {
  .decorative-animation { animation: none; transition: none; }
  html { scroll-behavior: auto; }
}

Scope this rule to your actual decorative effects and remove unnecessary motion in scripts too. Do not make completion depend on an animation ending. Reduced-motion CSS alone does not implement pause controls or adjustable time limits.

3. Operable: keyboard, focus, and targets

Many users never touch a mouse: people who use screen readers, switch devices, voice control, or a keyboard because of a motor impairment, and also power users.

• Everything interactive must work from the keyboard (Tab, Shift+Tab, Enter, Space, arrow keys where appropriate).
• Logical focus order follows the visual and reading order. Do not use positive tabindex values; use native order.
• Visible focus. Never remove the outline without replacing it with an equally clear style. Use :focus-visible.
• Skip link. Offer "Skip to main content" as the first focusable element on pages with long headers.
• No keyboard traps. A modal keeps keyboard focus inside while open, but users must be able to close it, usually with Escape and a visible close control. Set initial focus appropriately and restore it to the trigger or another logical location after closure.

:focus-visible { outline: 3px solid #1a56db; outline-offset: 2px; }

WCAG 2.2 additions that affect design

Criterion 2.5.8 is 24 by 24 CSS pixels in both dimensions, with spacing, equivalent-control, inline, user-agent, and essential exceptions. A 44 by 44 project target can improve usability; AAA criterion 2.5.5 uses that larger size with its own exceptions. Neither height alone nor a physical screen-pixel count determines compliance.

4. Perceivable and robust: semantics first

The most effective accessibility technique for developers is writing correct HTML. Native elements supply built-in semantics and keyboard behavior, but authors must still provide meaningful labels, content, and appropriate states.

ARIA (Accessible Rich Internet Applications) attributes add semantics when native HTML cannot. The first rule of ARIA is: do not use ARIA if a native element does the job, ARIA roles and states communicate semantics; they do not implement a custom widget's keyboard behavior. That behavior remains the developer's responsibility.

The following JSX fragments assume a component already supplies open, setOpen, message, and error. Keep live-region containers mounted before their messages change, and use assertive alerts only for information that needs immediate attention:

<button type="button" aria-expanded={open} aria-controls="filters" onClick={() => setOpen(!open)}>
  Filters
</button>
<div id="filters" hidden={!open}>…</div>

<p role="status">{message}</p>              {/* polite live region for results */}
<p role="alert">{error}</p>                 {/* assertive for errors */}
<button type="button" aria-label="Close dialog">×</button> {/* name for icon-only control */}

Test by operating the page with the keyboard, then with a screen reader (NVDA or Narrator on Windows, VoiceOver on Mac and iOS, TalkBack on Android). Automated tools such as Lighthouse or axe cannot decide every criterion or whether a task is usable. Combine automated findings, manual inspection, and user research; a clean scan cannot establish WCAG conformance. Revisit semantic forms and accessible error messages before coding the booking flow.

Use React Testing Library and user-facing component tests to check labels and interactions as the prototype becomes code. Component assertions complement manual keyboard, assistive technology, and user checks.

5. Usability heuristics

A heuristic evaluation is an expert review of an interface against recognized principles. It is fast and needs no participants, so it suits early prototypes. Jakob Nielsen's ten usability heuristics offer one established set:

For each problem found, record the heuristic, the location, a description, and a severity (for example 0 = not a problem, 1 = cosmetic, 2 = minor, 3 = major, 4 = catastrophe).

6. Usability testing

A usability test watches real users attempt realistic tasks. Unlike opinion surveys, it reveals actual behavior. Small iterative rounds can uncover actionable problems, but no fixed number guarantees that most issues will be found. Choose recruitment and sample size for the tasks, audience differences, risks, and the kind of claim you intend to make.

Plan

1. Goals: what you want to learn ("Can first-time users complete a booking without help?").
2. Participants: recruit relevant users with varied needs, including disabled participants and assistive technology contexts relevant to the service. One participant does not represent a whole disability group. Let participants use familiar equipment when possible and document gaps in coverage.
3. Tasks: scenarios, not instructions. Give a goal and context without naming interface labels.
4. Setup: a prototype or the coded page, a quiet place or video call, consent for recording, and a script.
5. Roles: a facilitator who speaks, and an observer who takes notes.

Weak task: "Click Workshops, choose Pottery, and press Reserve." (It tells the path.) Better: "You want to take your daughter to a pottery class this Saturday. See whether you can book two places."

During the session

• Welcome the participant and say you are testing the design, not them.
• Ask them to think aloud.
• Avoid leading them when they hesitate. Agree stopping and assistance rules beforehand, and offer breaks or stop a task if needed. Record any help you provide so assisted completion is not counted as unassisted success.
• Record: success or failure, time, errors, and quotes.
• After the tasks, administer an optional standard questionnaire before the debrief, then ask open follow-up questions.

Metrics

Analyze and act

Cluster the issues, rate severity, and prioritize by frequency and impact, as you did with research findings. Write a short report: what worked, what failed, evidence (quotes, counts), and recommended fixes. Then fix and retest using comparable tasks and completion rules. Report counts such as 4 of 5 alongside percentages, and distinguish independent, assisted, and failed attempts. Think-aloud and facilitator help affect timing; a small moderated round is not a reliable population success-rate estimate.

SUS responses use a 1–5 scale. For the standard questionnaire, subtract 1 from each odd-numbered response and subtract each even-numbered response from 5. Sum those ten contributions and multiply by 2.5. An adjusted total of 30 gives 75, a scale score rather than a percentage or accessibility pass mark. Use the complete standard instrument after participants have tried the system; altered wording or tiny samples need cautious interpretation.

Worked example: reviewing a booking form

Problem. The prototype's booking form has a placeholder-only "Full name" field in light gray text (#999 on white), a red-border-only error state, a "Pay" button with a 28 by 28 CSS pixel target next to a "Cancel" button of identical style, a sticky bottom banner "Free parking!" that covers the focused field on small screens, and a mandatory transcription CAPTCHA at login with no assistance or alternative path. List the issues with criteria and fixes.

Reasoning, step by step.

1. Contrast: #999 on white is about 2.8:1, below 4.5:1 for normal text (1.4.3). Fix: use a darker gray, for example #595959 (approximately 7:1).
2. Labels: placeholder text disappears while typing and is not a reliable label (3.3.2 Labels or Instructions, 1.3.1). Fix: add a visible <label>.
3. Color alone for errors (1.4.1). Fix: add error text and an icon, and link it with aria-describedby.
4. Primary and secondary actions look identical (heuristic 4, hierarchy). Fix: filled "Pay"; text or outline "Cancel" with a confirmation if data would be lost (heuristics 3 and 5).
5. Target size: the supplied 28 by 28 CSS pixel target meets the AA size threshold, but falls below this project's 44 by 44 goal. Increase both dimensions; a height measurement alone would be insufficient.
6. Focus obscured: if the banner entirely hides a keyboard-focused component, it fails 2.4.11; partial obstruction also deserves repair. Remove or reposition the banner, or provide reliable scrolling clearance. scroll-padding-bottom can help in a suitable scrolling layout, but actual focus visibility must be checked.
7. Mandatory transcription CAPTCHA without assistance or an alternative fails 3.3.8. Offer a usable authentication route without that test, such as an appropriately implemented passkey or email-link flow. Allowing password paste does not fix a separate mandatory CAPTCHA; every authentication step needs review.

Solution. Seven review observations with proposed fixes; the 28 by 28 target is an improvement opportunity, not an AA target-size failure. Severity: the CAPTCHA (blocks some users entirely) and the obscured focus are major; contrast and label are major for low-vision users; the button style is minor.

Why other approaches are weaker.

• Running only an automated scanner can reveal some contrast and naming problems, but cannot reliably resolve the entire task flow, authentication alternatives, focus obstruction, or action hierarchy.
• Adding aria-label to everything does not fix visible placeholders or contrast, and may create names that differ from visible text.
• Waiting until after launch means fixing issues in production code and risking exclusion of real customers.

Common pitfalls and study tips

• "Accessibility is for a few people." Captions, contrast, and keyboard support also help many others.
• Removing outlines for looks. Always replace focus styles.
• div buttons. They lack keyboard support, role, and name unless you rebuild everything.
• Overusing ARIA. Wrong ARIA is worse than none.
• Testing with colleagues only. They share your assumptions.
• Leading tasks. Telling users where to click wastes the test.
• Counting opinions as evidence. Observed behavior outweighs "I liked it".
• Study tip: recognize POUR categories; remember 4.5:1 and 3:1 contrast thresholds; know that AA is the common target; distinguish a heuristic evaluation (experts, no users) from a usability test (real users, tasks).

Mini case study: the library renewal page

A library's renewal page has a calendar widget that works only by dragging a slider to choose the return date, light blue links without underline in body text, an unlabeled magnifier icon button, and an error message that turns a field red and shows nothing else. Five test participants attempt "renew two books for three weeks". Two fail, one uses a screen reader and cannot find the search button.

Tasks. Propose four fixes, each tied to a principle or criterion, and say how you would verify the result.

Commented solution.

1. Provide a non-drag alternative (2.5.7): a date input or labelled step buttons. Verify operation with clicks/taps without dragging, then separately check keyboard operation (2.1.1).
2. Underline links and check contrast (1.4.1, 1.4.3): confirm 4.5:1 and a non-color cue. Verify: contrast checker.
3. Name the icon button with visible text or aria-label="Search" (4.1.2 Name, Role, Value). Verify: screen reader announces "Search, button".
4. Add error text and association (1.4.1, 3.3.1 Error Identification). Verify: trigger the error and listen with a screen reader; then run another suitable round. Compare observed barriers and completion counts with the simulated baseline of 3 of 5, without claiming a statistically established improvement from such small samples.

Key terms

• WCAG: Web Content Accessibility Guidelines from the W3C.
• POUR: Perceivable, Operable, Understandable, Robust.
• Conformance level: A, AA, or AAA.
• Contrast ratio: a measure of luminance difference between two colors.
• ARIA: attributes that add accessibility semantics to elements.
• Screen reader: software that speaks or brailles interface content.
• Heuristic evaluation: expert review against usability principles.
• Usability test: observing users performing tasks.
• Think aloud: participants speak their thoughts while working.
• SUS: System Usability Scale, a ten-item questionnaire about perceived usability; its 0–100 score is not a percentage.

Summary checklist

• I can state the four POUR principles and the three conformance levels.
• I check contrast: 4.5:1 for normal text, 3:1 for large text and UI components.
• I never rely on color alone, and I keep zoom and reduced-motion support.
• I make every control keyboard operable, with visible and unobscured focus.
• I apply WCAG 2.2 ideas: target size, dragging alternatives, redundant entry, accessible authentication.
• I use semantic HTML first and ARIA only when needed.
• I review designs with Nielsen's heuristics and rate severity.
• I run small task-based usability tests and prioritize fixes by evidence.

Sources and further reading

• Meta Front-End Developer Professional Certificate (opens in a new tab)

• Course 7: Principles of UX/UI Design (opens in a new tab)

• W3C: WCAG 2.2 (opens in a new tab)

• W3C WAI: What's new in WCAG 2.2 (opens in a new tab)

• W3C WAI: ARIA Authoring Practices Guide (opens in a new tab)

• MDN: Accessibility (opens in a new tab)

• Nielsen Norman Group: 10 Usability Heuristics (opens in a new tab)

• web.dev: Learn Accessibility (opens in a new tab)

• W3C: Non-text contrast (opens in a new tab)

• W3C: Reflow (opens in a new tab)

• W3C: Text spacing (opens in a new tab)

• W3C: Target Size (Minimum) (opens in a new tab)

• W3C: Accessible Authentication (Minimum) (opens in a new tab)

• GOV.UK Service Manual: Moderated usability testing (opens in a new tab)

• John Brooke: SUS — A quick and dirty usability scale (opens in a new tab)