Accessibility Testing Process for Individual Components

[myrta2302]

Purpose

Establish a commonly accepted testing process to ensure all Next Level components comply with WCAG/ARIA standards.
Document the process to save implementation and review time.

Testing Scope: What do we check?

• HTML Structure & Semantics
• Headings
• ARIA roles, states, and properties
• ARIA labels, descriptions
• Forms & Inputs
• Interactive behavior (mouse, focus, dynamic updates. keyboard accessibility)
• Screen Reader Compatibility

Do we also check for design-related issues?

• Colors
• Contrast
• etc...

Suggested Steps

1. Align on Testing Scope

2. Define a list of Accessibility Testing Tools (*suggestions to be revised)

Browser Extensions
• axe DevTools
• Siteimprove
• Accessibility Insights
• Lighthouse
• Aria DevTools
• HeadingsMap
• WAVE

Bookmarklets
• Tota11y tota11y – an accessibility visualization toolkit
• h123 - An bookmarklet that shows headings like a screenreader (Accessbility)
• HTML_CodeSniffer
• Bookmarklet: Contents Structured

Screen Readers
• NVDA for Windows
• Narrator for Windows
• VoiceOver for Apple devices (macOS and iOS)
• TalkBack for Android devices

Other
Accessibility Addon for Storybook -> Accessibility | Storybook integrations

3. Define a checking process (e.g. a shared .xls?)

Example -> Components Accessibility Check.xlsx