Auditing Accessibility Trees Across 76 Web Pages
Zusammenfassung
Pixel’s announcement shares an accessibility audit that used Chrome’s DevTools Protocol to inspect the computed accessibility trees of all 76 public pages. The scan returned 60,481 nodes, including 5,218 ignored nodes, and surfaced an image and a misplaced heading—details that DOM-only checks can miss.
DEV Community
I dumped the accessibility tree of all 76 of our pages: no unnamed controls, one image, and one heading in the wrong place
Most accessibility checks I have written start from the DOM. Count the aria-label attributes, grep for an alt, assert that there is one h1. It is cheap and it is a guess, because the thing a screen reader uses is not the DOM. It is the accessibility tree the browser computes from it, where names come from six possible sources in a fixed order and whole subtrees disappear for reasons that are not visible in the markup. So for Nakodo, which finds creators and local businesses that fit a brand and emails the good fits, I stopped guessing and asked Chrome for the tree itself. All 76 public pages, one Accessibility.getFullAXTree call each, every node aggregated. Here is what came back, and the one thing it found that a DOM grep had been missing for weeks. The method The tree is not available through normal page JavaScript. There is no document.accessibilityTree. You get it from the DevTools protocol, which means driving the browser rather than running a snippet in it: await page.cdp("Accessibility.enable");
const { nodes } = await page.cdp("Accessibility.getFullAXTree");
Each node arrives with a computed role, a computed name with the list of sources that were considered and which one won, a description, a property list (focusable, level, invalid, describedby) and an ignored flag. That last flag is the interesting one: getFullAXTree returns the nodes the browser decided not to expose as well as the ones it did, so you can measure what you are hiding instead of inferring it. If you want to see the same thing by hand rather than by protocol, open DevTools on any page, go to the Elements panel, open the Accessibility pane in the sidebar and tick "Enable full-page accessibility tree". That is the same data with a different front end. The totals Measure Value Pages 76 Nodes returned 60,481 Ignored (not exposed) 5,218, which is 8.6 per cent Exposed 55,263 Exposed nodes carrying a name 43,460 Distinct roles 42 Nodes per page 343 at the lowest, 1,099 at the highest, 827 median The smallest page is the alternatives hub at 343 nodes. The largest is the home page at 1,099, which is also the page with the largest ignored share at 20.9 per cent. Both of those numbers have the same cause, and I will come back to it. Two roles account for more than half of everything: 20,117 InlineTextBox and 14,182 StaticText. Text is what a website is. After that it is 5,084 links, 4,746 list items, 2,740 paragraphs, 662 headings, 648 table cells and a long tail: 334 disclosure triangles, 314 terms with 314 matching definitions, 63 times, 20 figures with 20 captions, 5 tooltips, 3 radios. Finding one: 5,166 controls, every one of them named The audit flagged any node with an interactive role and an empty computed name. The set was 5,084 links, 43 buttons, 36 text boxes and 3 radios, so 5,166 controls across the site. Zero of them have no name. I was braced for a handful. The usual suspects are icon-only buttons, links wrapped round a decorative image, and inputs whose label is a styled div sitting next to them rather than a label. The reason none of those bite here is boring and worth saying out loud: the icon set is only ever used inside a control that already has text, and the one place where an icon stands alone is the small-screen menu trigger, which carries an explicit label:
That is the whole trick. There is no clever labelling system here, no utility that enforces a name. There is just one component for buttons, one for inputs, and a habit of writing the words before the picture. The computed-name sources in the tree confirm it: the overwhelming majority of those 5,166 names come from contents, which is to say from the text that is already visible on the page, not from an attribute somebody remembered to add. Count them yourself on the page with the most controls, the glossary, which has 118 focusable nodes: [...document.querySelectorAll("a, button...

Powered by Readybot.io