AccessibilityNG: Table and Form Improvements in Chromium

This article provides a quick overview of how Chromium’s AccessibilityNG initiative modernized the browser's accessibility engine, focusing specifically on the major improvements made to table navigation and form control labeling. By overhauling how the browser constructs and updates the accessibility tree, AccessibilityNG resolved long-standing bugs caused by modern CSS layouts, enhanced screen reader navigation across complex data grids, and standardized accessible name computation for form inputs.

Table Navigation Improvements

Before AccessibilityNG, Chromium relied heavily on the visual layout tree to build the accessibility tree. This caused severe issues when web developers applied modern CSS to standard HTML tables. AccessibilityNG decoupled accessibility logic from visual layout, bringing several direct improvements to table navigation:

  • Resilience to Modern CSS: Applying properties like display: flex, display: grid, or display: contents to <table>, <tr>, or <td> elements previously destroyed the table's semantic structure for screen readers. AccessibilityNG shifted table construction to rely on DOM semantics and ARIA roles rather than visual layout objects, ensuring tables remain fully navigable regardless of how they are styled.
  • Accurate Cell Coordinates: The initiative rewrote the logic for calculating row and column indices. Complex tables utilizing rowspan and colspan, as well as ARIA grids using aria-rowindex and aria-colindex, now report exact coordinates to assistive technologies. This prevents screen readers from skipping cells or getting trapped during directional navigation.
  • Smarter Data vs. Layout Heuristics: Developers historically used HTML tables for page layout rather than tabular data. AccessibilityNG refined the heuristics used to detect whether a table is a "data table" or a "layout table." Screen readers are now much less likely to announce irrelevant table coordinates for purely visual layouts, while reliably exposing true data tables.

Form Control Labeling Improvements

Form controls rely on the W3C Accessible Name and Description Computation (AccName) specification to tell screen reader users what an input field represents. AccessibilityNG overhauled how Chromium calculates these labels, fixing numerous edge cases:

  • Reliable Hidden Label Referencing: Developers frequently use aria-labelledby or aria-describedby to link form inputs to elements that are visually hidden using display: none or visibility: hidden. Because the legacy engine relied on rendered layout objects, it often failed to read hidden elements. By transitioning to a pure DOM-based traversal for text calculation, AccessibilityNG ensures hidden labels and error descriptions are always announced accurately.
  • Standardized Recursive Name Computation: When a <label> contains multiple nested elements—including other form controls, spans, or pseudo-elements—calculating the correct text string can become recursive and error-prone. AccessibilityNG aligned Chromium strictly with the latest W3C AccName specification, eliminating bugs where screen readers would either read duplicate label text or drop parts of a label entirely.
  • Dynamic State and Label Updates: Modern web forms dynamically inject validation errors and update input labels on the fly. AccessibilityNG moved accessibility updates into the main rendering pipeline lifecycle. As a result, when a form control's label or aria-invalid state changes, the update is serialized and communicated to the screen reader immediately, eliminating the stale or missing announcements that plagued the legacy engine.