English for WCAG and Screen Reader Testing Reports

Writing up an accessibility finding clearly is different from writing a general bug report — you need to reference a specific WCAG success criterion, describe what assistive technology encountered, and explain the actual impact on a user, not just what looks wrong visually. This guide covers the English for structuring these findings so they get prioritized and fixed.

Key Vocabulary

WCAG success criterion — a specific, numbered testable requirement from the Web Content Accessibility Guidelines (e.g., “1.1.1 Non-text Content”), used to anchor a finding to an official standard rather than personal opinion. “This fails WCAG 2.1 success criterion 1.4.3 (Contrast Minimum) — the text color has a contrast ratio of 2.8:1 against the background, below the required 4.5:1.”

Screen reader announcement — the actual text or description a screen reader speaks aloud when a user navigates to an element, which is often different from what’s visually shown. “The screen reader announces this button simply as ‘button’ with no label, because the icon has no accessible name.”

Accessible name — the text a screen reader uses to identify an interactive element, computed from visible text, aria-label, alt text, or similar sources. “The icon-only delete button has no accessible name — we need to add an aria-label=\"Delete item\" so screen reader users know what it does.”

Focus order — the sequence in which interactive elements receive keyboard focus when a user tabs through a page, which should match the logical reading order. “Focus order jumps from the search field directly to the footer, skipping the entire results list — this breaks keyboard navigation for anyone not using a mouse.”

Assistive technology (AT) — software or hardware that helps users with disabilities interact with digital content, including screen readers, switch devices, and voice control software. “We tested this flow with two assistive technologies: VoiceOver on macOS and NVDA on Windows, since screen reader behavior can differ between them.”

Common Phrases

• “This fails WCAG [version] success criterion [number] ([name]).”
• “Tested with [screen reader name] on [OS] — the announcement was [what it says].”
• “The accessible name for this element is missing/incorrect.”
• “Keyboard-only users cannot [specific action] because [specific reason].”
• “Impact: a screen reader user would not know that [specific consequence].”

Example Sentences

Writing a finding with the standard structure — criterion, observation, impact: “Finding: The ‘Submit’ button has insufficient color contrast (2.1:1) against its background, failing WCAG 2.1 SC 1.4.3 (Contrast Minimum, requires 4.5:1). Impact: users with low vision may not be able to perceive that the button is present or interactive.”

Describing what a screen reader actually announced, not just what’s visible: “Tested with VoiceOver on macOS Safari. When focus moves to the pricing toggle, VoiceOver announces only ‘switch, off’ with no indication of what the switch controls. A sighted user sees the label ‘Annual billing’ next to it, but that text is not programmatically associated with the control.”

Distinguishing a visual bug from an accessibility bug in a report: “This is not a visual bug — the layout looks correct on screen. The issue is that the modal dialog does not trap keyboard focus, so a keyboard-only user can tab out of the open modal into content behind it, which is disorienting and can lead to unintended actions.”

Prioritizing findings by impact rather than severity alone: “I’d prioritize the missing form labels over the heading order issue. The missing labels block screen reader users from completing the signup form at all, while the heading order issue makes navigation less efficient but doesn’t block task completion.”

Professional Tips

• Always cite the specific WCAG success criterion by number and name — it turns a subjective opinion into a testable, referenceable requirement that’s hard to dismiss.
• Report the exact screen reader and platform combination you tested with (e.g., “NVDA on Windows with Chrome”) — behavior genuinely differs across combinations, and this detail helps others reproduce the finding.
• Quote the actual announcement text, not a paraphrase — “it announces ‘button’ with no label” is more useful to a developer than “the button isn’t labeled well.”
• Separate the observation (what happened) from the impact (what a user with a disability actually can’t do) — both matter, and impact is usually what gets a finding prioritized.
• When triaging multiple findings, prioritize by whether it blocks task completion, not just by how visually obvious the issue is.

Practice Exercise

1. Write a finding citing a specific WCAG success criterion, an observation, and an impact statement.
2. Write a sentence quoting the exact text a screen reader announced for a broken element.
3. Write a one-sentence justification for prioritizing one accessibility finding over another.