Open jnurthen opened 6 years ago
This would be really useful. Particularly if it was paired with aria-interactivedescription
in the same way that role
can have a roledescription
.
So, for the interactive slide title example, authors could say something like:
<h1 tabindex=0
aria-interactive="true"
aria-interactivedescription="press the arrow keys to move the title; press Enter to edit the title text">
Slide title
</h1>
For a "pan control" in a map, authors could give a role description and a description of the interaction:
<...
roledescription="pan"
aria-interactive="true"
aria-interactivedescription="press the arrow keys to pan north, south, east or west"
>
This is the markup for an interactive slide title that you can position on the page with arrow keys when focused:
<h1 tabindex=0 aria-interactive="true">Slide title</h1>
This can be helpful.
Question: Since keyboard navigation instructions and methods vary depending on the type of control, shouldn't there be a role too? Wouldn't the screen reader vendor need a role to map navigation keys in forms mode?
Wouldn't the screen reader vendor would need the role to map navigation keys in forms mode?
Yes, I guess a text description isn't enough info for the AT. They'd need a list of keys to pass through.
Anyhow, I'm guessing this is a pipe dream. It would be very powerful, but...
"With great power comes great responsibility...". ;)
A good start would be to influence AT vendors to extend their "forms mode" control set that it covers all active ARIA roles and does automatic mode switching from reading modes to interaction modes when encountering those with active handlers on it. This should be the first step.
Before inventing a new property aria-interactive this should be clarified if classic solutions can do the trick, too.
For things that remain like active headings (the example) I think we have two options
<span role="button" tabindex="0" onclick="doSomething()"><h1> Do something</h1></span>
or
<h1><span role="button" tabindex="0" onclick="doSomething()">Do something></span></h1>
Focus is on button element in both cases. Which variant is correct for HTML validators? And, having clarified that, what should AT announce? "Button Heading Level 1 Do Something" or "Heading Level 1 Button Do something"?? Or just one role? Who defines this?
But if you have active stuff that is considered by HTML as inactive: it does not help to declare clickable headings as "red herring" in HTML because people do code this. And it is needed and simply useful. Another example are active list items. Even entire sections can be active and are coded already likewise (especially triggered by Tap on mobile devices).
I doubt that an aria-interactive flag will be correctly understood and accepted by AT since then many discussions will start and interaction algorithm was always based on known role for an element and this is (by nature) totally unknown for a heading since it is not interactive. The only thing that would help in my opinion is that HTML5 itself extends its definitions what is an active element and what is not and will never be.
Headings and list items would be a good start to be included in the first list. Consequently, for all elements interactions are NOT allowed browsers immediately should stop the JS event support (since this is invalid code then) and THAT is the can of worms they want to avoid at all cost because it will break tons of code out there.
Regarding ARIA 1.1: in the end it would be better to collect ARIA structural roles that may be used also interactively and use aria-roldescription to express that when it is so and aria-describedby for a keyboard usage description (having no designated property for this yet). But this requires that AT is reading and announcing roledescription also for structural roles which is not so 100% clear for me in the moment that they will do that.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27866