Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Accessing the Accessibility tree with code

TLDR: How can I programmatically access the accessibility tree of a given web page? Is there any internal API that I can call via JavaScript to view the accessibility tree?

I am building a testing suite to check the correctness of accessibility within a web page. Currently we do this by comparing the DOM, and checking that certain attributes are present and correct. I would like to move away from using the DOM because that comes with a lot of extra data that needs to be traversed, and instead check only the a11y tree for correctness. This tree is found within the dev tools/inspector of most modern day web browsers, but I can not figure out how to check it with code. Thru my research, I have found that there is a new AOM (Accessibility Object Model) that is being suggested, but is not yet implemented. I have also found that the package 'puppeteer' has the ability to access it. Is there any way for me to access it directly?

like image 755
Dcoollx Avatar asked Jan 26 '21 05:01

Dcoollx


People also ask

How do you find the accessibility tree?

To view the accessibility tree: In Chrome, right-click anywhere on the page and select “Inspect” to open Chrome Developer Tools. Under the “Elements” tab, click the “Accessibility” tab. The first item in the list is the Accessibility Tree.

What is Dom in accessibility?

It is a modified Document Object Model (DOM). A browser takes the DOM and modifies it into a form that is useful to assistive technology. Think of the Accessibility Tree as a list of images, links and input fields with buttons.


1 Answers

Your idea is correct: it would be better to test the resulting accessibility tree, rather than make assertions about the underlying DOM. Apart from the extra traversal you describe, there are some other good reasons.

The main reason (to me) is that by looking for attributes in the HTML DOM, you're really making assertions about an implementation detail. However good tests should be agnostic to implementation details. For example an accessibility test shouldn't care whether a developer used <input type="image" src="foo.png" alt="foo"> or <button type="button"><img src="foo.png" alt="foo"></button>, since both have the same semantics as far as the accessibility tree is concerned.

Examining the accessibility tree would also be a much better way to assert that relationships such as aria-owns are behaving correctly; because the point of that attribute is to create parent/child relationships which aren't present in the DOM tree.

As far as I was aware, there isn't a good way to get the accessibility tree directly yet. That's being considered as a feature of the Accessibility Object Model; specifically the Phase 4: Computed Accessibility Tree API. This is still far from ready. A major issue is that different browsers would all have to expose the same accessibility tree, so that application/test authors aren't dealing with browser quirks. There is more information about this in the AOM explainer document.

The testing approach you describe is indeed one of the use cases which the Computed Accessibility Tree API intends to meet. I'm hoping to use it in this way myself, likely invoked via a test framework such as Nightwatch.

I have only recently become aware of the page.accessibility.snapshot feature of Puppeteer, and it sounds exciting. I don't yet have any experience of using Puppeteer, so I can't provide a fully-informed answer relating to that. One aspect that strikes me as relevant, though, is that Puppeteer is a Node.js library for controlling a headless Chromium browser. So I'll assume it currently deals with the accessibility tree derived by Chromium. This may not be quite the same as the tree called for by the AOM Computed Accessibility Tree standardization efforts. I think it would be safe to treat this as an unstable technology for the time being.

like image 112
andrewmacpherson Avatar answered Oct 26 '22 13:10

andrewmacpherson