What Developers Should Know About Assistive Technology and Web Accessibility

July 20, 2022

Assistive technology (AT) is a catch-all term for software, hardware, and other types of tools designed for people with disabilities. The purpose of AT is to counteract the barriers that affect these users — but while assistive tech is enormously powerful, it can’t overcome poor product design.

For example, many people with vision disabilities use screen readers, software that outputs text as speech or braille. Screen readers can identify images and read alternative text, which explains the purpose and function of the image. Of course, if the web developer forgot to add the alternative text, screen readers can’t magically find the missing information. 

The idea that assistive technology will “work around" accessibility barriers is a common (and harmful) assumption. AT devices expect creators to use the best practices of web design. When that isn’t the case, the user experience suffers.

To create content that works with assistive technology, avoid assumptions

Fortunately, web developers can accommodate AT users by observing a few simple concepts. The first step is to review the Web Content Accessibility Guidelines (WCAG), which require content to be perceivable, operable, understandable, and robust. Prioritizing these four principles of accessibility will help you avoid the assumptions that create barriers.

Next, understand the importance of structure and semantics. While many of your website’s visitors will perceive content visually and navigate with a keyboard and mouse, some people will use other methods — and if your website has a clear structure and properly defined elements, you won’t leave these users out of the conversation. 

Here are examples of a few common mistakes that might cause AT tools to behave in unexpected ways: 

  • Missing alternative text (also referred to as alt text) for images prevents screen readers from conveying all on-page information to users.
  • Web pages don’t use the HTML lang attribute, which affects screen reader pronunciation.
  • Misused subheading tags can prevent users from navigating through content to find important information
  • A web page contains a list without appropriate markup, which prevents assistive technologies from identifying the content as a list.

These issues typically occur when developers ignore semantics or use XML/HTML to style their web pages. That’s poor practice: HTML should define the semantic purpose of different elements and the structure of your site. After you’ve built your structure with HTML, other tools (such as CSS) can be used to style your content. 

Make sure that all visual information can be identified programmatically. Different users may have different sensory capabilities, but if all content is programmatically determinable, assistive tools can find and present the information. 

Related: Plain Old Semantic HTML: A Perfect Basis for Accessibility

Web developers can use ARIA to refine the experience for AT users

If your content is especially complex, HTML and CSS may not be capable of presenting all information to your users. You might also decide to hide certain non-essential content from screen readers and other AT software (we’ll note here that this is only advisable if the content would negatively impact the user experience).

WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications Suite) is a powerful tool for applying semantic definitions to elements that can’t be natively defined in HTML. Certain ARIA tags can also tell assistive tools how to interact with certain elements (for instance, by hiding nonessential content). 

By using ARIA, you can improve the experiences of many AT users — but misusing ARIA can create new accessibility issues. While ARIA support varies from tool to tool, HTML is widely supported. In other words, ARIA can be beneficial for accessibility, but it can’t make your site accessible on its own.

Before adding ARIA markup, keep these tips in mind: 

  • If content can be semantically defined with native HTML, use HTML instead of ARIA. 
  • Don’t use ARIA as a “quick fix" for poor HTML structure. 
  • If you use ARIA, be prepared to test your markup frequently. 
  • Double-check ARIA syntax and avoid changing native semantics.

For more guidance, read: 5 Tips for Using ARIA to Improve Web Accessibility

Assistive technology works best within an accessible environment

Never assume that the user’s software will overcome poor design decisions. Screen readers, eye-tracking systems, and other assistive tools rely on great web design, so prioritize accessibility from the first stages of development. 

Finally, while you should consider the experiences of AT users while creating content, remember that many people with disabilities do not use any type of assistive technology. Your website should offer an equivalent experience to all users, and following WCAG Level AA guidelines will allow you to provide that experience. 

To learn more about digital accessibility, review WCAG 2.1 Level A/AA principles and checkpoints or download our Ultimate Guide to Web Accessibility.

Receive an industry accessibility analysis of your website

Recent posts

6 Free Tools for Evaluating Web Accessibility

January 25, 2023

What to Know Before Writing a WCAG Conformance Claim

January 24, 2023

What Are Cognitive Disabilities, and Why Are They Important for Web Accessibility?

January 23, 2023

Not sure where to start?

Start with a free analysis of your website's accessibility.

GET STARTED