Skip to content

Coding for accessibility: Screen readers

kevinginley edited this page Jun 29, 2024 · 1 revision

Creating an accessible experience for users with vision impairments involves following best practices and adhering to WCAG (Web Content Accessibility Guidelines) standards. Here’s a step-by-step guide for front-end developers to ensure their applications are screen reader accessible:

1. Semantic HTML structure

  • Use semantic HTML5 elements (<header>, <nav>, <main>, <section>, <article>, <aside>, <footer>) to structure your content appropriately.
  • Semantic elements help screen readers understand the organization and hierarchy of your content.

2. Ensure all images have alternative text

  • Every <img> tag must have an alt attribute that describes the content of the image.
  • Use empty alt="" for decorative images that do not convey meaningful content.

3. Accessible forms

  • Label form elements (<label> tags) properly using the for attribute to associate labels with their inputs.
  • Provide helpful instructions and error messages near form controls.

4. Keyboard navigation

  • Ensure all interactive elements (links, buttons, form controls) can be accessed and activated using only the keyboard (Tab key).
  • Focus should be visible and move logically through interactive elements.

5. ARIA (Accessible Rich Internet Applications) roles and attributes

  • Use ARIA roles and attributes to enhance accessibility where semantic HTML alone is insufficient.
  • Examples:
    • role="navigation", role="button", role="menu", etc.
    • aria-label, aria-labelledby, aria-describedby, etc.

6. Focus management

  • Manage focus to ensure it moves logically through your application.
  • Avoid traps where users can get stuck or lose context.

7. Testing

  • Use accessibility tools and screen readers during development.
  • Test with real users who have disabilities to get feedback on usability.

Example code snippets:

Semantic HTML example:

<header>
  <h1>Website Title</h1>
  <nav>
    <ul>
      <li><a href="#">Home</a></li>
      <li><a href="#">About</a></li>
      <li><a href="#">Contact</a></li>
    </ul>
  </nav>
</header>
<main>
  <section>
    <h2>Section Heading</h2>
    <p>Content goes here.</p>
  </section>
</main>
<footer>
  <p>&copy; 2024 Company Name. All rights reserved.</p>
</footer>

Image with alt text example:

<img src="example.jpg" alt="Description of the image">

Accessible form example:

<form>
  <label for="username">Username:</label>
  <input type="text" id="username" name="username" aria-describedby="username-help">
  <p id="username-help">Enter your username.</p>
  <button type="submit">Submit</button>
</form>

ARIA roles and attributes example:

<nav role="navigation">
  <ul>
    <li><a href="#" role="button">Home</a></li>
    <li><a href="#" role="button">About</a></li>
    <li><a href="#" role="button">Contact</a></li>
  </ul>
</nav>

ARIA (Accessible Rich Internet Applications) roles and attributes play a crucial role in enhancing the accessibility of web applications for users who rely on screen readers and other assistive technologies.

What are ARIA roles and attributes?

ARIA roles:

  • ARIA roles define the type of UI element being presented to assistive technologies like screen readers. They provide semantic meaning to elements that may not be conveyed by the HTML alone. For example:
    • role="button" indicates an element acts like a button.
    • role="navigation" indicates a navigation section.
    • role="alert" indicates important, often time-sensitive information.

ARIA attributes:

  • ARIA attributes provide additional information about elements that assistive technologies can use to enhance the user experience. They can modify the behavior or presentation of elements. Some common attributes include:
    • aria-label: Provides a text label that is used in place of the element's text content for accessibility purposes.
    • aria-labelledby: Points to the ID of another element that serves as the accessible label for this element.
    • aria-describedby: Points to the ID of another element that provides additional descriptive information about this element.

Why use ARIA roles and attributes?

  1. Accessibility Enhancement: ARIA helps bridge the gap where HTML alone may not provide enough semantic meaning. For example, when creating custom widgets or interactive elements, ARIA roles ensure these are properly understood by screen readers.

  2. Screen Reader Compatibility: Screen readers rely on ARIA roles and attributes to accurately convey the structure, purpose, and state of web content. Without ARIA, complex widgets or dynamic content may be confusing or even inaccessible to users.

  3. Dynamic Content: ARIA attributes like aria-live and aria-atomic are crucial for announcing changes in dynamically updated content (e.g., chat messages or notifications) to screen reader users in real-time.

  4. Keyboard Accessibility: ARIA roles such as role="menu", role="tablist", and attributes like aria-selected ensure that complex interactive controls are navigable and operable via keyboard alone.

Examples of using ARIA roles and attributes:

Example 1: Button role

<button type="button" role="button" aria-label="Close">
  <span aria-hidden="true">&times;</span>
</button>
  • Here, role="button" and aria-label="Close" ensure that the element is recognized as a button and provides an accessible label for screen reader users.

Example 2: Navigation role

<nav role="navigation">
  <ul>
    <li><a href="#">Home</a></li>
    <li><a href="#">About</a></li>
    <li><a href="#">Contact</a></li>
  </ul>
</nav>
  • Adding role="navigation" to the <nav> element explicitly informs screen readers that this section is intended for navigation.

Example 3: Live region

<div role="alert" aria-live="assertive">
  Error: Please enter a valid email address.
</div>
  • Here, role="alert" and aria-live="assertive" ensure that screen readers announce this message immediately (assertively) to the user when it appears dynamically.

Best practices for using ARIA:

  • Use semantic HTML wherever possible: ARIA should complement, not replace, semantic HTML. Use elements like <nav>, <button>, <form>, etc., appropriately before resorting to ARIA roles.

  • Keep ARIA roles and attributes minimal: Avoid overusing ARIA, as incorrect or unnecessary roles can confuse users. Use ARIA roles and attributes judiciously where HTML alone falls short.

  • Test with screen readers: Always test your application with screen readers to ensure ARIA roles and attributes are correctly interpreted and provide a meaningful experience.

  • Stay updated with WCAG guidelines: As accessibility standards evolve, stay informed about best practices and updates to WCAG guidelines regarding the use of ARIA.

More information can be found here.

Clone this wiki locally