<aside> 💡

Study Tasks

• Know which combinations of assistive technologies work best with which browsers.
• Know how to use screen readers to navigate content via landmarks and headings, use forms, and read content, including data tables. Be aware that mechanisms often differ between desktop (mostly keyboard-based: tab and arrow keys) and mobile (often gesture-based).
• Be aware that users of AT often use their tools in very different ways. For example, while screen readers offer various navigation modes for expert users, many actual users do not know or use these modes.
• Understand the different screen reader modes for interacting with different types of page content (Windows screen reader: read/browse mode, forms mode, application mode, VoiceOver rotor, TalkBack menu).
• Be familiar with standard keystrokes for interaction with interactive elements in native HTML
• Be familiar with conventions for keyboard interaction within ARIA widgets.
• Know the limitations of your assistive technology knowledge. If you are not experienced, do not assume something is an error. It may be that you do not know how to use the assistive technology correctly. Output anomalies or gaps could indicate a partial lack of screen reader support or bugs.
• Demonstrate an understanding of user testing and compare it to accessibility testing.
• Understand the value of user testing by users with various types of disabilities.
• Consider the consequences of certain types of accessibility flaws. Some flaws are more critical than others.
• Demonstrate an understanding of the design’s usability versus accessibility and the conformance to accessibility specifications. </aside>

Resources

Recommended Combinations to Guarantee Better Compatibility

Windows

• JAWS and Google Chrome
• NVDA and Firefox
• Narrator and Edge

MacOS

• VoiceOver and Safari

Android

• TalkBack and Chrome

iOS

• VoiceOver and Safariindows

The current Windows accessibility API is known as UI Automation (i.e. User Interface Automation)

Mac app XCode > Open Developer Tool > Accessibility Inspector.

The accessibility tree contains information about objects including the following:

• Name
  • The text label given to the element. Sometimes the name is the text within the element itself (e.g., link text or heading text). Other times the name must be assigned with either an HTML method (e.g., <label> elements for form fields or <caption> elements for HTML tables), or via an ARIA attribute (i.e., aria-label="This is the name" or aria-labelledby="someID").
• Description
  • Extra information about an element (e.g., as defined by aria-describedby="someID" or by the title attribute, depending on the context).
• Role
  • The semantic meaning of the element, which can come from native HTML elements (e.g., headings, tables, lists, etc.) or ARIA roles (e.g., role="tablist", role="tab", role="tabpanel", etc.).
• Property
  • Characteristics of an element (e.g., haspopup="true").
• Relationship
  • Each relationship generally follows one of these patterns:
    • Parent-child hierarchies, which are often defined by the natural hierarchy of the DOM. For example, an HTML list item (<li>) must belong to a list (<ul> or <ol>), and an ARIA tab must belong to a tablist.
    • The explicit linking of an element to the element it belongs to or controls (e.g., as defined by aria-owns="someID" or aria-controls="someID").
• State
  • The current condition of an element (e.g., aria-expanded="false" or aria-selected="true").