Chrome at 100% for the accessibility focus area  |  Blog  |  web.dev

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.