Accessibility Testing
Accessibility testing checks whether people with disabilities can perceive, understand, navigate and operate a product — with a keyboard instead of a mouse, a screen reader instead of a screen, magnified text, captions or voice control. In practice it means testing against the success criteria of WCAG 2.2, the current version of the W3C Recommendation that regulations and procurement rules in many jurisdictions reference (some of them in an earlier 2.x version), and then confirming with real assistive technology that the result is usable, not only formally compliant.
This pillar gives the whole map: why accessibility belongs in QA, how WCAG 2.2 is organised, what conformance means, the five practical sub-areas (keyboard, screen reader, forms, visual and automated testing), how to evaluate a product with WCAG-EM, how to fit the work into a sprint and a pipeline, how multilingual and right-to-left products change the picture, and the defects testers find most often.
What accessibility testing is and why it matters
Accessibility is the degree to which people with the widest range of abilities can use a product. The people it concerns are not a niche: blind and low-vision users who rely on screen readers or magnification, deaf and hard-of-hearing users who need captions and transcripts, people with motor impairments who use a keyboard, a switch device or voice control, and people with cognitive, learning or neurological disabilities who depend on predictable layouts and clear language. Temporary and situational limitations — a broken wrist, bright sunlight on a phone, a noisy room — put everyone else in the same position for a while.
For a QA team, accessibility is a quality attribute like security or performance: it can be specified in acceptance criteria, designed for, tested, measured and regressed. It fails in the same ways other quality attributes fail — through missed requirements, late discovery and no regression coverage — and it is fixed by the same discipline.
It is also a legal and contractual matter in many places. Regulations and public-procurement rules in many jurisdictions reference WCAG, and in Europe the harmonised standard EN 301 549 builds on WCAG for web content and adds requirements for software, documents and hardware. The exact obligations differ by country, sector and product type, so leave the legal question to your legal or compliance team and use WCAG as the technical yardstick your tests are written against.
Late discovery is expensive. A custom dropdown built without keyboard support or proper semantics often has to be rebuilt rather than patched, and an audit two weeks before launch finds dozens of such components at once. That is the main argument for testing accessibility continuously, story by story, instead of in a single audit at the end.
How WCAG 2.2 is organised
WCAG 2.2 is a W3C Recommendation (the edition referenced here is dated 12 December 2024). Its normative requirements sit in three layers (WCAG’s own "layers of guidance" add a fourth, informative one: sufficient and advisory techniques). Four principles say what content must be; 13 guidelines under them state goals; and the testable success criteria (SC) under the guidelines are what you actually test and report against. Each success criterion has a number, a name and a level — for example SC 2.1.1 Keyboard (Level A) or SC 1.4.3 Contrast (Minimum) (Level AA). The W3C also publishes informative "Understanding WCAG 2.2" documents for every criterion and a Quick Reference listing techniques and common failures; that is where testers find the intent, the exceptions and the edge cases behind the short normative text.
Each layer sits under the one above it
- 14 principlesWhat content must be: Perceivable, Operable, Understandable, Robust
- 213 guidelinesUnder the principles: they state goals
- 3Success criteria (SC)Testable: what you actually test and report against
Each has a number, a name and a level, e.g. SC 2.1.1 Keyboard (Level A)
- 4Sufficient and advisory techniquesWCAG’s fourth “layer of guidance”
Listed with common failures in the W3C Quick Reference
- Perceivable — information must be presented in ways users can perceive: text alternatives (1.1.1 Non-text Content), captions for media, structure that is programmatically available and not only visual (1.3.1 Info and Relationships), sufficient contrast (1.4.3 Contrast (Minimum)) and content that reflows when zoomed (1.4.10 Reflow).
- Operable — every function must work with the input the user has: keyboard (2.1.1 Keyboard, 2.1.2 No Keyboard Trap), enough time, no flashing that can trigger seizures, navigation aids (2.4.1 Bypass Blocks, 2.4.3 Focus Order, 2.4.7 Focus Visible) and alternatives to complex gestures (2.5.1 Pointer Gestures).
- Understandable — text is readable and the interface is predictable: the page language is declared (3.1.1 Language of Page), focus and input do not cause unexpected changes of context (3.2.1 On Focus, 3.2.2 On Input), and users get help with errors (3.3.1 Error Identification, 3.3.2 Labels or Instructions).
- Robust — content works with current and future user agents, including assistive technology: every user interface component exposes its name, role and value (4.1.2 Name, Role, Value), and status messages can be announced without moving focus (4.1.3 Status Messages).
Levels and what conformance means
Levels are cumulative. Level A is the minimum; Level AA includes every A and AA criterion and is the target most organisations, contracts and regulations use; Level AAA is the highest, and WCAG itself advises against requiring AAA as a general policy for entire sites because some content cannot satisfy every AAA criterion. Unless your contract says otherwise, test against WCAG 2.2 Level AA.
WCAG 2.2 added nine success criteria to WCAG 2.1 — among them 2.4.11 Focus Not Obscured (Minimum), 2.5.7 Dragging Movements, 2.5.8 Target Size (Minimum), 3.2.6 Consistent Help, 3.3.7 Redundant Entry and 3.3.8 Accessible Authentication (Minimum) — and it lists 4.1.1 Parsing as obsolete and removed. If an older test plan or tool report still raises 4.1.1 findings, keep a markup problem only when it causes a failure of another criterion, such as 4.1.2.
A conformance claim is a statement about pages, not about a company or a team. WCAG 2.2 sets five conformance requirements: the chosen level is met in full; conformance applies to full pages, not parts of pages; when a page is one step in a process, every page in the complete process must conform; only accessibility-supported ways of using technologies are relied upon; and technologies that are not relied upon must not interfere with the rest of the page (non-interference).
Two of these shape test design directly. "Full pages" means a compliant form on a page with an inaccessible cookie banner is not a conforming page. "Complete processes" means that checkout, registration or a loan application passes only if every step does — including the payment page, the OTP screen and the confirmation step. When you scope an evaluation, list processes, not just URLs. And conformance is a snapshot: a page that conformed in March can fail in April after a new date picker ships, which is why accessibility needs regression coverage like any other quality attribute.
The five practical sub-areas
WCAG is organised by principle, but testers work by technique. Five sub-areas cover most of the day-to-day work, and each has its own guide in this topic.
- Keyboard accessibility — every function reachable and operable with Tab, Shift+Tab, Enter, Space, the arrow keys and Escape; a logical focus order; a visible focus indicator that is not hidden behind sticky headers; no keyboard traps; skip links; modal dialogs that manage focus. It is the fastest high-value check and the foundation that screen reader, switch and voice-control users build on.
- Screen reader testing — whether the page’s semantics reach assistive technology: accessible names, roles and states, headings and landmarks, meaningful link text, correct use of ARIA and announced status messages, verified with real screen reader and browser pairings such as NVDA or JAWS on Windows, VoiceOver on macOS and iOS, and TalkBack on Android.
- Accessible forms — visible labels and instructions, grouping of related fields, required-field indication, error identification and suggestions, error prevention for legal and financial submissions, input-purpose autocomplete and accessible authentication. Forms are where accessibility failures most often block a transaction outright.
- Visual accessibility — text and non-text contrast, use of colour, resize and reflow, text spacing, orientation, target size, content that appears on hover or focus, motion and flashing, and text alternatives for images.
- Automated accessibility testing — rule engines such as axe-core and audits such as Lighthouse, run in the browser, in component and end-to-end tests and in CI to catch machine-detectable failures on every change, while leaving judgement calls to people.
Manual and automated testing: what each can find
Automated checkers are valuable and limited. They reliably detect conditions that can be decided from the code and the computed styles: an image with no alt attribute, a form control with no accessible name, an ARIA attribute that is not allowed on a role, a reference to a missing id, plain text below the contrast threshold. They cannot decide whether alt text describes the image, whether the focus order makes sense, whether a heading describes its section, whether an error message helps, or whether a custom widget can actually be operated with a screen reader. The W3C’s evaluation overview states that tools alone cannot determine whether a site is accessible; how much of a product’s problems a tool catches depends on the product and the tool, and it is always only part of the picture.
The W3C Accessibility Conformance Testing (ACT) rules describe, in a tool-neutral format, how to test specific aspects of WCAG and ARIA. Some rules can be fully automated and some need a human judgement; when you compare tools, asking which ACT rules a tool implements is more useful than comparing headline numbers. A workable split of effort looks like this:
- Automated, on every change — rule-engine scans of key pages and components, in CI.
- Manual, per story — a keyboard pass, a short screen reader pass, zoom and reflow, and contrast of anything new on the changed UI.
- Expert evaluation, per release or per quarter — a structured WCAG evaluation of a representative sample (see WCAG-EM below).
- Testing with disabled users, periodically — the only way to learn whether the product is usable in practice, not just conformant on paper.
Evaluating a product with WCAG-EM
The WCAG Evaluation Methodology (WCAG-EM) 2.0, published by the W3C as a Group Note in July 2026, describes how to evaluate how well a digital product conforms to WCAG 2. It is a procedure, not a tool, and it works for a website, a web application or a set of app screens. Its five steps map cleanly onto a QA test plan:
- 1. Define the evaluation scope — the product and its parts, the conformance target (usually WCAG 2.2 Level AA), the accessibility support baseline (the browsers and assistive technologies the product is expected to work with) and any additional requirements.
- 2. Explore the product — identify common views, essential functionality, the variety of page or screen types, and the technologies relied upon.
- 3. Select a representative sample — a structured sample covering what step 2 found, some randomly selected samples, and every complete process.
- 4. Evaluate the sample — check every sample and every complete process against the criteria in the target, then compare the structured and random results; if the random samples reveal new kinds of failure, the structured sample missed something.
- 5. Report the findings — document the outcome of each step; optionally add evaluation specifics, an evaluation statement, an aggregated score and machine-readable reports.
Accessibility in the sprint
Accessibility is cheapest when it is a property of every story rather than a phase. For a sprint team WCAG-EM scales down naturally: the scope is the release, the sample is the changed screens plus the processes they touch, and the report is the list of failed criteria with linked defects. A practical flow:
- Refinement — add accessibility acceptance criteria to every story with UI: keyboard operation, names for controls, announced errors and status, contrast of new colours. Reference the success criterion numbers.
- Design review — check contrast, focus styles, target sizes, reading and focus order, and that nothing is conveyed by colour alone, before code exists.
- Development — prefer native HTML elements, follow the ARIA Authoring Practices patterns for custom widgets, and run an automated checker locally and in component tests.
- Story testing — the tester runs the keyboard pass, a screen reader smoke pass on one agreed pairing, zoom to 200% and reflow at 400%, and reviews the automated results.
- Regression — keep a short accessibility regression suite for critical journeys (login, search, checkout, key forms), rerun it on each release, and rotate the screen reader pairings over time.
- Definition of done — a story is not done while it has open Level A or AA failures, unless the team has explicitly accepted, ticketed and scheduled them.
Accessibility definition of done (story with UI)
[ ] Every new function works with keyboard only (Tab, Shift+Tab, Enter, Space, arrows, Esc)
[ ] Focus order follows reading order; focus is visible on every focusable element
[ ] Focused element is never fully hidden by a sticky header, footer or banner
[ ] Every control has an accessible name that contains its visible label
[ ] Headings and landmarks reflect the visual structure
[ ] Errors, toasts and loading states are announced (status / alert)
[ ] Text contrast >= 4.5:1 (large text >= 3:1); UI components and graphics >= 3:1
[ ] Usable at 200% text size; reflows at 400% zoom without horizontal scrolling
[ ] lang and dir correct in every locale (Arabic: lang="ar" dir="rtl")
[ ] Automated scan: no new violations
[ ] Screen reader smoke pass on the agreed pairing (for example NVDA + Firefox)Typical accessibility defects and how to report them
The same failures appear across products. Written as bug titles, with the criterion each one fails:
- "Country dropdown cannot be opened or changed with the keyboard" — 2.1.1 Keyboard.
- "Focus returns to the top of the page after closing the Edit address dialog" — 2.4.3 Focus Order.
- "No visible focus indicator on primary buttons (outline removed in global CSS)" — 2.4.7 Focus Visible.
- "Icon-only delete button is announced as button with no name" — 4.1.2 Name, Role, Value.
- "Section titles are styled paragraphs; the screen reader headings list is empty" — 1.3.1 Info and Relationships.
- "Item added to cart toast is not announced by screen readers" — 4.1.3 Status Messages.
- "Grey helper text on white has a contrast ratio of 2.9:1" — 1.4.3 Contrast (Minimum).
- "Arabic page declares lang=en; the screen reader reads Arabic text with an English voice" — 3.1.1 Language of Page.
Try it: AI Bug Title Generator Try it: AI Bug Description Generator
Reporting defects and automating in CI
An accessibility bug report needs everything a normal bug report needs (the guide on writing bug reports covers the anatomy and severity versus priority), plus four things: the success criterion and its level; the assistive technology, browser and operating system with versions; the exact key sequence or the exact announcement heard; and the user impact. "Screen reader users cannot complete checkout" is the sentence that sets priority. A Level A failure that blocks a core journey is usually treated as a release blocker.
Automated checks belong in the pipeline for the same reason unit tests do: they stop known regressions cheaply. Common patterns are running a rule engine inside existing end-to-end tests (for example axe-core with Playwright, Cypress or Selenium), scanning a list of URLs after deployment to a test environment, and running Lighthouse accessibility audits on key pages. Gate on what tools can decide: fail the build on new violations, keep a baseline of known issues with tickets so the pipeline does not stay red forever, and review the rule set when the tool updates. Never report a green pipeline as "accessible" — it means only that the automated rules found nothing. The automated accessibility testing guide covers tool integration, rule selection and triage in depth.
Multilingual and right-to-left accessibility
Products used in Arabic and English — common in Saudi Arabia and across the Gulf — need checks that single-language test plans miss. Screen readers use the language the page declares to load the correct pronunciation rules, so the lang attribute on the html element must match the page language (3.1.1 Language of Page), and passages in another language, such as an English product name inside Arabic text, should carry their own lang attribute (3.1.2 Language of Parts). A wrong lang value produces speech that is very hard to understand even when every other check passes.
Direction is the second concern. The dir attribute (dir="rtl" on the html element for Arabic pages) sets the base direction; the layout mirrors, and the focus order must still follow the reading order, which in Arabic runs right to left. Check that Tab moves through the mirrored layout in a logical order, that arrow keys in sliders, carousels and tab lists behave consistently with the mirrored layout, that directional icons are mirrored where they should be, and that mixed Arabic and Latin strings — order numbers, email addresses, phone numbers — are displayed and read in the right order. The RTL testing guide covers bidirectional text and layout mirroring in detail.
Try it: Multilingual Test Data Generator Try it: Arabic Test Data Generator
Frequently asked questions
What is the difference between accessibility testing and usability testing?
Accessibility testing checks whether people with disabilities can use the product, usually against WCAG success criteria and with assistive technology. Usability testing checks how easily representative users achieve their goals. They overlap; testing with disabled users is both.
Which WCAG level should we test against?
WCAG 2.2 Level AA, unless a contract or regulation specifies something else. AA includes all Level A criteria. WCAG itself advises against requiring AAA as a general policy for whole sites, although individual AAA criteria can be worth adopting.
Can an automated tool make a site WCAG compliant?
No. Tools find the problems that can be decided from code and styles, such as missing names or low text contrast. Whether focus order, alt text, headings and error messages make sense needs a human, and the W3C states that tools alone cannot determine accessibility.
Is 4.1.1 Parsing still tested?
Not as a WCAG 2.2 criterion: WCAG 2.2 lists 4.1.1 Parsing as obsolete and removed. Markup errors still matter when they break something else, for example when a duplicate id makes a label point at the wrong field, which fails other criteria such as 4.1.2.
Do we need to test with real screen readers?
Yes, for anything beyond static content. Browser developer tools show the accessibility tree, but only a real screen reader and browser pairing shows what users actually hear, including how live regions, custom widgets and focus changes behave.
Does WCAG apply to mobile apps?
WCAG is written for web content, but its principles and most criteria apply to app screens too, and EN 301 549 applies WCAG-based requirements to software as well as the web. Test native apps with the platform screen readers, VoiceOver on iOS and TalkBack on Android.
References
- Web Content Accessibility Guidelines (WCAG) 2.2The W3C Recommendation that defines the testable success criteria for accessible web content, organised under four principles and three conformance levels (A, AA, AAA).
- Understanding WCAG 2.2The informative explanation of each WCAG 2.2 guideline and success criterion: intent, who benefits, examples and techniques (not normative).
- WCAG Evaluation Methodology (WCAG-EM) 2.0The W3C method for evaluating a whole website against WCAG: define scope, explore, select a representative sample, audit it and report.
- Evaluating Web Accessibility OverviewW3C's entry point for accessibility evaluation: why to evaluate early and throughout development, and how manual checks, tools and user involvement fit together.
- All ACT RulesAccessibility Conformance Testing rules: precise, documented test procedures for WCAG and ARIA requirements, used to make automated and manual results consistent.
- How to Meet WCAG (Quick Reference)A filterable checklist of every WCAG 2.2 success criterion with its sufficient techniques and common failures.
- EN 301 549 V4.1.1 (2026-09) — Accessibility requirements for ICT products and servicesThe harmonised European accessibility standard for ICT, which builds on WCAG for web content and adds requirements for software, documents and hardware.
- Structural markup and right-to-left text in HTMLHow to set base direction with the dir attribute on html and structural elements, and why CSS alone should not be used for it.
Practice exercise
Check a booking release against WCAG 2.2 AA
You are the tester on the patient portal of a private clinic group (fictional). The portal is in Arabic, its default language, and in English. Release 3.2 adds online appointment booking, a process of five pages, and goes live in ten days; the contract requires WCAG 2.2 Level AA. The CI pipeline runs an automated accessibility scan and is green, and a colleague has just finished a manual pass. The material below gives the process, the scan result, the eight observations from the manual pass (O1 to O8) and two comments from the release thread.
Work on paper with the guide and the WCAG 2.2 Quick Reference; a colour converter that shows WCAG contrast ratios gives you the numbers for O6 and O8. Allow 45–60 minutes.
Patient portal of a private clinic group (fictional) - web, Arabic (default) and English
Release 3.2 adds online appointment booking.
Today: Thu 8 Oct 2026. Go-live: Sun 18 Oct 2026.
Contract target: WCAG 2.2 Level AA for every public page and process.
Booking process (5 pages)
1. /book/clinic choose a clinic and a specialty
2. /book/slot choose a doctor, a date and a time slot
3. /book/details patient name, national ID or iqama number, mobile number
4. /book/verify enter the 6-digit code sent by SMS
5. /book/done confirmation
CI accessibility scan - axe-core inside the Playwright end-to-end tests, every merge
Rules: WCAG Level A and AA
Scanned: /book/clinic, /book/slot, /book/details, /book/done (English and Arabic)
Not scanned: /book/verify - the test cannot receive the SMS code
Build 3.2.0-rc1: PASSED, 0 new violations
Baseline of known issues: color-contrast on /book/details, 1 element (.field-hint),
ticket A11Y-41, planned for release 3.3
Manual pass - Lina (tester), staging, build 3.2.0-rc1
Lab PC LAB-07: Windows 11, Chrome, NVDA (exact versions on the lab sheet)
O1 /book/slot, Arabic and English UI, keyboard only: Tab goes from the date field
straight to "Continue"; no time slot ever receives focus, and Enter or Space does
nothing. A mouse click selects a slot. NVDA browse mode reads each slot as plain
text ("09:30"), no role.
O2 /book/slot: available slots are green, fully booked slots are grey. Text, icon,
border and pattern are otherwise identical.
O3 Arabic UI, every page: the html element has lang="en" dir="rtl". NVDA reads the
Arabic text with its English voice; Lina could not understand it.
O4 /book/details, window 1280x720, zoom 100%: when Tab reaches "Continue", the
sticky "Need help? Call us" bar at the bottom of the window covers the button
completely.
O5 /book/verify, NVDA + Chrome: the code goes into 6 one-digit boxes. Each box is
announced "edit, blank"; the text above them, "Enter the 6-digit code sent to
your mobile", is not read when a box receives focus.
O6 /book/details: the hint "10 digits" under the ID field is #8a8a8a on #ffffff,
14px, regular weight. It is the .field-hint element in the scan baseline.
O7 An audit tool from an older project reports on /book/details:
"4.1.1 Parsing - duplicate id icon-help". Two decorative icons share the id;
nothing refers to that id (no for, aria-labelledby, aria-describedby or similar).
O8 A checklist found online says "body text needs 7:1". Body text on /book/clinic
is #666666 on #ffffff, 16px.
Release thread
Omar (product owner): "CI is green and the only known issue is a shade of grey.
Please confirm we are WCAG 2.2 AA compliant, so marketing can say so in the
release notes."
Rami (development lead): "Very few patients use only a keyboard. The slot picker
fix can wait for 3.3."- Map each observation to its WCAG principle and success criterion (number, name and level), and decide whether it is a failure against the contract target. Give the reason in one line.
- For each failure, decide whether a rule engine can detect it from the code and the computed styles, and explain why the pipeline is green anyway.
- Decide whether the booking process can be claimed to conform to WCAG 2.2 Level AA, using the conformance requirements, and say which failures you would recommend treating as release blockers.
- Write the bug report for O1, including the four things an accessibility bug report needs on top of a normal one.
- Reply to Omar and to Rami in two or three sentences each, and list what the team changes so that the next release does not repeat this.
Show the model answer
Step 1. The target is WCAG 2.2 Level AA, so every Level A and AA criterion counts. O1 — Operable, 2.1.1 Keyboard (A): failure; a slot can be chosen with a mouse but not with the keyboard. The slots also expose no role or state (NVDA reads plain text), so 4.1.2 Name, Role, Value (A) fails as well; native <button> elements, or a radio group built on the ARIA Authoring Practices pattern, fix both. O2 — Perceivable, 1.4.1 Use of Color (A): failure; colour is the only visual difference between an available and a booked slot. Add a difference that is not colour, such as the word "Booked" or an icon, and expose the state to assistive technology. O3 — Understandable, 3.1.1 Language of Page (A): failure on every Arabic page; they need lang="ar" (the dir="rtl" is already right), and English passages inside Arabic text then need their own lang under 3.1.2 Language of Parts (AA).
O4 — Operable, 2.4.11 Focus Not Obscured (Minimum) (AA), new in WCAG 2.2: failure; the focused "Continue" button is entirely hidden by author-created content, the sticky bar. If the bar hid only part of the button, this AA criterion would pass; "no part hidden" is the AAA criterion 2.4.12 Focus Not Obscured (Enhanced). O5 — Robust, 4.1.2 Name, Role, Value (A): failure; the six inputs have no accessible name, so the visible instruction never reaches the screen reader (some teams also record 1.3.1 Info and Relationships). O6 — Perceivable, 1.4.3 Contrast (Minimum) (AA): failure; #8a8a8a on #ffffff is 3.45:1, and 14px regular text is not large text, so it needs at least 4.5:1.
O7 — not a WCAG 2.2 failure. WCAG 2.2 lists 4.1.1 Parsing as obsolete and removed, and this duplicate id breaks nothing else, because nothing on the page refers to it. Pass it to the developer as a code-quality note, not as an accessibility defect, and stop counting the old tool’s 4.1.1 results. O8 — not a failure against the target. 7:1 is the AAA criterion 1.4.6 Contrast (Enhanced); #666666 on #ffffff is 5.74:1, which meets 1.4.3 at AA. Result: six failures (O1 to O6), four of them at Level A, and two observations that are not defects.
Step 2. Only O5 and O6 are the kind of problem a rule engine decides from code and computed styles: a form control with no accessible name, and text below the contrast threshold. O6 was found, but it sits in the baseline of known issues, so it no longer turns the build red. O5 is the same kind of problem the scan detects, but /book/verify is not in the scan list. O1 to O4 need a person: whether a function works with the keyboard has to be tried; whether colour is the only difference is a visual judgement; a rule engine can check that lang is present and valid, but en is a valid value, and only a person hears that it is the wrong language for the text; and a sticky bar hiding the focused element shows up only when you move focus through the page at a given window size. So the green pipeline means only that the automated rules found nothing new on the four pages they scan.
Step 3. No conformance claim is possible. Booking is a complete process, and the WCAG conformance requirements say that when a page is one step in a process, every page of the process must conform at the claimed level; conformance applies to full pages. The contract covers every public page, so the Arabic and the English version of each page both count. /book/slot fails O1 and O2, /book/details fails O4 and O6, /book/verify fails O5, and every Arabic page fails O3, so the process does not even meet Level A. /book/clinic and /book/done may pass on their own in English, but they cannot carry a claim either while the process they belong to fails.
Release blockers, as a recommendation to the product owner and the release manager. O1: a Level A failure that blocks a core journey is usually treated as a release blocker, and here keyboard users — and the screen reader, switch and voice-control users who build on keyboard operation — cannot choose a time, so they cannot book at all. O3: Arabic is the default language, an Arabic screen reader user hears the whole journey in an English voice, and the fix is usually one attribute in the page template. O5 should be fixed before go-live as well: the code step is part of the same journey and the fix is small. O2 and O4 fail the contract target too: fix them before go-live, or the team accepts them explicitly, tickets them and schedules them with the contract in view, as has been done for O6 (A11Y-41, release 3.3). Whatever is decided is recorded with its reason.
Step 4, a model bug report. Title: Time slots on /book/slot cannot be focused or selected with the keyboard. Criterion: 2.1.1 Keyboard (Level A), with 4.1.2 Name, Role, Value (Level A). Environment: staging, build 3.2.0-rc1; LAB-07, Windows 11, Chrome, keyboard only, then NVDA with Chrome, exact versions copied from the lab sheet; Arabic and English UI. Steps and key sequence: open /book/slot, choose a doctor and a date with the keyboard, then press Tab. Actual: focus moves from the date field straight to "Continue"; no slot receives focus, and Enter and Space do nothing; NVDA browse mode reads the slots as plain text, for example "09:30", with no role or state. Expected: every available slot can be reached and selected with the keyboard and is announced with its time, its role and whether it is available or selected. User impact: patients who use a keyboard, a screen reader, a switch device or voice control cannot book an appointment online; the journey stops at step 2 of 5. Proposed severity: Blocker, because the core journey cannot be completed in the portal; priority is the product owner’s decision, with go-live on 18 Oct. Attachments: a screen recording of the key sequence and the text from NVDA’s speech viewer. Hint for the developer: native <button> elements, or a radio group that follows the ARIA Authoring Practices pattern.
Step 5. To Omar: not yet, and not in the release notes. A conformance claim is a statement about pages, and the booking process has six failures against Level A and AA criteria, four of which no rule engine can detect; even the known "shade of grey" is a Level AA failure, and the green pipeline means only that the automated rules found nothing new on the four pages they scan. What can be published is a factual status: tested against WCAG 2.2 Level AA, the open failures with their tickets, and the fix plan. To Rami: the number of keyboard-only users is not the measure. Keyboard operation is the foundation that screen reader, switch and voice-control users build on, this is a Level A failure that blocks booking, and the contract asks for AA. If the team still wants to defer it, Omar as product owner decides, and the decision is recorded with the risk, the ticket and the date.
So that 3.3 does not repeat this: give the test environment a fixed test code or an SMS stub, so the end-to-end test reaches /book/verify and the scan covers every page of the process; fix A11Y-41 in 3.3 as planned, so the baseline shrinks instead of growing; add the guide’s accessibility definition of done to every story with UI — keyboard pass, screen reader smoke pass on the agreed pairing, zoom and reflow, contrast, and lang and dir in every locale; write the criterion numbers into the acceptance criteria during refinement, and check colour-only states and sticky elements in design review; put the booking journey, in Arabic and English, into the accessibility regression suite; and plan an expert evaluation per release on a WCAG-EM sample that includes every complete process.
If your answers differ, check them against the Understanding document of each criterion. Some observations fairly map to two criteria (O1, O5), and a team may decide with a recorded reason that O3 does not block the release. What is not acceptable is a finding without its criterion and level, an observation that is not a defect reported as one, or a conformance claim built on a green pipeline.
Your progress on this topic
Not started
Mark the topic complete when you have studied it and done the exercise.
Sign in to track your progress
Mark topics complete, continue where you left off and unlock specialisation exams.
Part of the QA Roadmap
Before this topic
Tools mentioned in this guide
Check HTML for common accessibility problems — missing alt text, unlabeled fields, nameless buttons and links, ARIA errors, headings, contrast — mapped to WCAG 2.2.
Generate a tailored QA checklist (functional, UI, API, security, performance, accessibility, release) for any feature with Mutqan AI.
Generate clear, searchable bug titles from a messy description with Mutqan AI.
Turn rough notes into a complete bug report: steps to reproduce, expected vs actual, environment, severity and attachments checklist.
Generate the same records in multiple languages (English, Arabic, Hindi, and more) to test i18n and RTL/LTR mixing.
Generate Arabic names, addresses, sentences, numbers (Arabic-Indic digits) and RTL edge cases for localisation testing.