Cf. https://github.com/domenic/html-as-custom-elements/blob/master/docs/accessibility.md#toward-a-solution-roles and following sections, although there are definitely other shapes such an API could take that would work, including potentially simpler ones.

Discussed briefly 19-aug telcon, schedule for followup 19-jan-2016 f2f

We have decided to repurpose this issue from generating/sketching out ideas for new accessibility solutions to simply reviewing the proposal in this space, which currently is WAPA: https://github.com/cyns/wapa

Changing the name of the issue.

@LjWatson @chaals any comments on this, referencing our discussion earlier today?

Positive thoughts from @slightlyoff on this at our f2f (afternoon of day 3).

Sorry for the slow reply.

So reading the Script Based Web Accessibility explainer (yay! an explainer!), it seems like it's a few different things all at once:

• A last-chance way for ARIA data to be plumbed back into the document when ARIA attributes aren't already present. This feels like a great way of explaining how ARIA might work programmatically!
• High level ("Intention") events (although it isn't clear if there are examples of this in the doc). Using IDL to describe the API instead of exmaple code to show how it works makes understanding some of this difficult.
• Mappings (whose purpose isn't clear to me from either the prose or example code)
• Virtualization

The last one feels like something that we might want to consider in combination with other aspects of delayed content loading. There's work on Intersection Observer to make it easier to build the sort of paginated lists that developers strive for and I'd be intrested to see if there's overlap in the assumed models between them. If not, it might box users into a single way of building pagination and that way might not be the most optimal.

Something I'd like to see here is a way to extend ARIA. Having the events is great, and it makes it much eaiser to feed ARIA data into elements, but not being able to extend the language itself makes handling composite widgets difficult.

Like Alex, I like the virutalisation which I think is something we might need to deal with consistently across the platform.

Likewise I'm a big fan of the "intention" events - this is very much facing the same problem as that I tried to outline with regards to "input to and interaction with applications" today. "Improving accesskey" is a misleading name. First because that's only one potential solution, and second because by focusing on a solution it distracts people from understanding the real problem.

Explaining ARIA in terms of script seems like an obviously useful thing to do, given that ARIA 1.x implies a heavy reliance on script to be useful anyway.

The mapping Alex mentioned is a very partial example of how stuff gets translated to one of the platform Accessibility APIs on Windows.

[Old]

• WAPA spec is here: https://rawgit.com/cyns/wapa/master/wapa.html (last update Oct. 2014)

[Latest thinking]

• UNOFFICIAL browser-folks-in-discussion-draft: http://a11y-api.github.io/a11y-api/spec/ (last update 21 July, 2016)

We reviewed yesterday in the f2f. The design is in flux. Agreed today to rename the issue to “Extensibility of Accessibility”.

New issue #134 raised on 31-aug-2016 call to specifically review the a11y object model spec.

This issue is closed. Work continues in #134 and #107.