Meeting minutes
present?
Adding AT Driver to charter https://github.com/w3c/aria/issues/2826
Daniel: came up because Browser Testing Tools are dropping AT Driver extension.
… I suggested it could be a joint deliverable but that wasn't an option either.
… of course ARIA has a lot of specs already. But it might be the best fit. So I brought it here.
jemma: what is the browser side?
Daniel: some integration with browsers was necessary. And overlap between browser and AT vendors.
matt: Mike and I brought it into their charter because it seemed aligned with that mission - tools in a browser context. The technology AT driver is based on is webdriver BiDi.
… so having webdriver BiDi people look at AT driver made a lot of sense.
… in practice, the implementations we've had by screenreader vendor is by Vispero. They are in ARIA but not BTT. This complicated things.
… the scope of AT Driver is a little broader than webdriver which is web-only. We've tried to write AT Driver in a way that it could potentially to apps not running inside a browser.
mike: I would add that there are opportunities to collaborate with ARIA. E.g. standardizing commands for common user intents. This would involve algorithms to move, e.g. the next heading. We cannot really rely on typical w3c lingo. E.g. they don't operate on elements. So AAM's are closer. I've had conversations with e.g. Valerie about this.
matt: alignment with ARIA is just bigger.
Jem_: is this expanding ARIA-AT?
matt: no, it's a dependency that ARIA-AT has. The ability to automate AT testing is essential for testing AT interoperability.
… without automation we cannot scale testing.
Daniel: if it ends in ARIA, we should be prepared for people to argue it is out of scope for ARIA.
… but I think we should try to see what we can do about it.
… but today we can only start this conversation. In particular discuss it with chairs present.
… are there other implementations?
matt: yes, vispero is the only one done by the vendor. NVDA has an implementation. There's faux implementation for Mac. It's essentially a wrapper around VoiceOver.
… I want to point out that testing is essential for ARIA's promise to support assistive technology interporability.
… we've had discussions around AT guidance of course. This is another dimension of this.
Daniel: raises the question of scope for this kind of guidance. How far it can go.
matt: right. AT Driver doesn't give guidance what to do, it just makes it testable.
… ARIA has zero value without AT. But you cannot test ARIA support with out AT Driver.
cyns: like we try to get testing at the browser and AAPIs layer, testing on the AT level fits in.
Daniel: next step is a discussion on the chairs/w3c side.
… then a potential charter draft. First for ARIA, then for Advisory.
matt: what are the implications if it's removed from BTT now but ARIA charter is not ready?
Daniel: I don't think that would be a problem.
… AT Driver is editor's draft. Not even a working draft yet.
… we should be able to pick it up.
matt: do we need to do something on the community group side?
Daniel: 2 scenarios. Get it to ARIA, then it's fine. Otherwise, the CG would go for a community report specification. Then we can try again after that
matt: ok so we can keep going. Except perhaps for BTT mention in the spec.
mike: should we change it to ARIA?
Daniel: that will depend.
matt: do we need to worry about this?
Daniel: no.
mike: just double check: we don't want to point to BTT but can't point to ARIA?
Daniel: we can't point to the CG side for normative reference. We have to wait until a WG approves it. Informally, we can.
matt: in the editor's draft, it's all unofficial. Do we need to change this right now? When they remove it from their charter?
Daniel: when they remove it, yes. But let's worry about this when it's moving towards FPWD.
… you could point to ARIA-AT for the time being.
… once it becomes an ARIA deliverable, then we need to work more stuff out.
mike: during this in-between state, will there be issues to, e.g. attend TPAC to speak about this?
Daniel: that would make sense because it will be discussed in charter discussions.
Updating Editors Draft URIs https://github.com/w3c/aria/issues/2825
Daniel: this is more of an FYI. When we moved to the monorepo structure we decided to keep old locations of github pages locations.
… but I've noticed people referencing the new location. So I'm wondering if we want to change.
… So I propose to redirect.
… then we have one source of truth.
matt: I like that the URL will then imply ownership.
Daniel: right. It's a bit different from wcag's overview page.
matt: right, no need for aria/aria
Jem_: +1
cyns: +1
<Daniel> pkra: We may want to consider closing the child repo issue tradckers and only use the monorepo for everything
pkra: just to repeat: I've seen more cases of issues for non-aria specs being filed in aria. I think at some point we should reconsider merging issue trackers.
matt: I'm with scott. I find it very helpful.
pkra: right. But if we observe more, then maybe reconsider in due time.
Daniel: to the item, I will create a PR
doc-pullquote role https://github.com/w3c/dpub-aria/issues/16
pkra: Matt Garrish isn't on the call so let's skip.
Daniel: I'll also follow up. Changes should be easier now.
Clarify Accessibility Parent-Child Relationships for menu, group, and menuitem https://github.com/w3c/aria/pull/2483
pkra: I put this on the agenda 3 weeks ago to get it moving again. But giacomo did some work this week.