5 Examples showing what happens if you don’t add ARIA attributes to your websites.

Recently, I came across a question on a discussion board for my User Experience Design course by another student.

I’m somewhat familiar with the idea of ARIA attributes, but as someone who has never used a screen reader or other kind of assistive technology, I’ve always been curious about what specific impacts different ARIA attributes have on how they present content to users.

Are most of them just future-proofing in case assistive technologies decide to utilize that information in the future, or do most attributes actually have a tangible effect now?

Can going overkill on ARIA attributes actually harm user experience in some cases?

Learning about things like that seems like it would be important for building websites that are accessible in practice and not just in theory.

I think most developers have this high level understanding that ARIA attributes are important for users with disabilities. But as someone who has never needed to use a screen reader, I don’t have a great understanding of what the consequences are when you don’t set up your attributes correctly. That’s why I want to explore real-world examples of what a visually impared user would hear when an website isn’t setup correctly with ARIA attributes. But first, we need to understand how exactly a screen reader works.

What are Screen readers and who uses them?

Screen readers use text-to-speech synthesis and other methods to read out loud the content and elements on a screen, such as text, buttons, links, and images, and allow users to navigate and interact with the content using keyboard commands or other input methods. This simple navigate-listen-interact cycle allows users to use all the functions of a website if it is designed with this type of user interaciton in mind.

There are built in options like VoiceOver (included in Apple’s macOS and iOS operating systems), and Narrator (which is included in Microsoft Windows) as well as Browser plugin that typically provide additional features and customization.

Although most think that screen readers are mean to users with low or no vision. They are also used by individuals with cognitive impairments or mobility impairments and by individuals who do not have disabilities, but need access to electronic information and websites in situations where visual access is not possible or practical.

Example 1: An Image

Let’s take this simple image of a pug.

<img src="assets/images/8193903121.png"/>

A pug wearing a red party hat with white dots

When a user highlights this image a screen reader might say:

8193903121.png, image

Which doesn’t provide information to a screen reader user other than the fact that there is an image. To fix this, add a alt tag to images.

<img
  src="assets/images/8193903121.png" 
  alt="A pug wearing a red party hat with white dots"
/>

A pug wearing a red party hat with white dots, image

As a side note, when a html element supports that alt tag, that should be used over aria-label. Aria-label should only be used in special cases like when a div has the property role=”img”.

Example 2: A disabled submit button

<button disabled>Let's Go!</button>

A disabled button labeled “Let’s Go!” at the end of form

When highlighting the button, screen reader might say:

Let’s Go!, button

This doesn’t tell the user what pressing the button will do, or the fact that it’s disbaled. Let’s fix that:

<button aria-label="Submit email" aria-disabled="true" disabled>Let's Go!</button>

Submit Email, dimmed button, Let’s Go!

Here the aria-label describes what the purpose of the button is and and the aria-disabled attribute allows the screen reader to describe that the button is dimmed and currently disabled.

Example 3: A comment box with a Label

Comment:
<textarea></textarea>
<p> Your comment will be visible to all members of your organization.</p>

A highlighted text area with the label “Comment:” and a description below it: “Your comment will be visible to all member of your organization.”

A screen reader might say:

Edit Text, blank

In order to fix this, we need to associate the the text area with the label and description.

<label id="comment-label" for="comment-box">Comment:</label>
<textarea 
  id="comment-box" 
  aria-labelledby="comment-label" 
  aria-describedby="comment-desc"
></textarea>
<p id="comment-desc">Your comment will be visible to all members of your organization.</p>

Comment, Edit Text. Your comment will be visible to all members of your organization

Here aria-labelledby connects the textarea to the label, allowing screenreader to undertstand that the feild is asking for a comment. Also notice that the for property in the label does the reverse so that when the screen reader is focused on the label, it knows that that it’s a label for the textarea. Lastly, aria-describedby attribute links the description with the textarea.

Example 4: Simple Table

<table>
  <thead>
    <tr>
      <th>Name</th>
      <th>Quantity</th>
      <th>Rating</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th>Product 1</th>
      <td>5</td>
      <td>4.5</td>
    </tr>
    <tr>
      <th>Product 2</th>
      <td>3</td>
      <td>3.7</td>
    </tr>
  </tbody>
</table>

A 3x3 table listing the name, quantity, and rating of Product 1 and Product 2

A side note: when a user is navigating through a table with a screen reader, it lists everything on a row before moving onto the column. As the screen reader moves through the table it might say:

Name: (Column 1 of 3)-> Quantity: (Column 2 of 3)-> Rating: (Column 3 of 3)-> Product 1 -> 5 -> 4.5 -> Product 2->3-> 3.7

That might suffice for some users especially when the table is short. However we can add Aria attributes to improve this expeirnce signifnicanltly.

<table role="table" aria-label="Product Comparison">
  <thead>
    <tr>
      <th scope="col" aria-label="Product Name">Name</th>
      <th scope="col" aria-label="Product Quantity">Quantity</th>
      <th scope="col" aria-label="Product Rating">Rating</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row" aria-label="Product 1">Product 1</th>
      <td>5</td>
      <td>4.5</td>
    </tr>
    <tr>
      <th scope="row" aria-label="Product 2">Product 2</th>
      <td>3</td>
      <td>3.7</td>
    </tr>
  </tbody>
</table>

In this example, the table has three columns: “Name”, “Quantity”, and “Rating”. The th elements in the table header use the scope and aria-label attributes to provide context and meaning for each column. The td elements in the table body use the aria-label attribute to provide a description of each cell's content. This allows assistive technologies to understand the structure and content of the table, and to provide appropriate navigation and interaction for users.

Now when going through the 3rd column a screen reader might say:

Product Name: Product 2->Product Quantity: 3-> Product Rating: 3.7

Of course, the verbosity of this can be adjusted on most screen readers to avoid saying the column titles if after x repetitions but adding these labels give this control to the user and allows them to make the choice on how much they want to hear.

Example 5: Overusing Aria Attributes

Of course, as with most things in life, too much of a good thing can be bad.

<div 
  role="dialog" 
  aria-labelledby="modal-title" 
  aria-describedby="modal-description" 
  aria-modal="true" 
  aria-hidden="false" 
  aria-live="polite" 
  aria-atomic="true"
>
  <h2 id="modal-title">Modal Title</h2>
  <p id="modal-description">This is a modal window that contains important information for the user.</p>
  {...}
</div>

In this example, the div element that contains the modal window has several aria attributes that are not necessary for providing a good user experience for screen reader users. The aria-labelledby, aria-describedby, aria-modal, aria-hidden, aria-live, and aria-atomic attributes all provide redundant information or unnecessary complexity. This can make the modal less intuitive for screen reader users to interact with and can also make the code more difficult to read and maintain. Depending on the screen reader and its settings, it will announce all of the aria attributes, which can be overwhelming and confusing for the user.

The future of ARIA

As the web continues to evolve and become more complex, ARIA will continue to play a crucial role in making web applications accessible and user-friendly for users of assistive technologies, such as screen readers and keyboard navigation.

One of the key areas where ARIA is likely to see further development is in supporting new web technologies and design patterns. For example, as more web applications move to using single-page architectures and asynchronous JavaScript, ARIA will need to provide new attributes and techniques for making these applications accessible to assistive technology users.

Another important area for the future of ARIA is in improving the interoperability and compatibility of ARIA attributes across different browsers and assistive technologies. Currently, there are some inconsistencies and differences in how different browsers and assistive technologies interpret and use ARIA attributes. Working towards a more consistent and standardized implementation of ARIA across the web will be critical for improving the user experience for assistive technology users.

Finally, the future of ARIA will also involve continued collaboration and dialogue between web developers, accessibility experts, and assistive technology users. As new challenges and opportunities arise in the world of web accessibility, it will be important for these stakeholders to work together to identify and address potential issues, and to develop new solutions that can benefit all users of the web.

Overall, the future of ARIA looks bright and promising. As the web continues to evolve, ARIA will play a crucial role in making it more accessible and user-friendly for everyone. Web developers should:

1. Use ARIA attributes and techniques to provide additional context and functionality for assistive technologies.
2. Provide clear and descriptive labels and descriptions for all elements and controls.
3. Use semantic HTML elements to accurately convey the structure and content of the page.
4. Ensure that the content is properly structured and organized, with clear hierarchy and relationships between elements.
5. Use color and contrast judiciously to ensure that the content is legible and visible to users with low vision.
6. Provide keyboard accessibility, allowing users to navigate and interact with the page using only a keyboard or other input device.
7. Test the application with assistive technologies to ensure that it is usable and accessible.

By following these steps, web developers can help create web applications that are accessible and usable for all users, regardless of their abilities or the devices they use.

There are many more ARIA Attributes I didn’t show here. See a full list of them here: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes

Note that ChatGPT was used for research and for writing some portions of this article.