Modernize ARIA usage, in line with ARIA 1.1 and the ARIA Authoring Practices guide.

OK, that's enough of an initial plan. Next step is to get contributors interested in doing it - we can promote it on the Slack and G.D.O channels for a11y.

It feels like this needs a thorough review of which ARIA authoring practices we can pickup.

That's right. The overall purpose of this issue is to consider each pattern from the ARIA authoring practices, to see where Drupal could benefit from using it.

I was under the assumption WCAG covered most of that, but clearly not.

The supporting documents for WCAG 2.0 do include many ARIA techniques which can help with various Success Criteria. Most of these are at the level of "providing labels for controls", and don't go as far as describing any complex components.

The WAI-ARIA Authoring Practices 1.1 is much newer that WCAG 2.0 (it's being developed to accompany ARIA 1.1). It describes patterns for the overall structure and behaviour of complex components. There's a focus on making web application widgets behave similarly to widgets in desktop applications (using equivalent roles, states, keystrokes, etc.). Examples are tab sets, accordions, collapsible nested menu links, drop-buttons, etc. Since Drupal has some components of this kind, this issue is about adopting these patterns where we can.

This isn't part of our accessibility gate - yet :-) It's one of things that I'd like to talk about in a core conversation at DrupalCon Vienna.

Update: come to think of it, while the ARIA Authoring Practices aren't part of our accessibility gate, they might increase our coverage of ATAG 2.0. I need to study that a bit more.

I think some of the keyboard behaviours described in the ARIA Authoring Practices will go towards meeting ATAG A.3.1.3 Efficient Keyboard Access. For example, the ARIA patterns for tabs and grid could reduce the number of keystrokes needed to access some settings. I already noted this possibility in #2865199-5: Adopting ARIA Grid pattern

WAI-ARIA 1.1 is now a W3C recommendation. Adding ideas about aria-current and aria-errormessage.

The batch API progress bar is currently just wrapped in a basic aria-live="polite", but it has quite a complicated structure inside. The announcements are a quite inconsistent between different screen readers.

We should evaluate using role=progressbar, with relevant properties and states. This presents the progress information in a more structured way for AT, so it might be easier to follow what's going on. Like most of the other ideas here, it will depend on how well supported it is.

I should organize the ideas list better. Some will be straight-forward to try out, others need more info.

I mentioned role="progressbar" to @John Cook - the new Batch API maintainer, who has experience of screen reader testing. He was enthusiastic about it.

We discussed the related aria-value* properties, and how these could be mapped to the values, label, and messages which a Batch API process already knows about. The idea is that assistive tech can convey progress in a way that is better matched to the platform norms, respect user verbosity settings, etc., than a simple ARIA-live region.

Alternatively, Batch API might expose a way for developers to pass their own string or tokens to aria-valuetext. Looks like a good child issue to spin out on it's own.

Added #2952488: Use aria-current=page in pagination links..

ARIA 1.1 introduces aria-modal="true" to clarify the behaviour of dialogs. Additionally, HTML 5.2 introduced a <dialog> element with an accompanying HtmlDialogElement interface.

An earlier draft of the WAI-ARIA Authoring Practices described different interaction patterns for modal vs. non-modal dialogs. I recall it suggested that non-modal dialogs should have a standard window-switching keyboard shortcut (F6?) like old HTML framesets. I went to look it up today, but it's not in the latest version which reached W3C Note status. I asked one of the editors on Twitter if it's still a thing being considered.

Adding a short placeholder in the issue summary ideas list.

Turns out there are already some modernization plans for the dropbutton component, at #1899236: Add new Splitbutton render element to eventually replace Dropbutton. The motivation there is about front-end coding practices for maintainability and theming.

So I've made #2893663: Dropbutton should report open/closed state to assistive technology a child issue for the drop-button plan. If they're going to overhaul the CSS and markup, that's the perfect opportunity to build in the accessibility improvements. I'm doubling down on using the Menu Button pattern from WAI-ARIA Authoring Practices too - the simplified markup proposal for dropbutton is already a move in that direction.

Also, the dropbutton modernization plan includes better focus styles, extending use of the blue-halo button focus style in Seven.

aria-haspopup="dialog" is new in ARIA 1.1, and would seem to be ideal for the places where we use dialogs, particularly views UI. However support for this is currently very poor in browsers and assistive tech.

Here's a test from a couple of years ago: ARIA Haspopup property.

Support hasn't improved yet. I tested recent versions of Windows 10 browsers with JAWS and NVDA, and got similar results.

JAWS bug report: Jaws does not announce token values of aria-haspopup

Support for aria-haspopup="true", per ARIA 1.0 is fairly good. We can certainly use that for things like dropbuttons I think.