Accessibility testing checks whether people with different ways of perceiving and operating interfaces can use a product. This includes users of screen readers, keyboards, magnification, voice input, and other assistive tools. An inaccessible button can completely block payment even when the scenario works perfectly with a mouse.
For QA, accessibility is a property of a user flow. People must be able to find an action, understand its purpose, perform it, and obtain the result. Checking individual attributes is useful but cannot replace completing the entire task.
Using WCAG
WCAG defines testable accessibility criteria for web content. Explicitly name the version and level, such as WCAG 2.2 AA. A, AA, and AAA identify sets of requirements; a judgment that something is "generally accessible" does not replace a specific criterion and testing scope.
Four principles help organize the work: information must be perceivable, interfaces operable, behavior understandable, and markup robust enough to support assistive technologies. Conformance is assessed against applicable criteria and complete processes, rather than a scanner's average score.
Keyboard use and visible focus
Put the mouse aside and complete the main scenario. Use Tab and Shift+Tab to move, and Enter, Space, and arrow keys where appropriate for the element type. Buttons and selection lists have different keyboard interaction models, so requiring the same keys for every component is incorrect.
Check logical order, visible focus, and the absence of inescapable keyboard traps. When a dialog opens, focus should move to a sensible location and return to appropriate context when it closes. A sticky panel must not completely obscure a focused component: WCAG 2.2 AA criterion 2.4.11 addresses this specifically.
Semantics and screen readers
A screen reader obtains information from the accessibility tree: element roles, names, states, and relationships. A clickable div may look like a button, but without proper semantics and controls, users may not discover the action.
Check headings, page landmarks, accessible link and button names, and field labels. A delete icon needs a clear contextual name, especially when many identical icons appear. Alt text conveys a meaningful image's purpose; decorative images usually need empty alt text to avoid unnecessary noise.
Forms, errors, and dynamic content
Field names should remain understandable after input. Required status and errors must be conveyed in text rather than only through a red border. Users must be able to find the error, understand how to correct it, and continue without losing valid data.
After adding an item, changing search results, or receiving a server error, check whether the screen reader receives appropriate feedback. Not every update needs a focus move: an unexpected jump can be disruptive. Choosing between a status message and focus movement depends on the task and event.
Contrast, color, and target size
WCAG 2.2 AA requires at least 4.5:1 contrast for ordinary text and 3:1 for large text. Large text means at least 18 pt, or 14 pt in bold. Exceptions include logos and inactive elements. Measure colors with a tool against the actual background, accounting for different states.
Color must not be the only way to explain an error or status. AA criterion 2.5.8 defines a minimum pointer target size of 24×24 CSS pixels with specified exceptions, including sufficient spacing. The 44×44 value belongs to the enhanced AAA criterion; it is not a universal AA minimum.
Magnification and reflow
Increase text size and browser zoom. Check that labels, actions, messages, and reading order remain intact. Ordinary vertical content should not require scrolling in both directions at a width equivalent to 320 CSS pixels; inherently two-dimensional content has exceptions.
Check dialogs, menus, tables, and long errors, beyond a static paragraph. An interface may wrap text correctly yet clip its only confirmation button when zoomed.
Practical example: accessible appointment booking
Suppose a user selects a specialist and date, then confirms an appointment. Test in a supported browser and assistive technology combination.
- 1.Complete the flow using the keyboard. Expect access to every action with visible, logical focus.
- 2.Select a date using a screen reader. Expect a clear calendar name, current selection, and unavailable dates; announcing numbers alone is insufficient.
- 3.Submit without the required phone number. Expect an accessible message associated with the field and a way to correct it.
- 4.Increase zoom and repeat confirmation. The button and result should remain accessible without losing essential information.
- 5.Simulate the selected slot becoming unavailable after submission. Expect an explanation and a clear route to another selection, including for nonvisual use.
Automation and testing limits
Scanners identify some structural problems: certain missing names, ARIA errors, and measurable contrast violations. They cannot judge whether alt text conveys complete meaning or whether a whole task is usable. Finding no violations does not establish full WCAG conformance.
Combine automated analysis, manual keyboard checks, screen readers, and assessment of applicable criteria. Record tested pages, states, tools, and versions. This keeps conclusions bounded and reproducible.
Reporting defects and mistakes to avoid
Describe the user barrier, steps, environment, and criterion where established. "After closing the dialog, focus moves to the top of the page and the user loses the selected row" is more useful than "accessibility is broken." Include the expected recovery behavior.
Common mistakes include applying ARIA everywhere instead of using correct HTML elements, considering mouse testing sufficient, and presenting a scanner report as a certificate. QA aims to establish that important actions are accessible and identify remaining barriers precisely.