Access All Areas: Ensuring Screen Reader Compatibility

30 Jul 24 Colette Wilson Wyatt

SHARE:

This is the fourth article in our web accessibility series. If you’ve been following them you’ll know that we’ve covered broad introductions to three areas of accessibility, keyboard, screen reader, and visual accessibility. In our last post, we took a practical look at some aspects of keyboard accessibility.

Today we’ll turn our attention to screen readers with tips on how to ensure our apps are screen reader-friendly.

To recap, a screen reader is an assistive technology that helps visually impaired or blind users access digital content by transforming text into speech. Of course, screen readers are not exclusively used by visually impaired users; people with cognitive differences often use them as well because listening to content can be easier to process than reading it.

We’ll examine the considerations from the perspective of each team to gain a deeper understanding of what it takes to create an accessible site.

Design

In truth, many of the design considerations for keyboard accessibility overlap with those for making a design screen reader compatible. It’s all about creating a clear and logical structure. Our designer, Emma, elaborates on this key point, emphasising how thoughtful design can enhance accessibility for all users.

Clear and Logical Structure

Logical page structures and organised navigation are cornerstones of good user experience, benefiting everyone – not just screen reader users – and making it easy for all users to navigate content smoothly and efficiently.

Design plays a crucial role in this process. By using design elements to indicate a clear hierarchy, such as structured headings and subheadings, we help users easily understand a page’s content and organisation.

In short, a logical structure is essential for screen reader accessibility as it facilitates efficient navigation, helps with understanding, reduces cognitive load, and improves usability. By organising content logically, we can create more inclusive and user-friendly designs for everyone.

Development

Creating a site that is screen reader-friendly involves a good dose of common sense, but some features still require special technical know-how. That’s where our in-house developer, Colette, comes in. Let’s dive into her top tips on ensuring your site is fully compatible with screen readers.

Semantic HTML & Aria Attributes

We’ve discussed the use of semantic HTML tags in a previous post and it remains an important aspect when it comes to screen reader compatibility. These descriptive tags define sections of the page so that screen readers can understand and convey the structure of the content to the user. Using the correct markup helps to clearly communicate the hierarchy and type of content too.

Many HTML tags have built-in accessibility features. Take the ‘form’, ‘label’, ‘button’, and ‘input’ tags, for example. These tags naturally convey structure and functionality, making it easier for screen readers to guide users through interactions.

Semantic markup done properly often reduces the need to rely as heavily on ARIA attributes (elements that define ways to make web content accessible), which can be a good thing because misusing ARIA can actually harm accessibility. However, ARIA attributes do still have their place. For instance, adding an aria-label like ‘Primary’ to the ‘nav’ tag to identify its purpose ensures screen readers interpret it correctly. In short, HTML is very often overlooked as a skill, but considered and correct markup acts like a map for screen readers and is fundamental to accessibility in general.

Text alternatives

Some types of content are inherently incompatible with screen readers, like images. When a screen reader encounters an image, it can’t immediately understand or convey what the image is about. That’s where HTML steps in with its inbuilt workaround, the alt text attribute.

You might be aware that adding alt text to images is important, but it’s surprising how often it’s done poorly. Alt text should be like a mini description, giving a quick but clear idea of what the image is and why it’s there. Equally important, if the image is purely decorative, is to leave the alt text blank. This way, screen reader users won’t get bogged down with irrelevant details.

In a recent, more experiential project, our use of background images provided important context to the content. To ensure the experience was just as rich for screen reader users as sighted users we made sure to include composing alt descriptions as a dedicated copywriting task.

Dynamic content

I’ve mentioned before that misusing ARIA attributes can sometimes backfire on accessibility. When it comes to dynamic content – stuff that updates on the page without a refresh – ARIA attributes are essential.

A common example can be seen in e-commerce sites. Picture a shopping cart icon that shows the number of items in your cart. When you click ‘Add to cart’, the number updates instantly without the page reloading. Sighted users see this change right away, confirming their action was successful. But without proper cues, screen reader users would miss this important update.

Adding the appropriate ARIA attribute alerts screen readers to these on-the-fly changes, keeping everyone informed. One project where live regions were particularly important was a gamified learning module. In the game users make decisions affecting their power levels. Each decision’s outcome was vital for making the next, so it was crucial to keep users updated on any power changes. By making the power component a live region, we ensured that everyone, regardless of how they accessed the game, stayed informed.

Navigation

Building screen reader-compatible navigation brings together many of the concepts we’ve already discussed, but navigation is such a crucial element of any website that I wanted to delve into it specifically.

For most smaller navigation menus, semantic HTML is really all you need. Using the ‘nav’ tag with its in-built role combined with semantic links containing meaningful text, describing their destination is enough to ensure screen reader users can easily navigate your site. For larger navigation structures with submenus, there’s a little more to it.

ARIA attributes like aria-controls and aria-expanded help manage the state of submenus, ensuring that screen readers can accurately convey that state. And, of course, adding the option to skip the navigation altogether is always a handy feature, allowing users to bypass the menu and jump straight to the main content.

 

Access All Areas: Ensuring Screen Reader Compatibility

QA

As always, QA is the vital final step in ensuring we deliver a truly screen reader-friendly experience. Once again, Jordan, our in-house QA Engineer and resident accessibility guru, gives us his insights on how best to test our work.

Testing Screen Reader Compatibility

Before we fire up the screen reader, our first step is an automated and manual code review to ensure this has been programmatically optimised for users of assistive technologies. We use a selection of automated tools, including the WAVE & Web Developer browser extensions. These extensions complement screen reader testing by highlighting errors in the code, including but not limited to missing alternative text, invalid page language and empty headings.

Multiple screen readers are available that can be used for testing. At Tilt, our preferred screen readers are NVDA and Jaws. With a multitude of navigation commands, using a screen reader may appear daunting at first; however, it is the best way to ensure that content is conveyed to the user correctly.

After we have reviewed the code and flagged any potential issues, we can start by using the screen reader to navigate through different elements to ensure that they are announced correctly and in the correct order.

  • Headings: Verify that they are correctly tagged
  • Links and Buttons: Ensure they are descriptive and accessible.
  • Forms: Check form controls have associated labels.
  • Images: Verify alt text is present and descriptive for non-decorative imagery.
  • Tables: Ensure they have appropriate headers and are understandable.
  • Dynamic Content: Check updates and status messages are announced.

Screen reader accessibility testing is crucial for ensuring that digital content and interfaces are inclusive and accessible to individuals with visual impairments. By conducting thorough testing with screen readers, developers can identify and rectify barriers that might prevent users from accessing and navigating websites effectively. This process not only promotes equality and inclusivity but also enhances user experience for a diverse audience. Moreover, it reinforces the importance of accessibility in today’s digital landscape.

Ultimately, integrating screen reader accessibility testing into development practices fosters a more inclusive digital environment where everyone can participate fully and independently, regardless of their abilities.

Next steps

Many resources are available that provide practical advice on creating screen reader-accessible websites. We recommend the W3C Web Accessibility Initiative (WAI), where you can find a wide range of tutorials, strategies, and techniques for making websites accessible, not just for screen readers but for all aspects of accessibility.

The key piece of advice we can give is that there truly is no substitute for testing your site using the same technologies that your users may rely on. Doing this will give you invaluable insights into their experience, highlighting accessibility issues that may otherwise go unnoticed. By using screen readers and other assistive technologies during testing, you can experience firsthand how your site performs for users with disabilities, allowing you to identify and address barriers to access and ensuring that your content is not only available but also fully usable by everyone.

Previous posts

Access All Areas 1: Insights on Web Accessibility 

Access All Areas 2: Essential Aspects of Web Accessibility

Access All Areas 3: Keyboard Accessibility from Design to QA