Part 2 – Web Accessibility: Your guide to comprehensive website testing

Accessibility Testing – 

Automated Assessment:

Automated testing tools can scan websites or mobile applications to identify errors across numerous pages based on WCAG standards. This approach can potentially uncover up to 57% of accessibility concerns.

1. VS Code Plugin – The axe Accessibility Linter plugin for VS Code assists developers by conducting real-time code analysis, ensuring adherence to common accessibility best practices. (Recommended)
Link: Axe Accessibility Linter

2. WAVE serves as a web accessibility evaluation tool developed by WebAIM. It offers visual feedback on your web content’s accessibility by embedding icons and indicators within your page.
Link: WAVE Evaluation Tool

3. Axe Devtools offers an automated and guided accessibility testing solution designed for component developers, front-end developers, native mobile app developers, and test engineers. It enables swift identification and correction of nearly all accessibility issues before your applications progress beyond the development phase.
Link: Axe DevTools

4. Lighthouse, a Chrome development tool, provides a comprehensive report. To analyze a webpage, navigate to it, right-click on the screen, choose “Inspect Element,” select the “Lighthouse” tab, check “Accessibility,” and then click “Generate Report.”

Manual Assessment: 

Manual examination plays a pivotal role in accessibility testing due to the fact that 80% of WCAG success criteria necessitate manual assessment, and certain aspects are beyond the scope of automated testing.

1. Keyboard Navigation –

⇒ How to conduct a keyboard test?

– Tab: Access form controls and links.
– Shift + Tab: Navigate backward.
– Spacebar: Activate checkboxes and buttons.
– Enter: Trigger buttons and links.
– Arrow keys: Interact with tree menus, auto-complete, radio buttons, select/drop-down menus, sliders, tab panels, etc.
– Escape: Close browser menus or dialog boxes.

⇒ What to assess?

– Any mouse-dependent features like hover menus?
– Presence of “skip navigation” link; test its functionality.
– Logical and intuitive navigation sequence.
– Visible keyboard focus indicator.
– Test pop-up dialogs for navigation and closure.
– Ensure ‘Esc’ closes all dialogs.

2. Non-Visual Navigation with a Screen Reader: Employ a screen reader to identify problems related to reading sequence, spelling, dynamic elements, and interactive components. Despite its initial complexity, this is an essential stage in assessing the accessibility of content.

Free screen readers:
– NVDA for PC
– VoiceOver for Mac

3. Manual Content Review 

⇒ BODY TEXT
– Verify unique, descriptive page titles marked as <h1>. Only one <h1> per page.
– Check meaningful visual headings marked as <h> elements in hierarchical order (<h1>, <h2>, etc.). Avoid skipping heading levels.

⇒ IMAGES
– Ensure “alt” text conveys non-decorative image content and function concisely and accurately.
– Confirm images of text have corresponding textual representation.

⇒ COLOR
– Check text-background color contrast ratio (at least 4.5:1).
– Avoid using color as sole information conveyance.

Link: WebAIM Contrast Checker

⇒ TABLES
– Limit table usage to tabular data, not layout.
– Verify table caption and row/column headers for data tables.

⇒ FORMS
– Assign descriptive labels to form controls.
– If labels aren’t visible, check for hidden <label>, aria-label, or title attribute.

⇒ ZOOM IN TO 200%
(Windows users use Control +, Mac users use Command +)

– Assess content visibility, order, and overlapping.
– Examine navigation bars, mobile-style menus, and scrolling behavior.
– Ensure functionality of links, buttons, forms, and menus with content zoomed.

⇒ USABILITY
– Confirm basic, legible fonts for readability.
– Maintain consistency and logic in visual navigation.

⇒ NON-AUDIO ACCESS
– Control audio/video start options.
– Include accurate captions and transcript links for videos.

⇒ DOWNLOADABLE FILES
– Ensure searchable, tagged, and OCR’d PDFs, Word docs, and PPTs with relevant alt text.

Reference : 

• https://uit.stanford.edu/accessibility/testing/manual-checks

From the next blogs onwards, we will see some examples of how we can debug and implement the Aria Accessibility.

Link to Part 3 – Web Accessibility: Practical Approaches to Implement accessibility using Axe tool