Accessibility Manual Checks

Perform manual WCAG 2.1 AA accessibility checks — keyboard navigation, focus-order audit, screen-reader smoke test, form-label verification, and colour-contrast assessment — producing actionable issue reports with remediation guidance.

Role

Manual QA engineer

Difficulty

Intermediate

Time limit

~90 min

Scenario

Your team is preparing to ship a new web feature and has asked you to perform the manual accessibility checks that automated tools cannot cover. An automated axe scan has already been run and its findings have been logged separately. Your task is to perform the remaining WCAG 2.1 AA checks — keyboard navigation, focus order, screen-reader announcement quality, form labelling, and colour contrast — on a publicly accessible web page, document each finding as an actionable accessibility issue report, and produce a summary that tells the team which failures must be fixed before shipping and which are best-practice improvements.

Requirements

1.Perform a complete keyboard-navigation check: Tab through every interactive element (links, buttons, form inputs, dropdowns, and any custom widgets) and verify each is reachable; Shift+Tab must reverse the order; Enter and Space must activate buttons and links; Escape must close modals, dropdowns, and popups; document any element that traps focus, skips focus, or fails to activate
2.Assess the visible focus indicator on at least 5 interactive element types — a missing focus ring or a focus ring with insufficient contrast against its background is a WCAG 2.4.7 (Focus Visible) failure; record the element, whether a focus indicator is visible, and whether its contrast appears adequate
3.Run a screen-reader smoke test and verify: the page title is announced when the page loads; landmark regions (header, nav, main, footer) are present and announced with correct roles; all informative images have appropriate alt text (decorative images have empty alt=''); every form field has an accessible label that is announced when the field receives focus
4.Audit all form fields on the tested page for label compliance: every input must have a visible label element (not just a placeholder); clicking the label must move focus to its associated input; label text must be announced by a screen reader when the field is focused; note any field where the only label is a placeholder attribute
5.Document at least 3 colour-contrast observations by measuring or closely estimating the foreground-to-background contrast ratio for text elements; WCAG 1.4.3 requires 4.5:1 for normal text (< 18pt or < 14pt bold) and 3:1 for large text (≥ 18pt or ≥ 14pt bold); note the hex values and calculated ratio for each observation
6.Write an accessibility issue report for every WCAG 2.1 AA failure found, including: the specific WCAG success criterion number and title, the affected element (with enough description to locate it), the current failing behaviour, the expected behaviour, a concrete remediation suggestion, and severity (High = functional blocker for keyboard/AT users, Medium = significant barrier, Low = best-practice improvement)

Starter data

›Suggested practice targets: gov.uk/check-uk-visa or any gov.uk service page (these are well-implemented and good for learning what correct accessibility looks like); for intentionally inaccessible practice, use a11y.coffee/a11y-failures or WebAIM's intentionally inaccessible page at webaim.org/intro/test (if available)
›Screen-reader quick-start: NVDA on Windows — press Caps Lock+N to silence, use Tab/Shift+Tab to navigate interactive elements, use H to jump between headings, use F to jump between form fields; VoiceOver on macOS — Cmd+F5 to toggle, Ctrl+Opt+→ to move by element
›WCAG success criteria relevant to this exercise: 1.1.1 Non-text Content (alt text); 1.3.1 Info and Relationships (form labels, landmark structure); 1.4.3 Contrast (Minimum) (4.5:1 for normal text); 2.1.1 Keyboard (all functionality via keyboard); 2.4.3 Focus Order (meaningful sequence); 2.4.7 Focus Visible (visible focus indicator); 3.3.2 Labels or Instructions (form labels); 4.1.2 Name, Role, Value (accessible name on controls)
›Common failure patterns: placeholder-only form labels (fail 1.3.1 + 3.3.2); missing alt text on informative images (fail 1.1.1); custom buttons built with <div> or <span> that lack role='button' and tabindex (fail 2.1.1 + 4.1.2); CSS outline: none or outline: 0 on focus without a custom focus indicator (fail 2.4.7); muted grey helper text below inputs that fails contrast (fail 1.4.3)
›Contrast measurement: in Chrome DevTools, open Elements panel → select a text element → in the Styles panel, click the colour swatch → DevTools shows the contrast ratio with a pass/fail indicator; or copy the hex values into webaim.org/resources/contrastchecker/
›Severity guidance: High = a keyboard-only user or screen-reader user cannot complete a core task (login, form submission, navigation); Medium = a significant barrier that degrades the experience but does not block task completion; Low = a best-practice improvement that the WCAG criterion does not strictly require at AA level

Expected deliverables

✓Keyboard navigation check results listing every interactive element type tested, with a pass/fail result and a note on any element that trapped focus, skipped focus, or failed to activate via keyboard
✓Focus indicator assessment for at least 5 interactive element types (visible: yes/no, contrast appears adequate: yes/no/unable to confirm without measurement)
✓Screen-reader smoke test notes specifying: screen reader name and version, browser and version, page title announcement, landmark regions found, any images with missing or inappropriate alt text, and form field label announcements
✓Form label audit for all form fields on the tested page (label present: yes/no, visible: yes/no, clicking label focuses field: yes/no, announced by screen reader: yes/no)
✓Colour-contrast observations for at least 3 text elements (foreground hex, background hex, measured or estimated ratio, WCAG 1.4.3 pass/fail, text size classification)
✓Accessibility issue reports for all WCAG 2.1 AA failures found (criterion number + title, element, current behaviour, expected behaviour, remediation suggestion, severity)

Evaluation rubric

Dimension	What reviewers look for
Keyboard and focus coverage	Are all interactive element types tested, not just standard inputs? Custom widgets (date pickers, carousels, custom dropdowns, modals) are the most common sources of keyboard failures. Is the focus-trap check included — can the user Tab away from every element without becoming trapped? Are the results specific enough to be reproducible (e.g. 'the date picker calendar grid is not reachable via Tab; Tab moves past the date picker to the next field').
Screen-reader check quality	Are screen-reader notes reproducible? The report must name the screen reader, version, and browser pairing — NVDA on Firefox and NVDA on Chrome produce different announcements for the same element. Are findings specific ('Submit button has no accessible name — announced as "button" only') rather than general ('screen reader didn't work right')? Does the check cover all four areas: page title, landmarks, alt text, and form labels?
Correct WCAG framing	Is each failure tied to a specific WCAG 2.1 AA success criterion by number and title? Does the severity reflect the real impact on users of assistive technology — a missing alt on a decorative image is Lower priority than a form field with no label that blocks screen-reader users from submitting the form? A report that says 'this fails accessibility' without citing a criterion number is not an accessibility issue report — it is an opinion.
Actionable remediation suggestions	Does each issue report include a concrete, developer-implementable remediation? 'Add aria-label="Open navigation menu" to the hamburger button' is actionable. 'Fix the button' is not. 'Set font-size: 16px on all form inputs to prevent iOS Safari auto-zoom' is actionable. 'Make it more accessible' is not. A developer reading the remediation suggestion should be able to implement the fix without asking a follow-up question.
Evidence clarity and reproducibility	Are the issue reports reproducible from the description alone? Do they specify the browser, OS, screen reader version, and the exact element or component (by role, visible label, or position)? Is the distinction between a WCAG failure (must fix for AA compliance) and a best-practice improvement (should fix but not required) clearly maintained across all reports?

Sample solution outline

›Keyboard check (gov.uk/check-uk-visa): Tab order follows visual reading order; all form inputs reachable; 'Start now' button activates via Enter; cookie consent modal — Tab cycles within modal while open (correct focus trap); Escape dismisses cookie banner: PASS on all checks
›Focus indicator: Standard links — visible blue outline on Chrome, visible outline on Firefox: PASS; custom-styled 'Start now' button — focus ring visible on Chrome; gov.uk green button has custom 3px yellow outline on focus: PASS; hypothetical fail example: 'Submit' button with CSS outline:none and no custom focus style — ISSUE A-001 (WCAG 2.4.7, High)
›Screen reader (VoiceOver macOS / Safari): page title announced as 'Check if you need a UK visa — GOV.UK'; landmarks: banner, navigation, main, contentinfo all present; breadcrumb image (gov.uk crown logo) has alt='GOV.UK': PASS; form field 'What is your nationality?' has visible label and is announced as 'What is your nationality?, combobox': PASS
›Contrast observations: (1) Body text #0B0C0C on #FFFFFF → 21:1 PASS; (2) Hint text #505A5F on #FFFFFF → ~7.0:1 PASS; (3) Hypothetical failure — muted helper text #9CA3AF on #F9FAFB → ~2.8:1 FAIL (WCAG 1.4.3, required 4.5:1 for 14px normal text) → ISSUE A-002 (Medium); (4) Hyperlink blue #1D70B8 on #FFFFFF → ~5.9:1 PASS
›Form label audit: 'What is your nationality?' — visible label: YES, clicking label focuses dropdown: YES, announced by VoiceOver: YES; placeholder-only example (hypothetical): search input has placeholder='Search...' but no <label> or aria-label → ISSUE A-003 (WCAG 1.3.1 + 3.3.2, High); remediation: add <label for='search-input'>Search</label> or aria-label='Search' on the input
›Issue A-001 (High) — WCAG 2.4.7 Focus Visible: Submit button — CSS outline:none applied via .btn:focus rule; no custom focus indicator; keyboard user cannot determine which element is focused; remediation: replace outline:none with a custom focus style, e.g. outline: 3px solid #FFD700; outline-offset: 2px
›Summary: tested gov.uk/check-uk-visa; 3 issues found (0 High if gov.uk is used — use hypothetical examples for the report practice); reminder that on a real product you would likely find 3–8 issues on a typical form page; all issues must be fixed for WCAG 2.1 AA compliance before shipping

Common mistakes

Running only an automated axe scan and treating the result as a complete accessibility audit — automated tools catch approximately 30–40% of WCAG failures; keyboard traps, focus-order logic, screen-reader announcement quality, and label association errors all require manual verification
Filing 'the page is not accessible' as a single issue — each accessibility failure must reference a specific element, a specific WCAG criterion number, and include a specific remediation; a single generic finding cannot be triaged, assigned, fixed, or verified
Accepting placeholder text as a form label — placeholder text disappears when the user starts typing, is not reliably announced by all screen readers, and does not satisfy WCAG 1.3.1 or 3.3.2 regardless of how visible it appears visually
Testing keyboard navigation only in Chrome — screen-reader and browser engine pairings behave differently (NVDA with Firefox vs. NVDA with Chrome produce different announcements for the same ARIA attributes); the check should note which browser was used
Skipping custom interactive widgets (date pickers, carousels, custom dropdowns, modal dialogs) in favour of only testing native inputs — custom widgets are the most common source of keyboard accessibility failures and are routinely missed in QA reviews
Reporting a contrast issue without providing the actual foreground and background hex values and the measured ratio — a contrast report without specific values cannot be verified or resolved by a developer; 'the text looks hard to read' is an observation, not an accessibility issue report

Submission checklist

Keyboard navigation check covering all interactive element types on the tested page
Focus indicator assessment for at least 5 interactive element types (visible: yes/no, contrast: adequate/insufficient)
Screen-reader smoke test with browser and screen reader version recorded
Form label audit covering all form fields (label present, visible, focus-associating, announced)
Colour-contrast observations for at least 3 text elements with foreground hex, background hex, ratio, and WCAG pass/fail
Accessibility issue reports for all WCAG 2.1 AA failures with criterion number, element, current/expected behaviour, remediation, and severity
At least one issue distinguishes a WCAG 2.1 AA failure (must fix for compliance) from a best-practice improvement (should fix)
Browser, OS, and screen-reader version recorded on all reports

Extension ideas

+Re-run the same checks on a second page of the same site (e.g. a results or confirmation page) and compare — are the same failure patterns repeated, or do different page types introduce different accessibility issues?
+Write a 5-minute accessibility smoke test that a developer can self-run before submitting a pull request — identify the 4–5 checks that catch the most severe keyboard and screen-reader issues with the least effort
+Investigate one of the ARIA roles (e.g. role='dialog' for modals, role='alert' for live regions) and write a test case that verifies the pattern is correctly implemented on a real or demo application