-
Notifications
You must be signed in to change notification settings - Fork 28
How Gaps in Assistive Technology Interoperability Hinder Inclusion
Since the initial phases of the ARIA-AT project, which will run through 2024, are focused on screen readers, we’ll explain interoperability using screen readers as the assistive technology. We will explain first from the perspective of a web developer. Even if you are not a developer, however, this perspective is very important for you to understand because the questions it raises impact everyone.
Imagine being a web developer testing with two screen readers, SR1 and SR2. You are testing the email application you are developing. Next to the email inbox is a control named “Your Folders” that lets users browse folders and subfolders where they have organized saved email messages. With SR1 running, you navigate to the “Your Folders” control and hear:
Your Folders Tree View Inbox selected one of ten level one
With SR2 running, you navigate to “Your folders” and hear:
Your Folders Table
The output is different. One seems more right than the other. SR1 gives users more information. You notice that it calls the control a “Tree View”, which seems to make more sense to you, especially since you used accessibility code that identifies the control as a tree. How do you know if these differences are OK? Maybe users of SR2 expect controls like this to be called a table. On the other hand, maybe there are bugs in SR2 that will make it difficult for users to understand how the control works. As a web developer who is not an expert user of SR2, how would you know?
Differences like this are potential assistive technology interoperability issues. Before we provide a more specific definition of interoperability, though, it is helpful to first explain some important terms.
In this screen reader output:
Your Folders Tree View Inbox selected one of ten level one
The term “Tree View” is an example of the screen reader interpreting information in the web code that we call an accessibility semantic. Developers add accessibility semantics to the code for each element on a page so assistive technologies can understand the purpose and state of the elements and present them appropriately to users. One way to think of accessibility semantics is that they are a non-visual way of communicating information that is conveyed by the visual design.
Users of SR1 who are familiar with tree view widgets will immediately understand how to interact with the element. SR1 can also help users who don’t know what the term “tree view” means by explaining it with contextual help.
The word “selected” represents the screen reader’s interpretation of an accessibility semantic that describes the state of the “Inbox” item. And, the phrase “one of ten level one” is an interpretation of three additional semantics that describe the position of the “Inbox” item in the tree.
The Accessible Rich Internet Application (ARIA) specification provides a dictionary of every possible accessibility semantic that can be used in a web page. It also provides rules that browsers use for exposing the accessibility semantics to assistive technologies. And, the ARIA Authoring Practices Guide (APG) helps web developers understand how to use the semantics defined in the ARIA specification and provides examples of appropriate usage. For instance, it includes a design pattern for tree view controls and several working examples that implement the pattern.
Two screen readers are interoperable when they both provide sufficient and accurate presentation of all accessibility semantics on any standards-compliant web page. This does not mean their presentation is identical but rather that the meaning of each screen reader’s presentation equally satisfies minimum expectations for rendering available accessibility semantics to users.
In our tree view example, there are six accessibility semantics describing the inbox item in the tree. SR1 presents more of the semantics than SR2 and it uses different words. To decide if they are interoperable, we need to agree on which semantics users need in order to correctly understand the widget and what it means to accurately convey those semantics.
The ARIA-AT project is proposing and testing expectations for all accessibility semantics. The ultimate goal is for everyone to agree on the expectations and for them to be tested every time any screen reader or browser makes a change that could affect how the semantics are conveyed.
The assistive technology interoperability gap is the difference between support for interoperability enjoyed by people who don’t use assistive technologies and those who do. Specifically, for the web:
- If you don’t need assistive technology, you can use any standards-compliant web page with any standards-compliant browser. If you rely on assistive technology, there is no way to know if a web page will work for you, even if it complies with all applicable standards.
- Standards-compliant browser behavior is well-defined. There are no similar definitions of acceptable behavior for any assistive technologies.
- Industry has built and maintains an infrastructure for continuously testing browser interoperability. An equivalent infrastructure for assistive technologies does not yet exist.
Without assistive technology interoperability, it is not possible to have a fully accessible web that includes all users of assistive technologies. The situation is very similar to early days of the web when browsers were not interoperable, so web sites excluded users who didn’t have access to a supported browser. However, the situation is arguably worse for assistive technology users because it is so hard to see the problems. The problems are essentially invisible to most people.
Some consequences of the assistive technology interoperability gap include:
- Because commonly accepted definitions of expected assistive technology behaviors for accessibility semantics have not yet been developed, assistive technology developers have had to make their own decisions about what behaviors are sufficient. This naturally leads to meaningfully different interpretations of accessibility semantics.
- Web developers don’t know if the assistive technology behavior they observe when testing their code is correct, so it is necessary to have accessibility experts perform routine testing. Further complicating matters, even the experts often disagree about what is acceptable.
- There are so many combinations of assistive technologies and browser that no web development organization can test their products with all of them. Even testing a representative sample is unattainable for most developers. This means there are nearly always going to be some users who are excluded.
- Because there is no assistive technology testing infrastructure similar to that available for browsers, regressions in ARIA support are common. Consequently, there is no guarantee that a product that works with a specific assistive technology today will work as well with that same assistive technology tomorrow.
- Because it is not possible to predict what types of widgets will be well supported by all assistive technologies, a designer who wants to design with accessibility in mind is severely constrained and may need to re-work the design after build and test. Typically, this leads to some type of accessibility Band-Aid.
- Well intentioned developers often try to add extra information and instructions to their web page in an attempt to compensate for what they perceive to be gaps in screen reader support. This screen reader Band-Aid content can generate so much extra speech that the site becomes extremely difficult to use because users have to spend a lot of cognitive energy to separate the actual content from the Band-Aid content.