Blank checklist, printable form
Assistive Technology Interoperability Testing Checklist
EN 301 549 §5.1 + §11.5 Compatibility Checklist
Blank checklist for offline completion.
Tick one box per row. Add comments and evidence references in the Notes column as needed.
Screen Readers, Cross-Platform
Verify compatibility with the major screen readers across all platforms, Windows, macOS, iOS, and Android.
| Ref | Severity | Requirement | Status | Notes / Evidence |
|---|---|---|---|---|
| EN 301 549 §11.5.2 | Critical | Tested with NVDA on Windows.NVDA is the most widely used free screen reader on Windows. Test all core user journeys, navigation, forms, interactive components, and dynamic content. NVDA uses the virtual buffer and browse/focus modes; verify both work correctly with your interface. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A | |
| EN 301 549 §11.5.2 | Critical | Tested with JAWS on Windows.JAWS is the most widely used commercial screen reader in enterprise environments. Its interaction model differs from NVDA in key areas, virtual cursor behaviour, forms mode activation, and verbosity settings. Test separately even if NVDA passes. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A | |
| EN 301 549 §11.5.2 | Critical | Tested with VoiceOver on macOS and iOS.VoiceOver is built into macOS and iOS. Test with Safari on both platforms as it provides the best VoiceOver support. On iOS, test touch-based navigation (swipe left/right) and rotor gestures. VoiceOver handles ARIA differently from Windows screen readers in several areas. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A | |
| EN 301 549 §11.5.2 | Critical | Tested with TalkBack on Android.TalkBack is Android's built-in screen reader. Test with Chrome on Android as it has the best TalkBack support. Navigation is via swipe gestures (similar to VoiceOver iOS). Pay attention to custom views, WebView content, and touch target sizes. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A |
Screen Magnification & Low Vision
Verify functionality with browser zoom, system magnifiers, high contrast modes, and colour inversion, critical for low vision users.
| Ref | Severity | Requirement | Status | Notes / Evidence |
|---|---|---|---|---|
| WCAG 1.4.4 | Critical | All functionality works at 200% browser zoom.WCAG requires content to be functional and readable at 200% zoom. No horizontal scrolling should be required for vertical-scrolling content. Text must reflow rather than being clipped or overlapping. All interactive elements must remain accessible. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A | |
| EN 301 549 §11.5.2 | Major | Content remains functional with ZoomText or system magnifier.ZoomText (Windows) and the built-in system magnifiers (Windows Magnifier, macOS Zoom) enlarge portions of the screen. Content must remain usable, tooltips and popups must appear near their triggers (not off-screen), and focus indicators must be visible at high magnification levels. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A | |
| WCAG 1.4.11 | Critical | Interface is usable in Windows High Contrast Mode and macOS increased contrast.High contrast modes override colours and can remove background images, gradients, and shadows. UI elements that rely on these visual treatments for meaning or boundaries may become invisible. Use transparent borders and CSS forced-color-adjust where needed. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A | |
| WCAG 1.4.1 | Major | Content remains readable with inverted colours.Some low vision users invert display colours to get light text on dark backgrounds. Content must remain legible and images should not become unusable. Avoid conveying information through colour alone, as colour relationships reverse when inverted. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A |
Motor & Alternative Input
Verify compatibility with switch access, voice control, full keyboard operation, and dwell/eye-tracking input methods.
| Ref | Severity | Requirement | Status | Notes / Evidence |
|---|---|---|---|---|
| EN 301 549 §5.1.3 | Critical | Switch access (iOS Switch Control / Android Switch Access) can navigate all functions.Switch access users navigate by scanning through elements sequentially and activating with one or two switches. All interactive elements must be reachable via the scanning order. Custom components must be focusable and activatable. Group related elements to reduce scanning time. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A | |
| EN 301 549 §5.1.3 | Critical | Voice control (Dragon NaturallySpeaking / macOS Voice Control) can activate all controls.Voice control users say the visible label or name of a control to activate it. All interactive elements must have visible text labels or accessible names that users can speak. 'Click Submit' must work for a button labelled 'Submit'. Custom controls without visible labels are unusable. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A | |
| WCAG 2.1.1 | Critical | All functionality is accessible via keyboard without requiring a mouse.Every feature available via mouse must be equally available via keyboard. This includes navigation, form completion, drag-and-drop alternatives, context menus, and dismissing overlays. Focus must be visible at all times and follow a logical order. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A | |
| WCAG 2.5.1 | Major | No hover-dependent interactions, compatible with dwell and eye-tracking input.Dwell clickers and eye-tracking systems activate elements by hovering over them for a set duration. If your interface shows important content or controls only on mouse hover, dwell users will trigger them unintentionally or be unable to access them. All hover-revealed content must be accessible via click/focus. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A |
Hearing Assistive Technologies
Verify compatibility with hearing aids, hearing loops, and ensure visual alternatives exist for all audio content.
| Ref | Severity | Requirement | Status | Notes / Evidence |
|---|---|---|---|---|
| EN 301 549 §5.1.5 | Major | Audio output is hearing aid streaming compatible (Bluetooth LE Audio / MFi).If your product outputs audio (videos, alerts, voice calls), it must be receivable through hearing aids and cochlear implants. Bluetooth LE Audio and Made for iPhone (MFi) are the primary streaming protocols. Web content generally streams via the device audio output, but verify no custom audio handling bypasses the system audio path. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A | |
| WCAG 1.2.1 | Critical | Visual alternatives are provided for all audio cues and alerts.Every sound, notification chimes, error beeps, success tones, incoming message sounds, must have a visual equivalent. Deaf and hard-of-hearing users must receive the same information visually. Use on-screen notifications, icon changes, or vibration alongside audio cues. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A | |
| WCAG 1.2.4 | Critical | Captions are compatible with hearing loop (telecoil) systems.In public settings, hearing loops transmit audio directly to hearing aids via telecoil. For web-based presentations or kiosks used in loop-equipped venues, ensure captions are available as a backup and that audio output can feed into loop amplifiers. Captions must be accurate and synchronised. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A | |
| WCAG 1.4.2 | Major | Volume is adjustable independently of system volume.Users with hearing impairments may need to set media volume differently from system sounds. All audio content on the site should have independent volume controls. Auto-playing audio must be avoidable. Users must be able to pause, stop, or adjust volume of any audio that plays for more than 3 seconds. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A |
Braille & Cognitive AT
Verify compatibility with braille displays, braille navigation, text simplification tools, and reading aids.
| Ref | Severity | Requirement | Status | Notes / Evidence |
|---|---|---|---|---|
| EN 301 549 §11.5.2 | Major | Braille display correctly renders all content.Braille displays convert on-screen text to braille cells. Content must be available as real text (not images of text or canvas-rendered text). Special characters, mathematical symbols, and emoji must either render correctly in braille or have text alternatives. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A | |
| EN 301 549 §11.5.2 | Major | Braille display routing keys work with all interactive elements.Braille displays have routing keys above each cell that allow users to click on the element displayed at that cell position. All interactive elements (links, buttons, form fields) must be activatable via routing keys. Custom widgets must expose their interactive nature to the accessibility API. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A | |
| EN 301 549 §5.1.3 | Minor | Content is compatible with text-to-speech simplification tools.Cognitive accessibility tools like Browsealoud, Rewordify, and built-in browser simplification features rely on well-structured HTML to simplify content. Use semantic headings, short paragraphs, lists for sequential information, and avoid complex nested layouts that confuse content extraction. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A | |
| EN 301 549 §5.1.3 | Minor | Compatible with reading rulers and focus highlight tools.Reading rulers, line guides, and focus highlight overlays help users with dyslexia and attention disorders track their reading position. These tools overlay a coloured bar or dim surrounding content. Your site must not interfere with these overlays, avoid high z-index elements that cover the overlay, and ensure content reflows correctly. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A |