Accessible Design and Usability Evaluation

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. Both belong in the design stage, because fixing them after the code is written costs far more.

The scenario is original: the Harbor Workshops booking flow, in which a sample prototype is reviewed and tested.

Learning objectives

By the end of this lesson you can:

Explain the four WCAG principles (POUR) and the A, AA, AAA conformance levels.
Apply contrast, text size, focus, target size, and non-color cues in a design.
Describe how accessible design decisions map to semantic HTML and ARIA.
Review a design using Nielsen's usability heuristics.
Plan and run a small moderated usability test with task scenarios.
Record issues with severity and turn them into prioritized fixes.
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:

Principle	Meaning	Example
Perceivable	Information can be presented in ways users can sense	Text alternatives for images, captions for video, sufficient contrast
Operable	Interface components can be used by everyone	Everything works with a keyboard, enough time, no seizure-triggering flashes
Understandable	Content and operation are clear	Predictable navigation, clear labels, helpful error messages
Robust	Content works with current and future assistive technologies	Valid semantic HTML, correct names and roles

WCAG success criteria have three conformance levels: A (minimum), AA (the usual target, and the level referenced by many laws and procurement rules), and AAA (highest, not always achievable for all content). Aim for AA. The current version is WCAG 2.2 (a W3C Recommendation since October 2023). It is built on 2.1 and adds nine criteria, and it removes the obsolete criterion 4.1.1 Parsing.

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).

Item	Minimum ratio (AA)	Criterion
Normal text	4.5:1	1.4.3
Large text (at least 24 px, or 18.66 px bold)	3:1	1.4.3
UI components (input borders, icons that carry meaning) and focus indicators	3:1 against adjacent colors	1.4.11

Check ratios with a contrast checker or the browser's developer tools. Light gray text on white, which often looks elegant, commonly fails.

Do not rely on color alone

About 1 in 12 men and 1 in 200 women have some form of color vision deficiency, and everyone sees poorly in glare. If a field with an error is outlined in red only, many users will not notice. Add text, an icon, or a pattern.

<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.
Content must remain usable when text is resized up to 200%, and without horizontal scrolling when zoomed to 400% at a 1280-pixel-wide viewport (a "reflow" requirement, 1.4.10), which a responsive layout provides.
Do not disable zoom with user-scalable=no in the viewport meta tag.
Avoid images of text.

Motion and timing

Provide a way to pause moving content, avoid flashing more than three times a second, and respect users who ask for reduced motion:

@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after { animation: none !important; transition: none !important; scroll-behavior: auto !important; }
}

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 dialog should keep focus inside while open, then return it to the trigger when closed.

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

WCAG 2.2 additions that affect design

Criterion	Level	What it asks for	Design implication
2.4.11 Focus Not Obscured (Minimum)	AA	A focused element is not completely hidden by author-created content	A sticky header or cookie banner must not cover the focused field
2.5.7 Dragging Movements	AA	Anything done by dragging also has a single-pointer alternative	A drag-to-reorder list needs "Move up/down" buttons
2.5.8 Target Size (Minimum)	AA	Pointer targets at least 24 by 24 CSS pixels, with exceptions (such as inline links in text)	Keep icon buttons big enough or spaced apart
3.2.6 Consistent Help	A	Help options appear in the same place across pages	Keep the contact link in the same spot
3.3.7 Redundant Entry	A	Do not ask users to re-enter information already given in the same process	Prefill billing details from the participant details
3.3.8 Accessible Authentication (Minimum)	AA	No cognitive function test, such as remembering a password or solving a puzzle, without an alternative	Allow password managers and paste; do not block them

Larger touch targets (about 44 by 44 pixels) remain a good practice on mobile even though the AA minimum is 24 pixels.

4. Perceivable and robust: semantics first

The most effective accessibility technique for developers is writing correct HTML. Native elements come with roles, names, keyboard behavior, and states for free.

Need	Use	Avoid
Action	`<button>`	`<div onClick>`
Navigation	`<a href>`	`<span>` with a click handler
Page regions	`<header>`, `<nav>`, `<main>`, `<footer>`	A tree of `<div>` elements
Headings	`<h1>`…`<h6>` in order	Larger text styled to look like a heading
Form fields	`<label for>` + `<input>`	Placeholder as the only label
Lists	`<ul>`, `<ol>`	Line breaks
Images	`alt` text that describes purpose; `alt=""` for decoration	Missing `alt`; "image of…"

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, and the second is that ARIA changes only what assistive technology is told, not behavior, so you must add the keyboard handling yourself.

Useful ARIA in React interfaces:

<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 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 catch only a portion of problems (a common estimate is less than half), so manual checks remain necessary.

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 are the most used set:

#	Heuristic	Harbor Workshops example
1	Visibility of system status	Show "Booking in progress…" and a confirmation
2	Match between system and real world	Say "seats left", not "capacity delta"
3	User control and freedom	Offer Cancel and Back; allow undo
4	Consistency and standards	Same button style and placement across steps
5	Error prevention	Disable Reserve when sold out; confirm destructive actions
6	Recognition rather than recall	Show chosen date and price on the form
7	Flexibility and efficiency of use	Remember details for returning users
8	Aesthetic and minimalist design	Remove nonessential information
9	Help users recognize, diagnose, and recover from errors	"Card expired. Check the date or try another card."
10	Help and documentation	Short FAQ close to the form

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. Studies by the Nielsen Norman Group suggest that small rounds of about five participants uncover most major issues for one user group, and that repeated small rounds beat one large test.

Plan

Goals: what you want to learn ("Can first-time users complete a booking without help?").
Participants: 5 per user group, matching your personas, including at least one assistive technology user where possible.
Tasks: scenarios, not instructions. Give a goal and context without naming interface labels.
Setup: a prototype or the coded page, a quiet place or video call, consent for recording, and a script.
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.
Stay quiet when they struggle; answer a question with "What would you do if I were not here?"
Record: success or failure, time, errors, and quotes.
End with open questions and, optionally, a short questionnaire.

Metrics

Metric	How	Example result
Task success rate	Completed tasks divided by attempted tasks	4 of 5 completed the booking: 80%
Time on task	Seconds to complete	Median 95 seconds
Errors	Wrong clicks, validation errors	7 across all participants
Satisfaction	System Usability Scale (SUS), ten statements scored 0 to 100	Score 74 (SUS average is about 68)

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, retest, and compare.

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 28 pixels tall next to a "Cancel" button of identical style, a sticky bottom banner "Free parking!" that covers the focused field on small screens, and a CAPTCHA that asks users to solve a puzzle to log in. List the issues with criteria and fixes.

Reasoning, step by step.

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 (about 7:1).
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>.
Color alone for errors (1.4.1). Fix: add error text and an icon, and link it with aria-describedby.
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).
Target size: 28 px passes the 24 px minimum of 2.5.8, but is below the 44 px comfort level for thumbs; raise min-height to 44 px.
Focus obscured by the sticky banner (2.4.11). Fix: make the banner non-sticky, dismissible, or add scroll-padding-bottom so the focused field scrolls into view.
Puzzle CAPTCHA is a cognitive test (3.3.8). Fix: use an alternative, such as email link sign-in, a passkey, or a method that allows password managers and copy-paste.

Solution. Seven issues, each with a criterion or heuristic and a specific fix. 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 would find the contrast issue but not the CAPTCHA, the obscured focus, or the unclear button 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 exam 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".
Exam 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.

Provide a non-drag alternative (2.5.7): a date input or +/- buttons. Verify: complete the task with keyboard only.
Underline links and check contrast (1.4.1, 1.4.3): confirm 4.5:1 and a non-color cue. Verify: contrast checker.
Name the icon button with visible text or aria-label="Search" (4.1.2 Name, Role, Value). Verify: screen reader announces "Search, button".
Add error text and association (1.4.1, 3.3.1 Error Identification). Verify: trigger the error and listen with a screen reader; then retest with five participants and compare the success rate to the earlier 3 of 5.

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 satisfaction questionnaire.

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.