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.

Bridging the Gap: Language Support for Non-Native Developers

The goal of accessibility testing isn’t just about ticking boxes on a checklist; it’s about ensuring that everyone can use a product effectively. That means communicating clearly and precisely, especially when documenting issues found during audits or reporting results to other developers. For non-native English speakers navigating the world of technical writing and accessibility, this can feel particularly challenging. It’s not just about translating words; it’s about understanding the nuance of professional communication – the subtle ways in which language is used to convey authority, suggest solutions, and collaborate effectively. Let’s consider how you might frame a problem for your team. Instead of simply stating “Button lacks alt text,” a more helpful approach would be: “The primary button on this form currently doesn’t have associated alternative text; this violates WCAG 1.1.1 (Non-text Content) and could significantly impede the experience for users relying solely on screen readers.” Notice the added context – referencing the specific success criterion demonstrates your understanding of the issue’s impact.

Another common pitfall is using overly literal translations. Phrases like “the website is not accessible” are often too blunt and don’t convey the seriousness of the situation. A better phrasing would be: “We identified several instances where the current design doesn’t fully meet WCAG guidelines, specifically regarding keyboard navigation and color contrast.” This approach focuses on what needs to be done rather than simply stating what’s wrong. Similarly, when drafting a pull request description, instead of saying “Fix accessibility,” try something like: “This PR addresses identified accessibility issues related to form labeling and screen reader compatibility, ensuring compliance with WCAG 2.1 Level AA standards.” The use of specific terms – ‘form labeling,’ ‘screen reader compatibility’ – immediately signals the scope of the work and demonstrates familiarity with relevant guidelines.

Furthermore, remember that constructive feedback is crucial. When discussing an issue with a colleague, avoid accusatory language. Instead of saying “You made this inaccessible,” try: “I’ve noticed some challenges with screen reader navigation in this section. Could we explore ways to improve the semantic structure and ARIA attributes to enhance accessibility?” This softer approach fosters collaboration and encourages a solution-oriented mindset. Don’t be afraid to ask for clarification – if you don’t understand a term or phrase used by a native speaker, politely request an explanation. “Could you elaborate on what you mean by ‘keyboard focus order’ in this context?” is perfectly acceptable.

Finally, pay attention to the tone of your writing. Accessibility reports should be professional and objective, focusing on the technical details rather than personal opinions. Maintaining a clear, concise, and well-structured style will significantly improve understanding and facilitate effective collaboration within your team. Remember, clarity in language directly translates to clarity in action – helping ensure that accessibility improvements are implemented efficiently and effectively.