Interpreting WAI-ARIA

Question 1

What are the main goals of WAI-ARIA?

Answer 1

• expanding accessibility information that may be supplied by the author
• requiring full keyboard support that may be implemented in a device-independent way, where supported
• improving accessibility of dynamic content generated by scripts
• providing interoperability with assistive technologies

Question 2

What are the two main aspects of roles covered in WAI-ARIA?

Answer 2

User interface functionality and structural relationships.

Question 3

What is meant by semantics and why is it important in relation to accessibility?

Answer 3

Semantics is the science of meaning. It is important that web pages and UI components are created with semantics in mind, so that UAs and ATs can interpret and convey their meaning, regardless of how they are being presented.

Question 4

How do roles differ from properties and states?

Answer 4

Roles are element types, providing information for normal processing, and will not change with user actions.
States and properties describe interaction, and can be dynamically changed and updated by UAs and OSs.

Question 5

What is meant by an accessibility API?

Answer 5

It is the information and controls exposed by the UA to the operating system and assistive technologies, providing them access to interpret and manipulate the web page.

Question 6

_T/F:
WAI-ARIA can be used interchangeably with the native language’s semantics.

Answer 6

F. While the statement is technically true, it is not the intention of WAI-ARIA to be used as a replacement for native technologies. When the host language provides a feature that provides equivalent accessibility to the WAI-ARIA feature, use the language feature. It is not appropriate to create objects with style and script when the host language provides a semantic element type for that type of object.

Question 7

Who are the target audiences for WAI-ARIA?

Answer 7

• UAs
• ATs
• Authors who create content
• Authoring tools that help authors create conforming content
• Conformance checkers

Each conformance requirement indicates the audience to which it applies.

Question 8

T/F:
The WAI-ARIA specification neither requires nor forbids user agents from enhancing native presentation and interaction behaviours on the basis of WAI-ARIA markup.

Answer 8

T. UAs are encouraged to maximize their usefulness to users with/without disabilities and may expose landmarks or enhance styling.

Question 9

T/F:
As host languages evolve to provide semantics to objects and features that can currently only be declared with WAI-ARIA, authors should refactor and remove instances of WAI-ARIA in their codebase.

Answer 9

F. Authors are encouraged to use native host language features when they become available, but are not required to change existing code. UAs and host languages are encouraged to continue supporting WAI-ARIA to support legacy code.

Question 10

How are conflict in roles, states, and properties resolved in cases where the host language and WAI-ARIA do not match?

Answer 10

Host language states and properties will take precedence over WAI-ARIA to avoid conflicts, BUT WAI-ARIA roles will take precedence over implicit host language roles.

Question 11

What are managed and unmanaged states?

Answer 11

Managed states are those handled by the UA – e.g. such as focus, checked, selected – and often have CSS pseudo-classes associated with them.
Unmanaged states are those that the UA does not control or that the author can override, and the author must implement a mechanism to update them.

Question 12

What is a “managing container” or “composite” widget, and how does it accept and manage focus?

Answer 12

A container or composite widget is one that handles multiple related elements that work together to convey information or handle a user interaction.
The widget itself should receive and lose focus via the main navigation key (e.g. tab on desktop); additional interactions and focus within the widget should be handled by additional keys (e.g. arrows). When the container loses focus and subsequently regains it, the focus within should be returned to the last focused element within it (with some exceptions, e.g. menu bar).

Question 13

What are some examples of composite widget roles within which authors are required to manage focus?

Answer 13

• combobox
• grid
• listbox
• menu
• menubar
• radiogroup
• tree
• treegrid
• tablist

Question 14

What characteristics are used to define roles?

Answer 14

• Abstract Roles (boolean)
• Required States and Properties
• Supported States and Properties
• Inherited States and Properties
• Required Owned Elements
• Required Context Role
• Accessible Name Calculation
• Presentational Children (boolean)
• Implicit Value for Role

Question 15

*T/F:
A widget with a role that has required owned elements can be left empty if those elements are missing because they are being loaded by a script.

Answer 15

F. While the the required owned elements are missing, the widget MUST be marked with aria-busy="true".

Question 16

Where does an element’s accessible name come from?

Answer 16

1. author: explicitly provided in element’s markup (e.g. aria-label, aria-labelledby, alt, or title) on any element except presentation and none.
2. content: text value of the element node; lower priority than author values.

Question 17

How are roles categorized?

Answer 17

1. Abstract Roles: supporting taxonomy by defining general role concepts; not to be used by authors
2. Widget Roles: standalone UI widgets, or part of larger composite widgets
3. Document Structure Roles: structures that organize content in a page; not usually interactive
4. Landmark Roles: regions of the page intended as navigational landmarks
5. Live Region Roles
6. Window Roles: act as windows within the browser or application

Question 18

What are the differences between the table and grid roles, and when is one more appropriate than another?

Answer 18

• table is not intended to be interactive.
• grid SHOULD be used if the container maintains a selection state, provides its own 2D navigation, or allows users to rearrange/manipulate its contents or their display

Question 19

What are “states” and “properties”, and how do they differ?

Answer 19

• Provide specific information about an object
• Help define roles
• Applied asaria-prefixed attributes
• Property values are less likely to change through the application life-cycle
• State values may change frequently based on user interaction
• Frequency of change is relative an often inconsequential to authors, so they may be referred to together as “attributes”

Question 20

What types of values may be specified for states and properties?

Answer 20

• true/false
• tri-state (true/false/mixed)
• true/false/undefined
• ID reference
• ID reference list
• integer
• number
• string
• token
• token list
• URI

Question 21

What is meant by “global” states and properties?

Answer 21

These are applicable to all host language elements, regardless of whether a role is applied. They are applied to the base role (roletype) and are inherited by all roles.

Question 22

What is meant by the “accessibility tree”?

Answer 22

It is a parallel structure to the DOM, in which accessible objects are created for each DOM element that should be exposed to an AT, because of its properties, relationships, features, or events.

Question 23

What elements MUST NOT be exposed to the accessibility API or included in the accessibility tree?

Answer 23

• any elements (and descendants) with host language semantics specifying that they should not be displayed (e.g. CSS display: none or visibility: hidden, HTML hidden)
• any element with role none or presentation (conditional)

Question 24

What elements SHOULD NOT be exposed to the accessibility API or included in the accessibility tree?

Answer 24

• any elements (and descendants) with aria-hidden="true" [overrides descendant values]
• any descendants of elements whose children are presentational by definition (but not their text content)

Question 25

What elements MUST be exposed to the accessibility API and included in the accessibility tree?

Answer 25

• any elements that are not hidden and may fire an accessibility API event (including: currently focused, even if an ancestor is aria-hidden="true"; valid target of aria-activedescendant)
• any elements that are not aria-hidden="true" and have an explicit role or a global WAI-ARIA attribute
• any elements that are not hidden and have an ID that is referenced by another element via a WAI-ARIA property

Question 26

T/F:
Host languages may have features that make WAI-ARIA redundant and unnecessary

Answer 26

True. Host languages may have native features that correspond to WAI-ARIA features, where UAs process these “implicit” WAI-ARIA semantics in the same way as the WAI-ARIA feature, exposing the same information the the accessibility API. Wherever these features exist in the host language, they do not need to be duplicated with explicit WAI-ARIA semantics.

Question 27

T/F:
UAs will always respect the semantics of the host language first.

Answer 27

False, mostly. Except for a few cases, UAs MUST always use the WAI-ARIA semantics to define how they expose the element to accessibility APIs, rather than using the host language semantics. That is to say, WAI-ARIA semantics override the host language semantics in most cases.
- Exception: Host languages MUST explicitly declare if a WAI-ARIA attribute is in direct conflict with a native attribute; UAs then MUST ignore the WAI-ARIA attribute.
- Exception: Host languages MAY document features that cannot be overridden by WAI-ARIA (“strong native semantics”)

Question 28

How are missing states and properties handled for roles where they are supported or required?

Answer 28

• Missing supported states and properties are treated according to their default value.
• Missing required states and properties are treated as if they were present, and have an implicit neutral value that is not necessarily their default value.