Last Comment Bug 808596 - Add new ARIA role for key buttons
: Add new ARIA role for key buttons
Status: RESOLVED FIXED
[proposed ARIA]
:
Product: Core
Classification: Components
Component: Disability Access APIs (show other bugs)
: Trunk
: All All
: -- normal (vote)
: mozilla23
Assigned To: Eitan Isaacson [:eeejay]
:
Mentors:
Depends on:
Blocks: aria
  Show dependency treegraph
 
Reported: 2012-11-05 08:43 PST by Eitan Isaacson [:eeejay]
Modified: 2013-05-21 11:11 PDT (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
23+


Attachments
Introduce key role. (2.44 KB, patch)
2012-11-09 11:09 PST, Eitan Isaacson [:eeejay]
surkov.alexander: feedback+
Details | Diff | Review
Bug 808596 - Introduce key role. (2.47 KB, patch)
2013-04-25 10:27 PDT, Eitan Isaacson [:eeejay]
surkov.alexander: review+
Details | Diff | Review

Description Eitan Isaacson [:eeejay] 2012-11-05 08:43:44 PST
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.
Comment 1 alexander :surkov 2012-11-06 21:21:25 PST
It doesn't seem it falls into ARIA role concept (especially into widgets role like button or command). It seems to be closer to xul:key element. Anyway if ARIA could introduce keyboard shortcuts support then it could be worth idea. Does standard keyboard shortcuts support doesn't work?
Comment 2 James Teh [:Jamie] 2012-11-06 21:26:07 PST
I'd argue it does fit the concept of a role. It's slightly different to a button in terms of how the user perceives it, even though it might have the same API behaviour.

I'm not sure I follow what you mean about keyboard shortcuts. This is so that an AT knows that a particular element is a key on an on-screen keyboard.
Comment 3 alexander :surkov 2012-11-06 21:30:45 PST
I must misread the original idea. Can you give me an example of it?
Comment 4 James Teh [:Jamie] 2012-11-06 21:44:21 PST
This would be used for individual keys on on-screen keyboards and dialpads, such as in Firefox OS. There is a need to distinguish between buttons and keys because some AT users (such as screen reader users) interact with them differently, particularly when using a touch screen.
Comment 5 alexander :surkov 2012-11-06 22:55:46 PST
(In reply to James Teh [:Jamie] from comment #4)
> This would be used for individual keys on on-screen keyboards and dialpads,
> such as in Firefox OS. There is a need to distinguish between buttons and
> keys because some AT users (such as screen reader users) interact with them
> differently, particularly when using a touch screen.

Ok, got it. Maybe it makes sense to have a role/landmark for containers like dialpad?
Comment 6 Marco Zehe (:MarcoZ) 2012-11-07 01:07:52 PST
(In reply to alexander :surkov from comment #5)
> Ok, got it. Maybe it makes sense to have a role/landmark for containers like
> dialpad?

No, it makes more sense to have a distinct role for a virtual key, since those on-screen keyboards usually consist of keys *and* regular buttons. In iOS, for example, the button to insert a newline is not a key, but a button. If iOS is set to touch typing, meaning the key gets entered when you lift your finger, the enter key behaves differently (on purpose) since lifting the finger does not enter this particular one automatically, one has to specifically double-tap to enter it. This is desired, and your landmark solution would potentially put *all* controls in keyboard mode. I therefore think Eitan's approach makes more sense here.
Comment 7 Eitan Isaacson [:eeejay] 2012-11-07 07:27:26 PST
(In reply to Marco Zehe (:MarcoZ) from comment #6)
> (In reply to alexander :surkov from comment #5)
> > Ok, got it. Maybe it makes sense to have a role/landmark for containers like
> > dialpad?
> 
> No, it makes more sense to have a distinct role for a virtual key, since
> those on-screen keyboards usually consist of keys *and* regular buttons. In
> iOS, for example, the button to insert a newline is not a key, but a button.
> If iOS is set to touch typing, meaning the key gets entered when you lift
> your finger, the enter key behaves differently (on purpose) since lifting
> the finger does not enter this particular one automatically, one has to
> specifically double-tap to enter it. This is desired, and your landmark
> solution would potentially put *all* controls in keyboard mode. I therefore
> think Eitan's approach makes more sense here.

With that said, on the app implementation side it is a good idea to contain the keys within a group with a label of "Keyboard", or "Dialpad". But that is just a usability note.
Comment 8 alexander :surkov 2012-11-07 15:51:52 PST
Do we need ask for new IA2 role for that or is xml-roles is enough?
Comment 9 James Teh [:Jamie] 2012-11-07 15:56:54 PST
There's probably no practical use for this on Windows except in testing, since I imagine Firefox (and other apps) will use the Windows on-screen keyboard. Therefore, there's probably not much point in having an IA2 role. However, if it does become useful in Windows, it should have its own IA2 role.
Comment 10 alexander :surkov 2012-11-07 16:09:13 PST
Basically it means we don't need new roles in ARIA. Putting things for b2g only into standard doesn't seem reasonable.
Comment 11 James Teh [:Jamie] 2012-11-07 16:16:01 PST
It could be useful on other mobile platforms as well. For example, there might be a web application which displays a keypad which works on both iOS and Firefox OS.

I guess that does suggest it might be useful on Windows. Perhaps I'm just biased, since before Windows 8, touch screens weren't a big thing on Windows. Certainly, NVDA does support touch screen usage with Windows 8, so with the above example, a new role would benefit us.
Comment 12 Eitan Isaacson [:eeejay] 2012-11-09 10:28:21 PST
(In reply to James Teh [:Jamie] from comment #11)
> It could be useful on other mobile platforms as well. For example, there
> might be a web application which displays a keypad which works on both iOS
> and Firefox OS.
> 

Yeah. Just what you said. Firefox OS apps are not exclusively for Firefox OS, they are designed to work on any platform with any browser. So Firefox is a good place to start, but other user agents will need to eventually add this too.
Comment 13 Eitan Isaacson [:eeejay] 2012-11-09 10:29:12 PST
(In reply to alexander :surkov from comment #10)
> Basically it means we don't need new roles in ARIA. Putting things for b2g
> only into standard doesn't seem reasonable.

What I said above was a reply to this.
Comment 14 Eitan Isaacson [:eeejay] 2012-11-09 11:06:52 PST
(In reply to alexander :surkov from comment #8)
> Do we need ask for new IA2 role for that or is xml-roles is enough?

I wrote a patch that adds a new nsIAccessibleRole, but if we do xml-roles, that is not needed? That actually sounds like a not bad migration path, have buttons with additional "key" in xml-roles. But I am not sure how that aligns with how multiple roles are defined.
Comment 15 Eitan Isaacson [:eeejay] 2012-11-09 11:09:07 PST
Created attachment 680154 [details] [diff] [review]
Introduce key role.

This is what I have, any input is welcome. Maybe we need to add a moz prefix since it is not part of the ARIA spec?


Feedback: surkov.alexander@gmail.com
Comment 16 David Bolter [:davidb] 2012-11-09 11:32:52 PST
I wouldn't prefix this.

Henri, can you advise here? Here is the deal:

We want to use an new undocumented value for the role attribute. For example:

<div role="key">esc</div>

This is driven by the want to improve the user experience for users of b2g who are blind. A use case is the dialer keypad. I think we can just go ahead and use it unprefixed as per the current patch but wanted your thoughts. Obviously we would tell the ARIA group what we are doing and why.
Comment 17 alexander :surkov 2012-11-09 17:42:49 PST
(In reply to Eitan Isaacson [:eeejay] from comment #15)
> Created attachment 680154 [details] [diff] [review]
> Introduce key role.
> 
> This is what I have, any input is welcome.

I don't have problems with the patch (perhaps I didn't get usual to 'key' role because it sounds ambiguous). What ARIA says about unknown roles processing? (I just need to make sure we don't break the spec by extending it).

> Maybe we need to add a moz prefix
> since it is not part of the ARIA spec?

that should fall into usual ARIA role extension practice. it doesn't deny but it doesn't suppose to use prefixes.
Comment 18 alexander :surkov 2012-11-11 19:55:53 PST
Comment on attachment 680154 [details] [diff] [review]
Introduce key role.

Review of attachment 680154 [details] [diff] [review]:
-----------------------------------------------------------------

::: accessible/src/base/RoleMap.h
@@ +1053,5 @@
> +     ATK_ROLE_PUSH_BUTTON,
> +     NSAccessibilityButtonRole,
> +     ROLE_SYSTEM_PUSHBUTTON,
> +     ROLE_SYSTEM_PUSHBUTTON,
> +     eFromSubtree)

role="button" aria-pressed="true" is exposed as toggle button, but this one will be exposed as a button. It seems we should use toggle button until we have a better mapping on platform layer.

if it has popup then we use buttonmenu role (see Accessible::ARIATransformRole)
Comment 19 Henri Sivonen (:hsivonen) 2012-11-12 00:56:33 PST
(In reply to David Bolter [:davidb] from comment #16)
> I wouldn't prefix this.
> 
> Henri, can you advise here? Here is the deal:
> 
> We want to use an new undocumented value for the role attribute. For example:
> 
> <div role="key">esc</div>
> 
> This is driven by the want to improve the user experience for users of b2g
> who are blind. A use case is the dialer keypad. I think we can just go ahead
> and use it unprefixed as per the current patch but wanted your thoughts.
> Obviously we would tell the ARIA group what we are doing and why.

I think it makes sense not to prefix (and to let the ARIA group know what’s happening).

If the ARIA group agrees, and makes "key" part of their spec, there’s no need to transition.

If the ARIA group disagrees, they can still cooperate by not using "key" for an incompatible purpose.
Comment 20 alexander :surkov 2012-11-18 18:09:09 PST
need feedback on comment #17
Comment 21 alexander :surkov 2012-11-18 18:09:09 PST
need feedback on comment #17
Comment 22 alexander :surkov 2012-11-18 18:10:35 PST
Comment on attachment 680154 [details] [diff] [review]
Introduce key role.

I don't have issue with the patch if comment #17 is answered positively.
Comment 23 David Bolter [:davidb] 2012-11-19 07:01:11 PST
(In reply to alexander :surkov from comment #17)
> (In reply to Eitan Isaacson [:eeejay] from comment #15)
> > Created attachment 680154 [details] [diff] [review]
> > Introduce key role.
> > 
> > This is what I have, any input is welcome.
> 
> I don't have problems with the patch (perhaps I didn't get usual to 'key'
> role because it sounds ambiguous). What ARIA says about unknown roles
> processing? (I just need to make sure we don't break the spec by extending
> it).

I couldn't find a place where it explicitly breaks the spec or implementation guide. If we land it we should not publically tout it as an addition to ARIA unless/until it actually becomes so. I don't expect it will be hard to get into ARIA.next.

The place to propose it is wai-xtech (wai-xtech@w3.org). Eitan can you post to the list and describe the motivation for the new role?

Or let me know if you want me to do it.
Comment 24 Eitan Isaacson [:eeejay] 2013-04-25 10:27:13 PDT
Created attachment 741929 [details] [diff] [review]
Bug 808596 - Introduce key role.

A rebased version of the previous patch. Up for review.
Comment 25 alexander :surkov 2013-04-25 19:11:07 PDT
Comment on attachment 741929 [details] [diff] [review]
Bug 808596 - Introduce key role.

Review of attachment 741929 [details] [diff] [review]:
-----------------------------------------------------------------

::: accessible/src/base/nsARIAMap.cpp
@@ +230,5 @@
> +    ePressAction,
> +    eNoLiveAttr,
> +    kNoReqStates,
> +    eARIAPressed
> +  },

you need to wait for bug 864646 which is on inbound and update your patch

also, add missed kGenericAccType into the structure
Comment 27 Ed Morley [:emorley] 2013-04-30 05:59:51 PDT
https://hg.mozilla.org/mozilla-central/rev/7f6151df4160
Comment 28 Lukas Blakk [:lsblakk] use ?needinfo 2013-05-08 13:23:58 PDT
Is this another 'developer' tagged note? Does it require web page code changes for there to be user impact?
Comment 29 alexander :surkov 2013-05-08 18:08:46 PDT
It was introduced for Firefox OS apps/webapps
Comment 30 Lukas Blakk [:lsblakk] use ?needinfo 2013-05-21 11:11:35 PDT
This has been noted in the Aurora 23 release notes:

http://www.mozilla.org/en-US/firefox/23.0a2/auroranotes/

If you would like to make any changes or have questions/concerns please contact me directly.

Note You need to log in before you can comment on or make changes to this bug.