Accessibility Testing Checklist for Bugs

An accessibility bug report should identify the task, starting state, exact keyboard or form actions, expected access, observed barrier, tested environment and reviewed evidence. Record OS and browser versions; name an assistive technology and version only if it was actually used. Keep untested combinations and suspected causes explicit as Unknown or Not tested.

W3C’s Easy Checks are a first review of selected issues, not a complete evaluation. This checklist can help communicate a suspected barrier; it does not certify WCAG conformance or replace a fuller accessibility assessment.

These checks are prompts to observe behavior. Do not mark an assistive-technology result from a keyboard-only or visual run, and do not infer the underlying code defect from one screenshot.

Both examples below are invented and unrun. They show the level of detail to collect, not findings from ContextCapture or a customer site.

Fictional, unrun example — keyboard path to Save
Starting state: Test draft open; focus in its first editable Title field.
Steps: From the Title field, press Tab repeatedly and record each focus destination until reaching the footer; press Shift+Tab and record the return path; if focus enters the toolbar, try its documented arrow-key route, then Enter or Space on Save if focus reaches it.
Expected: A keyboard path reaches Save and activates the same draft-saving task.
Actual: In this invented scenario, focus moves from the last field to the footer; no keyboard path to Save was found.
Evidence needed: Browser/version, exact focus sequence, visible focus screenshots, tested alternatives.
Assistive technology: Not tested. Root cause and WCAG conformance: Unknown.

Fictional, unrun example — form error marked only in red
Starting state: Test contact form open with safe data; email left blank.
Steps: Activate Submit; inspect the email field and surrounding text.
Expected: If an input error is detected, the affected field and error are identified in text.
Actual: In this invented scenario, only the field border turns red; no text identifies the error.
Evidence needed: Browser/version, screenshot, exact error text if any, focus position.
Assistive technology: Not tested. Programmatic error announcement: Unknown.

For the fictional Save example, start with focus in the first editable Title field and record every Tab and Shift+Tab destination. If focus enters the toolbar, try its documented arrow-key route. Record whether Enter or Space activates Save when focus reaches it, and whether the draft actually saves. If an alternate keyboard route works, report the confusing path precisely instead of claiming Save is wholly unavailable. If no route works, attach the full sequence and tested alternatives.

W3C’s Keyboard explanation concerns the operability of the function, not a required Tab stop for each control. This first pass still does not establish screen-reader behavior or site-wide conformance.

Copy this static report structure. Replace placeholders with actual observations and include a possible success-criterion link only as an informative lead for review, not a certification statement. Remove names, private form values and account details from shared captures.

Title: [task and observed barrier]
Page / release: [safe route and tested build]
Environment: [OS, browser/version, device, viewport and zoom if relevant]
Assistive technology: [name/version only if used; otherwise Not tested]
Starting state: [page, account/test data, focused control such as the first editable field]
Steps: [exact keys or actions, one per line]
Expected: [how the task or feedback should be available]
Actual: [visible/announced result observed, without guessed cause]
Impact: [task blocked or difficult, and who may be affected; unknowns explicit]
Evidence: [reviewed screenshot/video, focus sequence, error text, timestamp]
Possible WCAG reference: [informative lead for review, not conformance verdict]
Retest: Not tested — [owner and environment for next check]

Use the registration form cases for input states, the reproduction guide for a repeatable sequence, and the screenshot annotator to cover private pixels. The bug-report generator and sample report help organize the reviewed handoff.

Published October 9, 2026. Updated October 10, 2026. The examples are fictional; no accessibility test, assistive-technology run or conformance audit occurred on this page.