Meeting minutes
Lola: Working with ARIA-AT CG to bring about AT-Driver work
… Primarily we're the ARIA AT group.
… We don't currently have reps from AT implementors
<lolaodelola_> https://
Lola: I want to encourage people to think about this from a browser a11y testing, developer and design tools perspective
… AT is broad. There are two areas we want to focus on
… AT rendering of web code, and web developer experience
… Web devs don't know if the behavior they observe is correct.
… Even experts often disagree about what's acceptable.
… Regressions in ARIA are common, so there are no guarantees that what works today works tomorrow.
… AT driver is a protocol inspired by WebDriver / BiDi
… This is a protocol for automating assistive tech using web sockets
… Capabilities including observing speech, simulating keyboard, and modifying settings
… Protocols don't make this better alone.
… We're currently working on an interop suite for ARIA-AT
… This will become compatible with NVDA. We hope to have that ready soon.
… We have support from Vispero & NVDA
… We're also working on a11y tree dump
… If you work at a screen reader company, talk about this
Mitch: I think a lot of people think this is useful.
… Looking ahead, a risk of success is we may see work-arounds on the AT
Matt: Do you mean the limitations of what can be done with current AT trees?
… That might ber more the domain of ARIA WG
Mitch: I probably meant browser's ability to do the right thing.
… In communicating what this is for to AT / content developers, it may not be for a dev to fix the problem.
Matt: This is what the interop effort is doing. By knowing browser support for different a11y semantics is, the info can be put together too
… It would not be smart to test support for something with known bugs.
Fremy: Very supportive of the project. I had a few questions on the practicalities.
… If you want to make a test suite for a site, has this considered you may want faster than real-time operations?
… Other question; I don't know how easy it is to install the AT itself. I was wondering if as part of this if we could make a version that could only be used for testing?
Matt: The point is to test how the AT specifically behaves. If you're not testing the same AT that would get more into webdriver capabilities.
Fremy: You may want for example to try running against an upcoming version.
Lola: It's a little tricky because accessibility testing in general takes a long time.
… In terms of running tests faster. We have the specifications. Then we're building ARIA automation on top of that
… Optimising is something we want to consider for later iterations.
dekoz: I wonder if screen magnification / high contrast mode are in scope of this?
Matt: They're not in the short-term scope, but the way we're writing the spec, we intend for any AT that relies on acc APIs to be in scope
jcraig: Typically screen mag software doesn't do anything but zoom into the pixels.
dekoz: We would want to make sure that a page with screen magnification has the exact delta
BenT: I'd love to hear more about this would work with different modes of operation with screen readers
… There are a lot of users with for example custom JAWS scripts
… How would that be addressed in AT Driver?
… Would you write test scripts to confirm all the many ways you can use screen readers?
… There are so many ways in which you can use AT.
… I was also wonder if something like Dragon Naturally Speaking is in scope?
… I have a lot more questions. How can I find out more?
Lola: We discuss a lot in the community group.
BenT: Magnification ATs often do text smoothing, could this be used to test this is rendered correctly?
Matt: The way this is architected, you provide a command the user would execute.
… Then the driver expects a response. This has to be something that can be encoded. It's the AT that responds.
… If the AT can represent the user experience faithfully there is almost no limit.
… There is a practical question of when the AT implements AT driver, in the case of screen readers we expect the speech response back unaltered.
… We have conceptually figured out how we'd do this for screen readers.
… I'm having a hard time seeing how we could encode the response from speech software
… In terms of AT settings, the protocol supports setting and confirming settings.
… In terms of what commands are supported.
… When testing a website, those kinds of questions you have to remember if you're testing the screen reader or the website.
… There is really no point in testing that as a web developer.
JCraig: I wanted to get a few issues into the minutes
<jcraig> w3c/
JCraig: Issue 11, HID level automation has to be out of scope.
<jcraig> w3c/
JCraig: at the HID level is usually where AT simulate events.
… As I was reviewing this earlier, I was reminded there is an automation package in issue 12 that requires the user to disable their system integrity protection (SIP) on MacOS.
… That's not an approach we'd recommend for any user, or even any web developer on their main system, although maybe in an otherwise secure CI system that could be okay
… Open key press interface seems like a non-starter
… If this will be something that moves into werbdriver bidi peer, it has to be an enumerated list.
… Implementations could never make the key press API secure as proposed
… For this to be a first-class automation API, it would need to change... Or keep it how it is working today, but know it couldn't ever be standardized as a keypress API.
Mitch: Will this require a modification of the AT in order to obtain the benefits?
Lola: Yes
… I also want to say, there is a lot of interest in this. The subgroup meets bi-weekly on Monday 12pm - 1pm pacific time