Interop 2024: Chrome at 100% for the accessibility focus area

Chrome started the year passing 88.2% of tests in the accessibility focus area of Interop 2024. In June 2024 we were first to reach 100% of tests passing. This post explains the work that happened to reach this goal.

What is included in the accessibility focus area?

As with every focus area in Interop 2024, the accessibility area is defined by a set of web platform tests for selected features. The tests in Interop 2024 aim to ensure all browsers create accessible names and computed roles in the same way.

Accessible names convey the purpose or intent of an HTML element. This helps users understand what the element is for and how they can interact with it. The accname specification defines how browsers create this accessible name string for an element. The ARIA specification includes a walkthrough of how this name is calculated.

The computed role of an element is a string that represents the role of the element as computed by the browser engine. This is used primarily in developer tools and, for example, in the WebDriver function getComputedRole, enabling interoperability testing.

What did the Chrome team need to do?

There were two larger areas of work that we needed to complete—changing mapping of roles to generic roles and removing deprecated roles. Then there were some additional smaller fixes and features to implement. In addition to the following work that the Chrome team completed, we also collaborated with Microsoft on fixes they were committing to Chromium for the accessibility focus area.

Change mapping for certain roles to a generic role

Changing a mapping to generic role removes accessibility semantics from an element. Generic elements don't provide value to an accessibility tree, so they are not included in the tree. This helps with performance and makes the tree smaller and easier to parse for assistive technology. The following roles are changed to a generic role.

• A <header> scoped to <main> or a sectioning content element (<article>, <aside>, <nav>, or <section>).
• A <footer> scoped to <main> or a sectioning content element (<article>, <aside>, <nav>, or <section>).
• An <aside> inside a sectioning content element (<article>, <aside>, <nav>, or <section>) without an accessible name.
• A <section> without an accessible name.
• Orphaned list items (<li>).

For the first four bullet points, typically these elements are mapped to landmark roles. Having two many landmarks on a page can make it harder to navigate, so this change helps reduce redundant landmarks making the page easier to navigate. The final item typically indicates a mistake by the page developer, a list item should always be inside a list, therefore an orphaned item is given a generic role.

Remove a deprecated role

We deprecated the directory role, and mapped it to the list role. ARIA 1.2 deprecates the directory role. The specification explains that it is equivalent to the list role, and the developers should use list. In order to maintain the semantics of older content that uses directory, it's now mapped to list in Chrome.

Other fixes

We added support for the gridcell role. This new role makes the distinction between gridcell and cell more clear. A gridcell is focusable, editable, and selectable, unlike cell.

We added fallback role calculation. Previously, we did not check for fallback roles so if the first role was not valid, we used another role, which is not what is detailed in the specification.

Some roles are only valid if they are in the correct context, we added a check for invalid use of roles, as follows:

• The row role should be inside table, grid, rowgroup, or treegrid.
• The rowgroup role should be inside table, grid, tree, or treegrid.
• The listitem role should be inside list.

If the role is invalid Chrome now uses other information, such as the HTML element, to compute an alternative role.

We marked thead and tfooter as included in the accessibility tree. Previously they were marked as ignored, but were still included in the tree. Now table header and table footers can be parsed by assistive technologies.

While these changes may not be visible to most developers, with all browsers working to ensure these things work in the same way, we ensure that different roles are exposed in the same way everywhere.