ARIA

[torgo]

From @LJWatson:

1. ARIA is complex. To understand ARIA it is necessary to understand accessibility mechanics (the relationship between code, browserer and accessibility API). This is something that many accessibility professionals do not understand, let alone the thousands of working developers actually building things for the web. This means ARIA is often misunderstood and misused.
2. ARIA is unexpected. When something like role="button" is used to explicitly define a role for a <span>, developers expect the transition to be complete. In other words they expect the <span> to functionally be a button in every respect, not just that it is now identified as a button in the accessibility tree. This means they do not provide the necessary behaviour and/or interaction needed to make the thing act like a button.
3. ARIA is only for screen readers plus an inconsequential amount of speech recognition tools. With buy-in from the implementors it could be much more powerful, but whilst it is constrained only to tools that use the accessibility APIs (and then only a subset of those), it exists in a silo. For example, the aria-kbdshortcuts attribute will be used to indicate to screen readers when a keyboard shortcut is available. It will not provide a functioning shortcut, nor (unless browsers decide to implement it otherwise) a visible label to indicate to sighted people that a shortcut is supposed to exist.
4. ARIA is often presented as a solution for everything. This seems like a contradiction of the previous point, but sometimes ARIA isn’t the solution at all. It is often better to look for existing solutions within the host languages (HTML, SVG etc.) or to create them there. This is essentially an architectural problem with ARIA and the way it is expanding/developing.

We will take this up at our F2F meeting in London with Léonie joining us to introduce the topic.

[chaals]

Léonie's points are important. In particular, they point to some fundamental problems with ARIA:

1. Developers have to do a lot of work to get it right, and can easily forget something or get it wrong
2. Developers are required, in this model, to implement interaction behaviour. This can only work reliably if they know the user's platform and the user's capabilities for interaction. But they do not, and can not. (This is the issue I first brought to the TAG in San Francisco in March last year). So we are asking them to solve a problem without the tools to do so.
3. For a lot of accessibility problems ARIA is irrelevant, since they don't involve any Accessibility API, but rather standard functionality. If browsers won't base behaviour on ARIA (and they probably canot re-engineer now to do so without introducing real compatibility issues) then it remains a very narrowly focused approach to a set of problems.

At the same time, it is actually useful and relatively successful in providing a practical resolution to the problems it actually addresses. We should make sure we don't throw out the baby with the bathwater.

[torgo]

Taken up at our London F2F.

[torgo]

@slightlyoff suggested that we organize a call with ARIA wg chair, an interim session with the chair and/or editors (on a teleconf) possibly building up to a “working session” at our Stockholm F2F. @torgo to reach out to ARIA wg chair to organize.

[slightlyoff]

Specifically, I'd like for us to discuss the completeness of ARIA 1.1; there seem to be HTML elements whose intrinsic roles (e.g. <p>) which cannot be reflected or re-created with ARIA 1.1. This is a major problem for Web Components and custom element authors.

In the longer-term, I'd like for us to discuss how ARIA might be made extensible and the "Accessibility Tree" that lots of specs seem to assume but which isn't spec'd anywhere.

[chaals]

An article about accessibility APIs. There is meant to be a follow-up that explains how browsers use aria to connect to that, but until it is written, you should search for other explanations of that.

[marcoscaceres]

It would be great if custom roles could be created somehow... maybe as part of?: https://wicg.github.io/a11yapi/

[LJWatson]

@marcoscaceres
"It would be great if custom roles could be created somehow..."

Agreed. Extensibility is something the ARIA WG is looking at for 2.0. AFAIK, this is the issue in question:
https://www.w3.org/WAI/ARIA/track/issues/9

@slightlyoff
"Specifically, I'd like for us to discuss the completeness of ARIA 1.1; there seem to be HTML elements whose intrinsic roles (e.g.  

 ) which cannot be
reflected or re-created with ARIA 1.1. This is a major problem for Web Components and custom element authors."

It would be useful to do a gap analysis to identify exactly which element roles are missing from ARIA at present (assuming no-one has done this already). The HTML AAM is probably the place to start [1].

Suggest this would be something to focus on for 2.0, so we don't hold 1.1 up on its way to Recc.

[1] https://www.w3.org/TR/html-aam-1.0/

[torgo]

Discussed at 25-5-2016 teleconference. Agreed for one to carve out some time at the stockholm f2f in July and at the upcoming TPAC to delve into accessibility / extensibility / components discussion further to inform the work on ARIA 2.0 requirements.

[torgo]

@dbaron wrote on IRC: ARIA at TPAC is Thursday-Friday, so maybe trying to do some joint time on Friday at TPAC would work?

[bkardell]

Tabindex and relationships for a11y is hard if you are building and managing interactive UI which requires part of the tree to temporarily be removed from focus (inert). There is a ton here https://www.w3.org/Bugs/Public/show_bug.cgi?id=24983 but as you can see it really isn't just about dialogs, the bug gives several examples of other times this is a challenge, and there are more. I know there is work happening on this, but there is still a lot to be explained in things both that we see on the web and would like to see in order to make it even plausible that they will be accessible. Even things we have used often and for a long time are actually quite difficult to actually get all the things right.

[torgo]

This will be further taken up at our next f2f in Stockholm with @LJWatson.

[torgo]

Also CCing @alice to solicit more feedback (as discussed briefly at the PWA event).

[torgo]

We discussed at Stockholm f2f (see day 2) with @LJWatson @michael-n-cooper and @richschwer. Agreed to review upcoming requirements for document for ARIA 2.0.

[ZoeBijl]

@bkardell you referring to inert attribute?

[torgo]

Agreed we need to schedule for a future call to check status but we need to figure out what the TAG's ask is.

[torgo]

Obsoleted by #156. @LJWatson if there is further feedback you would like on this please feel free to open a new issue.