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.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…