Is it possible to embed ChromeVox lite in our style guide? about ud891

[alice]

ChromeVox Next is using the chrome.automation API, not the (currently partially specced and completely unimplemented) AOM API, so it won't be totally straightforward to "Lite-ify" unfortunately. That said, once AOM is eventually shipping this would be a fabulous use case for it, and hopefully it wouldn't be too painful to switch over.

[alice]

No, there isn't an official, supported version anywhere. We made it for the course, and had to do a little hacking to get it to work.

I really like this idea! I think encouraging developers to get a feel for what it's like to use web pages via assistive technology is an important part of helping us all to build accessible products, and ensuring that your style guide models and demonstrates the result of accessibility best practices makes a lot of sense. We made it for the course for similar reasons as I imagine you'd want to embed it: using a separate tool is enough of an effort that most developers won't do it, plus it would be an inconsistent experience across platforms; embedding something into the page means that people can use it right away and there's even potentially a kind of "curiosity" factor if the controls are always visible.

However:

• I'm hesitant to commit myself or others to maintaining ChromeVox lite as a separate tool (for example, it doesn't and can't support Shadow DOM, because of the way it works with events). We were able to build this version because of a long history of effort on the ChromeVox project as a working screen reader for ChromeOS, but the maintainers of that project have moved on to ChromeVox Next, which uses a private extension API which gives access to the accessibility tree directly, so would not be suitable for this purpose.
• I appreciate that the idea would be more of a "flavour" of what ATs would do with a given element, but I'd still be wary of encouraging developers to try and pin down AT behaviour, in the sense of setting expectations for exactly what a screen reader might "say" for a given element. Obviously this can vary between ATs, and can even vary depending on user context for any given AT as well.

So this isn't really "no" but more of a "probably not, unfortunately"; that said, I'll ask around to see how feasible it would be to release what we have as open source, since it does seem like it would be a potentially beneficial developer/education tool.

[toolness]

Ah, that's totally understandable. It is unfortunate that the maintenance problem seems like the biggest hurdle here--ChomeVox Next having direct access to the accessibility tree does seem like a more robust way of doing things, so it's good that the ChromeVox maintainers move on to it. Perhaps one day regular web pages will have direct access to the accessibility tree too, and we can have ChomeVox Next Lite!

Wait... that made me remember something I heard about a while back called the Accessibility Object Model. (Oh, and it looks like you're one of its authors--cool!)

Is the AOM what ChromeVox Next is using to introspect the a11y tree, or is it something different? That would be really cool if ChomeVox Next could eventually be "Lite'd" in the same way you did with ChromeVox.