role="key" anyone?

[eisaacson]

(originally posted to wai-xtech, but never got through moderator)

I would like to see a new role called "key", we started discussing it in
the Mozilla Bugzilla, here is the initial description I gave:

Accessibility on touch interfaces typically distinguish between buttons
and keys. For example in Android and iOS, when the user lands on a
button via explore by touch, they double tap to activate. Keys provide
quicker more efficient access for prolonged use, and allow the user to
simply raise their finger from the display once a key is reached to
activate.

Keys can be found in the on-screen keyboard, and in the keypad in a
phone's dialler app.

I propose introducing another ARIA role for keys, called "key". It would
be a subclass of either "button", or "command" directly.

There could be many other ways to implement this, using other attributes
and flags on the button elements, like touchtype="true".

I think introducing a new role for this makes sense because other ATs
with different input models could interpret the role to make activation
a bit easier than typical buttons. For example, a switch AT could have
shorter dwell times for keys. Or a braille display could choose to have
a special mode and markup for keys.

You can read the rest of the discussion at:
https://bugzilla.mozilla.org/show_bug.cgi?id=808596

Cheers,
 Eitan.

[Dominic Mazzoni]

Sounds great to me. I think it should be a subclass of "button" for maximum backwards compatibility, so if I understand correctly the correct way to specify it on a generic element would be:

  <div role="key button" tabIndex="0">A</div>

or alternatively I think this would be correct, right?

  <button role="key">A</button>

I know iOS already has an official interface for this, are you aware of any other platform or native accessibility API that has a mapping?

Have you already filed a w3 bug against the ARIA component?

While we're discussing the broad idea, should we provide some other attribute that indicates that touches should be passed through? There might be other reasons that a region of the screen should respond directly to touch rather than via the typical accessible support where a double-tap is required to activate.

- Dominic

--
You received this message because you are subscribed to the Google Groups "Browser Accessibility Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to browser-accessibil...@googlegroups.com.
To post to this group, send email to browser-acce...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/browser-accessibility-dev/f3ee1f76-fca6-44f4-89e5-0e0293a42053%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Eitan Isaacson]

On 03/10/2015 11:57 AM, Dominic Mazzoni wrote:

Sounds great to me. I think it should be a subclass of "button" for maximum backwards compatibility, so if I understand correctly the correct way to specify it on a generic element would be:

  <div role="key button" tabIndex="0">A</div>

I thought space delimited role lists was removed during some draft a while ago, no? We could do that?

or alternatively I think this would be correct, right?

  <button role="key">A</button>

Yes.

I know iOS already has an official interface for this, are you aware of any other platform or native accessibility API that has a mapping?

No, AFAIK at-spi and ia2 have no equivalent. But at least in Firefox and AT-SPI you could access the actual role attribute via 'xml-roles', so while the platform could fallback to a native button role, ATs could still query for a key role if they have any special behavior for that.

Have you already filed a w3 bug against the ARIA component?

Was that an option in April 2013? I didn't know about that. Anyway, I submitted a bug now. Thanks.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28187

While we're discussing the broad idea, should we provide some other attribute that indicates that touches should be passed through? There might be other reasons that a region of the screen should respond directly to touch rather than via the typical accessible support where a double-tap is required to activate.

That would definitely be cool (but very different from the proposal above that does not directly deal with touch or gestures).

Jumping ahead and thinking how we would implement that. Say there was an attribute like touch-passthru=true on a container, any touch event in a child of that container should probably have the relatedTarget be the passthrough container so we could easily filter and not call preventDefault in capture stage.

[Dominic Mazzoni]

On Tue, Mar 10, 2015 at 12:51 PM, Eitan Isaacson <eisa...@mozilla.com> wrote:

On 03/10/2015 11:57 AM, Dominic Mazzoni wrote:

Sounds great to me. I think it should be a subclass of "button" for maximum backwards compatibility, so if I understand correctly the correct way to specify it on a generic element would be:

  <div role="key button" tabIndex="0">A</div>

I thought space delimited role lists was removed during some draft a while ago, no? We could do that?

Multiple roles was an old idea that was deleted. However, the current spec says that you're supposed to list multiple space-delimited roles and the browser should use the first one it recognizes.

http://www.w3.org/html/wg/drafts/html/master/single-page.html#aria-role-attribute

Was that an option in April 2013? I didn't know about that. Anyway, I submitted a bug now. Thanks.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28187

Great, thanks!