-
Notifications
You must be signed in to change notification settings - Fork 0
Coding for accessibility: Screen readers
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:
- 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.
- Every
<img>
tag must have analt
attribute that describes the content of the image. - Use empty
alt=""
for decorative images that do not convey meaningful content.
- Label form elements (
<label>
tags) properly using thefor
attribute to associate labels with their inputs. - Provide helpful instructions and error messages near form controls.
- 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.
- 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.
-
- Manage focus to ensure it moves logically through your application.
- Avoid traps where users can get stuck or lose context.
- Use accessibility tools and screen readers during development.
- Test with real users who have disabilities to get feedback on usability.
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>© 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.
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.
-
-
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.
-
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.
-
Dynamic Content: ARIA attributes like
aria-live
andaria-atomic
are crucial for announcing changes in dynamically updated content (e.g., chat messages or notifications) to screen reader users in real-time. -
Keyboard Accessibility: ARIA roles such as
role="menu"
,role="tablist"
, and attributes likearia-selected
ensure that complex interactive controls are navigable and operable via keyboard alone.
<button type="button" role="button" aria-label="Close">
<span aria-hidden="true">×</span>
</button>
- Here,
role="button"
andaria-label="Close"
ensure that the element is recognized as a button and provides an accessible label for screen reader users.
<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.
<div role="alert" aria-live="assertive">
Error: Please enter a valid email address.
</div>
- Here,
role="alert"
andaria-live="assertive"
ensure that screen readers announce this message immediately (assertively) to the user when it appears dynamically.
-
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.
Welcome to Evergreen Team Wiki page.
- Problem Statement and Goals
- Architecture
- Pull Request Guideline
- Cypress testing Documentation
- Sysdig integration