How to make an accessibility review?

Understanding how accessible your module, theme, or site is can feel overwhelming. If you're new to accessibility, the topic alone can leave you wondering where to start. Accommodating a wide range of abilities means considering a diverse range of factors. This documentation outlines essential considerations in a logical, step-by-step process for checking the accessibility of your module's theme or site.

Start with Automated Tools

Many accessibility issues can be detected by running the page through automated tools. Some of these tools include WAVE, Tenon, Accessibility Insights, Google Lighthouse, Siteimprove, and the Siteimprove Accessibility Checker Chrome extension. Some parts can be automated using axe-core. These tools help identify issues like incorrect markup structure, missing ARIA attributes, and poor color contrast.

Keyboard Navigation Testing

Keyboard navigation is essential for users who cannot or choose not to use a mouse. This includes screen reader users and those with motor disabilities like RSI or paralysis. To ensure a good keyboard experience, maintain logical tab order and clearly visible focus styles. Also ensure users are not forced to tab through excessive elements.

What to Look For

• Can you skip repetitive content?

A skip link should be provided to jump directly to unique page content, bypassing repeated navigation. It should be the first tab stop and visible when focused.

• Are all controls fully operable?

Every interactive element should be usable via keyboard. This includes expand/collapse, trees, sliders, dialogs, overlays, drag-and-drop — or provide an alternative method.

• Can you tab in both directions?

Some apps allow forward tabbing but break backward tabbing (Shift + Tab), causing a keyboard trap. Ensure users can tab through interfaces in both directions.

• Are there any keyboard traps?

Make sure focus is not completely locked. Can users dismiss overlays, modals, or autocomplete widgets using only the keyboard? If not, you've created a trap.

• Is focus confined in dialogs?

Keyboard focus should stay inside dialogs. Otherwise, users may navigate beyond it without visual feedback.

• Is focus always visible?

All interactive or input elements should be focusable and show a visible focus indicator, such as a focus ring. Users must be able to see what element they are on.

• Is there invisible content accessible by keyboard?

Ensure there is no hidden content that remains in the tab order unnecessarily.

• Are hover-only elements accessible via keyboard?

Use a mouse to find hover-only content. It should also be accessible using keyboard navigation. This benefits keyboard and touch users alike.

• Are non-interactive elements focusable?

- Non-interactive content should not be focusable.
- Don’t use tabindex="0" unless the element is meant to be interacted with.
- Avoid unnecessary tabindex on static content as it adds navigation burden.

• Is the tab order logical?

Tab order should match the logical reading order. Avoid disrupting DOM flow with CSS that confuses tabbing sequence.

Re-check at Breakpoints

After running keyboard tests, zoom the browser to trigger breakpoints and test again. High-zoom users on laptops may interact with the tablet/mobile view. Breakpoints matter beyond touch users.

Headings

Headings are the backbone of your content. A good heading structure reflects the page's layout, like a book index. Descriptive and hierarchical headings are vital for screen reader users who use them to navigate.

What to Look For

• Is there only one H1 per page?

Each page should have a single H1 that describes the page’s main purpose.

• Are heading levels consistent with content hierarchy?

Use heading levels to reflect structure, not styling. Don’t skip heading levels.

• Are headings descriptive?

Good headings briefly describe the section that follows.

Color and Contrast

Sufficient Color Contrast

Text should have a contrast ratio of 4.5:1 or higher against the background. Use color contrast checkers to verify this.

Color Alone Should Not Convey Information

Color can’t be the only means of conveying important information. Add text or icons to reinforce meaning. For form errors, don’t just say "fields marked in red"; include field names and recognizable error icons. Adding asterisk symbols for required fields helps those with color vision deficiencies. Focus states should use more than color, such as outlines.

Not Just Icons

Icons representing key functions should include a text label describing their purpose. Make sure interactive elements like menus are labeled. Icon meanings aren't always intuitive. Labels help screen reader users as well.

Audio and Video

If your page uses audio or video for conveying information, provide captions or transcripts. See WebAIM’s guide on captions, transcripts, and audio descriptions.

• Informative videos with or without sound should have transcripts for visually impaired users.
• Informative videos with sound should include captions for hearing-impaired users.
• Complex videos with sound may need audio descriptions for blind users to understand scene context.
• Live video must include captions.
• Live audio must have a text alternative for users with hearing impairments.

This follows WCAG Guideline 1.2: Time-based Media.

Autoplaying Animation, Video, and Audio

Autoplaying content can distract users. Avoid assuming where users are focusing.

• Animations: e.g., carousel rotating through images.
• Autoplaying video: e.g., YouTube video that plays on page load.
• Autoplaying audio: e.g., radio stream starts on load.

To reduce distractions:

• Avoid autoplaying content over 5 seconds.
• Provide controls to stop, play, and pause content.

Dynamically Changing Content

JavaScript can change parts of the page without full reloads. Users must be notified of such updates. Examples include search result updates or non-interactive notifications. Use Drupal.announce() to announce changes to assistive tech. This API is based on ARIA live regions.

The best way to test dynamic content is with a screen reader.

Screen Reader Testing

Automated and manual keyboard checks cover many issues. However, screen reader testing reveals others.

What to Look For

• Do all controls have labels?

Controls must be labeled to describe their function. Often this is done with a label element, but complex cases may use aria-labelledby.

• Are custom controls labeled with proper ARIA roles and states?

Users with assistive tech need access to visual information like formatting and states. Native elements handle this, but custom ones need ARIA attributes (e.g., a slider should use role="slider" and attributes like aria-valuenow, aria-valuemin, aria-valuemax).

• Does the information flow make sense and match the visual order?

CSS can rearrange layout. Does the content order still make sense when read linearly?

• Are link texts meaningful?

Screen readers prefix "link" before each link. Avoid redundant words like "link to" and ambiguous texts like "click here" or "read more." Links should make sense out of context.

• Do all images have appropriate alt text?

Images must have alt text unless purely decorative. To hide from screen readers, use empty alt text (alt="").

Manual Screen Reader Testing

Some issues only show during screen reader use. Popular readers include VoiceOver (macOS) and NVDA (Windows). To start with VoiceOver, watch this video and review WebAIM’s guide. For NVDA, watch this tutorial and read Marco Zehe’s guide.

Once familiar, try turning off your monitor and hiding your mouse. Pronunciation is not part of testing.

If you're new to screen readers, testing isn’t as simple as it sounds. It takes time to learn non-visual navigation and screen reader shortcuts. Each reader works differently, so test across multiple tools, browsers, and platforms.