Screen Reader Testing
Screen reader testing checks whether a page or app exposes the right information to assistive technology: what each element is (its role), what it is called (its accessible name), what state it is in, how the content is structured, and whether changes are announced. A screen reader can only speak what the code tells it, so most failures are semantic — a button that is really a div, an icon with no name, a heading that is only bold text.
This guide explains how screen readers use semantics, how accessible names are computed, what to check in headings, landmarks, links and controls, the rules for using ARIA, how to test dynamic content and live regions, which screen reader and browser pairings to use, and a practical test routine with test cases and defect examples.
How screen readers use semantics
The browser turns the DOM into an accessibility tree: a parallel structure in which every meaningful element has a role (button, link, heading, textbox), a name, states and properties (expanded, checked, required, invalid) and relationships. The operating system’s accessibility API passes that tree to the screen reader, which speaks it or sends it to a braille display. Visual styling does not change an element’s role: a div styled as a button is still a generic element in the tree. CSS is not irrelevant to the tree, though: display: none and visibility: hidden remove content from it, and text generated with CSS (::before and ::after) can become part of an accessible name.
- 1DOMHTML elements and ARIA attributes
<button aria-label="Search">Branch: Icon only, no aria-label: no name, so just “button” is heardFail
- 2Accessibility treebuilt by the browserRole · name · states and properties · relationships
role: button · name: "Search" - 3OS accessibility APIPasses the tree to the screen reader
- 4Screen reader
- 5Speech or braille display
"Search, button"Expected
Simplified. Styling does not change a role: a div styled as a button is still generic in the tree. CSS can still remove content from it with display: none or visibility: hidden, or add to a name with ::before or ::after.
That is why native HTML comes first. A button element has the button role, receives focus, activates with Enter and Space, and takes its name from its text — all without extra code. Headings (h1 to h6), lists, tables with th, label elements, fieldset and legend, and landmarks such as nav and main give screen reader users the same structure sighted users see. Most WCAG failures this page deals with fall under 1.3.1 Info and Relationships (structure must be programmatically determinable) and 4.1.2 Name, Role, Value (every user interface component exposes its name, role, states and value).
Desktop screen readers on Windows have two main ways of working. In browse mode (also called virtual cursor) the user reads the page with the arrow keys and jumps by element type with single letters; in focus mode (forms mode) keystrokes go to the focused control, so typing works in fields and arrow keys operate widgets. Screen readers switch modes automatically for many controls; custom widgets that break this switching are a common source of defects.
Accessible names and descriptions
The accessible name is what a screen reader announces for an element, and voice-control users say it to activate the element. Browsers compute it following the W3C Accessible Name and Description Computation (accname 1.2, currently a Working Draft). Simplified, the name comes from the first of these that applies:
- aria-labelledby — text of the referenced element or elements.
- aria-label — a string on the element itself.
- Native labelling — label element for form fields, alt for images, caption for tables, legend for fieldsets.
- Content — for roles that allow it, such as buttons, links and headings, the element’s text.
- Fallbacks — the title attribute and, for inputs, the hint text shown inside the empty field; they are unreliable and should not be the only name.
Checking names, labels and descriptions in practice
Use the browser developer tools’ accessibility pane to see the computed name, role and states of an element before you listen to it: it tells you why something is announced the way it is. Then check three things. First, every interactive element has a name — icon-only buttons (search, close, delete, menu) are the classic failure. Second, the name contains the visible label: 2.5.3 Label in Name requires that a control whose label includes text has that text in its accessible name, so a button that shows "Send" must not be named "Submit form". Third, the name is useful out of context: "Delete" in a list of twenty addresses is better as "Delete address: 12 Olaya Street".
A description adds secondary information, typically through aria-describedby: a password rule, the format of a date, an error message attached to a field. Descriptions are announced after the name and role, sometimes after a pause, and users can turn some of them off, so critical information belongs in the name or visible label. Form labels, instructions and error messages are covered in depth in the accessible forms guide.
Headings, landmarks and page titles
Screen reader users rarely read a page top to bottom. They open a list of headings or landmarks, or jump from heading to heading, to find the part they need. That makes structure testable: open the headings list and compare it with what you see. Every visual heading should be a real heading element, the levels should reflect the hierarchy (one main h1, h2 for sections, h3 inside them), and heading text should describe its section (2.4.6 Headings and Labels). Styled text that looks like a heading but is not marked up fails 1.3.1.
Landmarks mark the regions of a page: header (banner), nav (navigation), main, aside (complementary), footer (contentinfo), plus search and form regions. Check that main content sits inside main, that repeated navigation sits in nav, and that when there are several regions of the same type each has a label such as "Main menu" and "Footer links". Finally, the page title is the first thing announced: 2.4.2 Page Titled requires a title that describes the topic or purpose, and single-page applications must update it on every route change.
Links, buttons, form controls and images
Links navigate; buttons act. A link that submits a form, or a button that goes to another page, confuses users because the role predicts the behaviour. Link text must make the purpose clear from the text itself or from its context (2.4.4 Link Purpose (In Context)); a links list full of "Click here" and "Read more" fails users who navigate by links. Buttons must announce their state where they have one: aria-pressed for toggle buttons, aria-expanded for buttons that open menus, accordions and disclosures.
Form controls need a name, a role, their current value and state (required, invalid, checked, selected), and their error message attached so that it is announced — the accessible forms guide covers this in depth. Images need a text alternative that serves the same purpose (1.1.1 Non-text Content): meaningful alt for informative images, empty alt for decorative ones so the screen reader skips them; the visual accessibility guide covers alt text in detail.
ARIA: roles, states, properties and the rules for using them
WAI-ARIA 1.2 (a W3C Recommendation) defines roles (what an element is: tab, dialog, menu, alert), states (conditions that change: aria-expanded, aria-checked, aria-selected) and properties (more stable characteristics: aria-label, aria-controls, aria-required). ARIA changes only what is exposed in the accessibility tree; it does not change behaviour. The ARIA Authoring Practices Guide is explicit that ARIA roles do not cause browsers to provide keyboard behaviour or styling — a div with role="button" still needs tabindex and key handlers.
Two pieces of W3C guidance summarise how to use it. The long-standing "first rule of ARIA use" says that if you can use a native HTML element or attribute with the semantics and behaviour you need already built in, do so instead of adding ARIA to another element. And the APG’s "No ARIA is better than bad ARIA" warns that incorrect ARIA misrepresents what is on screen, which can make the experience worse than no ARIA at all. In testing, the most common ARIA defects are:
- A role without the behaviour — role="button", role="tab" or role="checkbox" on elements that cannot be focused or operated from the keyboard.
- States that never change — aria-expanded stays "false" after the menu opens; aria-selected is not moved when another tab is chosen.
- aria-hidden="true" on content that contains focusable elements, so keyboard focus lands on something the screen reader cannot perceive.
- aria-label on a plain div or span with no role — WAI-ARIA 1.2 prohibits naming the generic role, so the label may not be announced.
- A name that contradicts the visible label, failing 2.5.3 Label in Name.
- Application roles on ordinary content — role="menu" on a site navigation list, or role="application" on a page region, which changes how the screen reader handles keys.
Dynamic content, live regions and status messages
Anything that changes without a page load is invisible to a screen reader user unless it is announced or focus moves to it. Choose between the two deliberately. Move focus when the user must act on the new content (a dialog opens, a new page view loads). Announce without moving focus when the user should simply know something happened: "Saved", "3 results", "Item added to cart", "Uploading 40%". That second case is exactly 4.1.3 Status Messages, which requires status messages to be programmatically determinable through role or properties so assistive technology can present them without them receiving focus.
The tools are live regions. role="status" (polite: announced when the user is idle) suits results counts and confirmations; role="alert" (assertive: interrupts) is for important, time-sensitive messages such as errors; role="log" suits chat and activity feeds. When you test, trigger each change and listen. Typical failures: the live region is inserted into the page at the same moment as its text, so nothing is announced; the region is hidden with display: none; a spinner announces "loading" every half second; or everything is an alert and the user is constantly interrupted.
Screen reader and browser pairings
Screen readers and browsers are tested as pairs, because both take part in producing the result. Choose pairings from your audience data and your contract’s accessibility support baseline, keep the list short, and rotate through it across releases rather than testing everything every sprint.
- Windows — NVDA (free, open source) with Firefox or Chrome; JAWS (commercial) with Chrome or Edge; Narrator, built into Windows, with Edge.
- macOS — VoiceOver, built in, usually tested with Safari.
- iOS and iPadOS — VoiceOver with Safari and with native apps.
- Android — TalkBack with Chrome and with native apps.
- Record the versions of the screen reader, browser and operating system with every result; behaviour changes between versions.
A practical screen reader test routine
Learn a small set of commands well rather than all of them. This routine covers most pages in fifteen to thirty minutes on one pairing; keep speech rate comfortable at first and write down exactly what you hear.
1. Load the page Title announced? Language/voice correct?
2. Headings list NVDA: NVDA+F7 (Elements list) · JAWS: Insert+F6 · VoiceOver macOS: VO+U (rotor)
Does the outline match the visual structure?
3. Landmarks NVDA: D · JAWS: R · VoiceOver: rotor > Landmarks
4. Links list NVDA: NVDA+F7 · JAWS: Insert+F7 — does each link make sense?
5. Read in order NVDA/JAWS: Down Arrow · VoiceOver macOS: VO+Right Arrow
iOS VoiceOver / TalkBack: swipe right
6. Operate controls Tab to each control: name + role + state announced?
Activate: Enter/Space · iOS/Android: double-tap
7. Forms Labels, required, errors announced on submit?
8. Dynamic changes Trigger toasts, filters, loading: announced without focus move?
9. Dialogs Announced as dialog with its name? Background silent? Focus returns on close?
10. Complete task Finish one real process (search, checkout) with the screen reader only
NVDA key = Insert (Caps Lock can also be set) · VO = Control+Option
NVDA: NVDA+Space toggles browse/focus mode · Ctrl stops speechScreen reader test cases
Use these as the expected results for each page type and complete process in scope, recording the pairing with every result.
- SR-01 — The page title is announced on load and describes the page (2.4.2).
- SR-02 — The page language is correct and text is read with the right voice; other-language passages switch voice (3.1.1, 3.1.2).
- SR-03 — The headings list reflects the visual structure with logical levels (1.3.1, 2.4.6).
- SR-04 — Main, navigation, header and footer landmarks exist; repeated landmark types are labelled.
- SR-05 — Every link’s purpose is clear from its text or context (2.4.4).
- SR-06 — Every button and control announces name, role and state; toggles announce pressed or expanded (4.1.2).
- SR-07 — Informative images have meaningful alternatives; decorative images are silent (1.1.1).
- SR-08 — Custom widgets announce the right role and every state change (4.1.2).
- SR-09 — Status messages are announced without moving focus (4.1.3).
- SR-10 — A modal is announced as a dialog with its name, and the page behind is not read while it is open.
- SR-11 — Nothing visible is hidden from the screen reader, and nothing hidden is read.
- SR-12 — At least one complete process can be finished with the screen reader alone.
Defect examples
Written as bug titles. In the report, add the pairing with versions, the steps, and the exact announcement — for example: NVDA 2026.x + Firefox, Tab to the search icon, heard "button", expected "Search, button".
- "Search icon button is announced as button with no name" — 4.1.2 Name, Role, Value.
- "FAQ accordion headers do not announce expanded or collapsed state" — 4.1.2 Name, Role, Value.
- "Offers page has twelve links all announced as Read more" — 2.4.4 Link Purpose (In Context).
- "Section titles are styled div elements; the headings list is empty" — 1.3.1 Info and Relationships.
- "Result count after applying filters is not announced" — 4.1.3 Status Messages.
- "aria-hidden on the header hides the focusable menu button from the screen reader" — 4.1.2 Name, Role, Value.
- "Send button has aria-label Submit form; voice command Click Send does nothing" — 2.5.3 Label in Name.
- "Company logo announced as logo-final-v2.png" — 1.1.1 Non-text Content.
Try it: AI Bug Title Generator Try it: AI Bug Description Generator
Frequently asked questions
Which screen reader should I test with?
The pairings your users and your contract’s support baseline require. A common minimum is one Windows pairing such as NVDA with Firefox or Chrome, plus VoiceOver on iOS and TalkBack on Android for mobile. Rotate other pairings across releases.
Should we add aria-label to everything?
No. Most elements get their name from visible text or native labels, which also keeps screen reader and visual users in sync. Use aria-label mainly for controls with no visible text, such as icon buttons, and never let it contradict the visible label.
Is ARIA required to make a page accessible?
No. A page built from native HTML elements with visible labels, real headings and landmarks is largely accessible without any ARIA. ARIA is for what HTML cannot express, such as tabs, expanded states and live regions, and it must be tested like any other code.
Why does my live region announce nothing?
Usually the region was added to the page together with its message, it is hidden with display: none, or the text did not change. Render the empty region when the page loads and update its text later. Check that the role (status or alert) fits the message.
Do screen readers read Arabic?
Major screen readers can speak Arabic when an Arabic voice is available, and they rely on the page’s lang attribute to apply the right pronunciation rules. Check that Arabic pages declare lang="ar", that English passages inside them are marked, and that numbers and mixed strings are read in a sensible order.
References
- Accessible Rich Internet Applications (WAI-ARIA) 1.2The W3C Recommendation that defines ARIA roles, states and properties — how custom widgets expose their meaning to assistive technology.
- ARIA Authoring Practices Guide (APG)Patterns for common widgets (tabs, menus, dialogs, comboboxes) with the expected keyboard interaction and ARIA usage — the reference testers compare custom components against.
- Accessible Name and Description Computation 1.2How browsers compute the accessible name and description of an element from labels, ARIA attributes and content (a W3C Working Draft).
- 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).
- Accessibility — MDNPractical guides to building and checking accessible web pages: semantic HTML, ARIA, keyboard support and testing.
- Accessibility — Human Interface GuidelinesApple's accessibility design guidance for iOS and other platforms: VoiceOver, Dynamic Type, contrast, touch targets and motion.
- Test your app's accessibilityHow to test an Android app's accessibility manually with TalkBack and other services, and automatically with the platform's testing tools.
Practice exercise
Review a screen reader session on a search results page
You test the English UI of Dawa, an online pharmacy web app (fictional). Your colleague Omar ran the guide’s test routine on the search results page with one pairing, NVDA with Firefox, and wrote down exactly what he heard. Before he files bugs, you review his log against the page’s markup. The material below gives the task in scope, a markup extract, what the scripts do, and the log. Announcements are quoted in English because the page under test is the English UI.
Work on paper with the guide’s name computation order, its test cases SR-01 to SR-12 and the WCAG 2.2 criteria it cites. Not every row is a failure, and not every problem is a WCAG failure: say which is which. If you have NVDA or VoiceOver, you can save the extract as a local HTML file and listen to the names and roles yourself; the wording will differ, the findings should not. Allow 30–45 minutes.
Dawa - online pharmacy web app (fictional). English UI; an Arabic UI also exists.
Page under test: search results, staging build 3.8.0, a single-page application.
The page has a header and main content only: no navigation menu, footer or dialog.
Task in scope: on the results for "vitamin D", filter to 1000 IU and add one pack
of the first product to the cart.
Pairing: NVDA with Firefox on Windows 11 (the tester did not note versions).
Announcements are written as name, role, state, as in the guide; real wording and
order differ between screen readers and versions.
Markup extract (one product card shown; the other 11 use the same template)
<html lang="ar">
<head><title>Dawa</title></head>
<body>
<header>
<a href="/"><img src="/img/logo.svg" alt="Dawa home"></a>
<button class="icon" onclick="openSearch()"><svg class="i-search"></svg></button>
</header>
<main>
<h1>Results for vitamin D</h1>
<p id="count">12 products</p>
<div class="toggle" role="button" tabindex="0" aria-expanded="false"
onclick="toggleFilters()">Filters</div>
<div id="filters" hidden>
<label><input type="checkbox" onchange="applyFilter()"> 1000 IU</label>
</div>
<ul class="products">
<li>
<img src="/p/IMG_4021.jpg" alt="IMG_4021.jpg">
<div class="card-title">Vitamin D3 1000 IU, 60 tablets</div>
<p>SAR 39.00</p>
<a href="/p/4021">Details</a>
<button aria-label="Buy now" onclick="addToCart(4021)">Add to cart</button>
</li>
</ul>
</main>
</body>
</html>
What the scripts do (from the developer)
toggleFilters() shows or hides #filters; changes nothing else
applyFilter() reloads the list and replaces the text of #count, e.g. "4 products"
addToCart(id) on success appends this element to body, removes it 3 s later:
<div class="toast" role="status">Added to cart</div>
On screen, the product name (.card-title) is large and bold and looks like a heading.
Session log (tester: Omar)
1 Load the page Opened the results from the home page, then NVDA+T (read title).
Heard: "Dawa" and the browser name. The English text that
follows is read with an Arabic voice and is hard to understand.
2 Headings list NVDA+F7, Headings. One item: "Results for vitamin D", level 1.
3 Landmarks D, then D. Heard: "banner landmark", "main landmark".
4 Links list NVDA+F7, Links. Heard: "Dawa home", then "Details" 12 times.
5 Read in order Down Arrow through the first card. Heard: "list, 12 items",
"IMG_4021.jpg, graphic", "Vitamin D3 1000 IU, 60 tablets",
"SAR 39.00", "Details, link", "Buy now, button".
6 Operate controls Tab to the search icon. Heard: "button".
Tab to Filters. Heard: "Filters, button, collapsed".
Enter: the filter panel opens on screen.
Shift+Tab, then Tab. Heard: "Filters, button, collapsed".
7 Dynamic changes Space on the 1000 IU checkbox.
Heard: "1000 IU, checkbox, checked". On screen the count
changes to "4 products"; nothing else is heard.
8 Dynamic changes Enter on "Buy now" in the first card. On screen: "Added to cart"
for 3 seconds. Nothing heard, so Omar pressed Enter again.
9 Complete task Cart page: "Vitamin D3 1000 IU, 60 tablets" x 2.
Omar’s note: "Nothing told me that it worked."- Before reading the log, write from the markup alone what each image and control exposes — name, role and state: the logo link, the search icon, Filters before and after opening, the product image, Details and Add to cart. Use the guide’s name order:
aria-labelledby,aria-label, native label, content, fallbacks. - Compare the log with your predictions row by row. For each row write pass or fail, the SR test case, the WCAG 2.2 success criterion where one applies, the cause in the markup, and the announcement you expected.
- Write a bug title in the guide’s style for each failure, and a complete report body for the search icon: pairing with versions, steps, what was heard and what was expected.
- Decide SR-12 for the task in scope, and name the findings that make the task fail or go wrong.
- List what must be added or checked before the bugs are filed, and what to test next.
Show the model answer
Predictions from the markup. Logo link: the name comes from the image’s alt, so "Dawa home, link". Search icon: a button that contains only an svg, with no aria-labelledby, no aria-label, no text and no title, so it has no name and is announced as "button". Filters: "Filters, button, collapsed", and it stays collapsed, because toggleFilters() never changes aria-expanded. Product image: the alt is the file name, so "IMG_4021.jpg, graphic". Product name: plain text, not a heading. Details: "Details, link", identical on all twelve cards. Add to cart: aria-label comes before content in the name order, so the name is "Buy now", not the visible "Add to cart". Result count and toast: no live region is in the page before the text changes, so nothing is announced. Omar’s log matches every prediction. This is why the guide says to look at the computed name, role and states in the accessibility pane before you listen: the markup explains what you hear.
Row 1 shows two failures. SR-01 fails, 2.4.2 Page Titled: the results view, opened from the home page, still has the shell’s title "Dawa", which names the site but not the view; expected a title that names the view, such as "Results for vitamin D - Dawa", set on every route change. SR-02 fails, 3.1.1 Language of Page: the English UI declares lang="ar", so NVDA reads English text with an Arabic voice; expected lang="en" on the English UI and lang="ar" on the Arabic UI, updated when the user switches language. Both come from the app shell, so they most likely affect every view and are fixed in one place.
Rows 2 to 4. Row 2: SR-03 fails, 1.3.1 Info and Relationships: the product names look like headings but are div elements, so the headings list holds only the h1; expected the h1 followed by the twelve product names as level 2 headings. Row 3: SR-04 passes — the page has only a header and main content, both are landmarks, and no landmark type appears twice, so none needs a label. Row 4: "Dawa home" passes SR-05. "Details" twelve times is a judgement call. Each link sits in the same list item as its product name, which is a programmatically determined context, so 2.4.4 Link Purpose (In Context), a level A criterion, is met; links that are clear from their text alone are required only by 2.4.9 Link Purpose (Link Only), level AAA. Unless your target includes AAA, record it as an improvement rather than a WCAG failure, because the links list is still useless for choosing a product, and suggest a name that starts with the visible text, such as "Details: Vitamin D3 1000 IU, 60 tablets". Twelve "Read more" links with no such context, as in the guide’s example, would fail 2.4.4.
Row 5: the list with its 12 items, the product name and the price are read in order — pass. The image fails SR-07, 1.1.1 Non-text Content: a file name is not a text alternative. Expected an alt that serves the image’s purpose, such as "Vitamin D3 1000 IU, 60 tablets, pack", or alt="" if the team decides the image only repeats the product name beside it. Either is acceptable; the file name never is. It is one defect in the card template, not twelve. The other two announcements in row 5, "Details, link" and "Buy now, button", are covered under row 4 and under Add to cart below.
Row 6. The search icon fails SR-06, 4.1.2 Name, Role, Value: expected "Search, button", for example through aria-label="Search" or visually hidden text; the header is on every page, so every page is affected. Filters fails SR-08 and the same criterion: the panel opens but the state stays "collapsed"; expected "Filters, button, expanded" after opening and "collapsed" after closing. The markup shows a second risk: a div with role="button" and only onclick has no key handling, because ARIA roles add no behaviour. In browse mode NVDA can activate an element by sending it a click, so the toggle may work with the screen reader and still fail for keyboard users. Repeat with the screen reader off; if Enter and Space do nothing, file a separate defect under 2.1.1 Keyboard, as described in the keyboard accessibility guide. One fix covers both: a native button element whose aria-expanded the script updates — the first rule of ARIA use.
Add to cart (rows 5 and 8) fails SR-06, 2.5.3 Label in Name: the visible label is "Add to cart" but the name is "Buy now", because aria-label overrides the button’s text. A voice-control user who says "Click Add to cart" gets no match, and a screen reader user hears an action that sounds like an immediate purchase. Expected a name that starts with the visible label: "Add to cart, button" at minimum, or "Add to cart: Vitamin D3 1000 IU, 60 tablets, button", which also tells the twelve buttons apart.
Rows 7 and 8 fail SR-09, 4.1.3 Status Messages, for two different reasons. The checkbox itself passes ("1000 IU, checkbox, checked"), but the count is a plain paragraph with no status role, so its change is never announced; expected "4 products" announced politely while focus stays on the checkbox, for example by giving the count role="status" from page load. The toast does have role="status", but the script adds the region and its text at the same moment, so it is not reliably announced; expected "Added to cart" announced politely while focus stays on the button, by keeping an empty status region in the page from load and writing the message into it.
Row 9: record SR-12 as failed. The product can be added, but nothing confirms it, so Omar added it twice and found the wrong quantity only on the cart page; a user who trusts the page orders two packs. The findings behind this are the silent toast, the "Buy now" name, which makes the button’s effect unclear, and, earlier in the task, the silent result count and the wrong Filters state. The unnamed search icon is not on this task’s path, but it stops a screen reader user from starting a new search from this page.
Bug titles: (1) "Header search icon button is announced as button with no name" — 4.1.2. (2) "Add to cart buttons are announced as Buy now" — 2.5.3. (3) "Added to cart message is not announced; users add the product twice" — 4.1.3. (4) "Result count is not announced after applying a filter" — 4.1.3. (5) "Filters toggle is announced as collapsed after the panel opens" — 4.1.2. (6) "Product names are styled div elements; the headings list shows only the h1" — 1.3.1. (7) "Product images are announced by file name, for example IMG_4021.jpg" — 1.1.1. (8) "English UI declares lang="ar"; NVDA reads English text with an Arabic voice" — 3.1.1. (9) "Page title stays Dawa on the search results view" — 2.4.2. Improvement: "Details links in product cards cannot be told apart in the links list". After the keyboard check, if confirmed: "Filters toggle does not respond to Enter or Space" — 2.1.1.
Report body for (1). Environment: NVDA (version) with Firefox (version) on Windows 11 (version), staging build 3.8.0. Steps: open the results page for vitamin D; press Tab until focus reaches the search icon in the header. Heard: "button". Expected: "Search, button" (SR-06, 4.1.2 Name, Role, Value). Evidence: the accessibility pane shows role button and an empty name. Scope: the header is on every page.
Before filing: add the versions of NVDA, Firefox and Windows that the log leaves out, because behaviour changes between versions; confirm each computed name in the accessibility pane; check the title and language on one more view, such as the home page, to confirm the scope of (8) and (9); and run the keyboard-only check of the Filters toggle. Next: repeat the routine on the other pairings in the support baseline, such as VoiceOver with Safari on iOS and TalkBack with Chrome on Android for the mobile web, and on the Arabic UI, where lang="ar" is correct and you check that Arabic text is read with the Arabic voice and that prices and mixed Arabic-English strings are read in a sensible order. After the fixes: confirmation testing of each defect on the same pairing, and regression testing of the other pages that use the header and the product card.
If your answers differ, check each finding for four parts: what was heard, what was expected, the cause in the markup and the criterion. Reasonable variations: alt="" instead of a descriptive alt for the product image, or "passed with findings" for SR-12 if your team uses that result, as long as the double add is reported. Two answers are not correct here: recording "Details" as a 2.4.4 failure, because the list item supplies the context, and recording nothing for it, because links-list users still cannot tell the links apart.
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
Next topics
Tools mentioned in this guide
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.