Re: aria-key approach.

[Dominic Mazzoni]

My idea was that you could add elements that aren't part of the tab order and aren't visibly rendered using one of the recommended techniques for invisible screen-reader-only content. Here's an example:

<!-- At the bottom of the page -->

<section aria-label="Screen reader commands"

    style="position: absolute; clip: rect(1px, 1px, 1px, 1px)">

  <button tabindex="-1" aria-key="j">Next</button>

  <button tabindex="-1" aria-key="k">Previous</button>

</section>

Ideally you'd implement this so that those buttons actually perform the next / previous action, and the keystrokes just result in pressing those buttons. That way other types of assistive technology, like a voice control program, could also access those buttons.

On Mon, May 11, 2015 at 11:46 AM, Ramya Sethuraman <ra...@fb.com> wrote:

I like the aria-key approach with the example being adding aria-key=“c” on the gmail compose button to expose the short cut.

But, what happens for keyboard short cuts that are not exposed using a UI element on the page? For e.g.: we have the j/k keyboard shortcuts on Facebook.com that are not exposed via a button/link on the page.

Apologies if this has already been discussed in the thread.

Ramya

[Dominic Mazzoni]

Any more thoughts from anyone? From NV Access or Mozilla?

In terms of implementation, of course we could map this to the IAccessible2 attributes, but should we also map this to IAccessible::accKeyboardShortcut? It seems like a good fit and would make sense to have a way to set that field from the web.

In terms of screen reader implementation, one option is what JAWS is experimenting with now, but one can imagine other ways to make use of this information - for example a hot key that pops up a list of elements on the page with keyboard shortcuts that hints at the passthrough key where it'd be necessary - and optionally maybe other convenient ways to passthrough.

[Victor Tsaran]

Hi Dominic.

Wouldn't this markup be confusing to someone who does not see the screen? Why those buttons? Why nothing happens when I press them?

*** *** ***

Find me on Twitter http://www.twitter.com/vick08

--
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/CAFz-FYwGb6VxbXN9msXfRNSe1kKf4vLXp3VNMhbeMFWB6sT-uQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Dominic Mazzoni]

If the action that the shortcut key takes is already on the screen, for example there's already a button or a menu item for it, then you just need to associate the key with the object. I think it's a good incentive to make real buttons or menu items on the screen for actions like that, where it makes sense.

If it doesn't make sense, you just hide the buttons visually using one of the recommended techniques for invisible screen-reader-only content.

[Dominic Mazzoni]

I'm open to other ideas. As I said in another thread, my objections to data-at-shortcutkeys include:

* We can't standardize an attribute with a name like that

* We shouldn't be encouraging assistive technology to use direct DOM access; it should go through an accessibility API, 

* It's not extensible, it defines one map for keys but there's no place to add other information about commands like whether they're disabled or not, or gestures, or synonyms, etc.

I think the key idea is that I think each command you invoke should be its own element, because then we can reuse so much of the existing DOM semantics: you could mark it as disabled if the command is temporarily not available, you could mark it as hidden to temporarily remove it from the list of elements, or you could efficiently dynamically change the name of one command (for example one that toggles) without needing to regenerate a whole JSON string.

Let's brainstorm other ideas, though,

One alternative would be to use a <meta> tag in the head of the document. See the meta tag documentation and the list of registered meta extensions. I'd favor one meta tag per key rather than a single attribute containing JSON; that way each element represents one command and we have the option of adding more attributes over time - for example gestures, as Jamie suggested.

Please suggest other alternatives or ways to work around the objections above.

On Tue, May 12, 2015 at 10:32 PM, Ramya Sethuraman <ra...@fb.com> wrote:

I think having aria-key where there are visual buttons makes sense but ideally we shouldn't force developers to add invisible buttons for keyboard shortcuts.

Ramya

[Nektarios Paisios]

How about we try fixing the accesskey attribute? I know about the issues
but solutions have been suggested before. The advantage is that there
would be no need to introduce new attributes.
https://lists.w3.org/Archives/Public/public-html/2012Sep/0442.html
https://lists.w3.org/Archives/Public/public-html/2011Aug/0435.html
Nektarios.

[Dominic Mazzoni]

I don't see how we could fix accesskey without breaking backwards compatibility. Plus, it'd be similar to my original suggestion in that if you want a global keyboard shortcut you'd have to create an invisible element to attach it to.

[Nektarios Paisios]

There are some ideas in the links I provided. But I agree that this is not the easiest issue to solve.
However, it seems that there have been discussions on how to provide better support for keyboard shortcuts in the wider standards community and I think we should take our discussion there.
Nektarios.

[Alexander Surkov]

I'd be good to see proposal, but, in general, I think ARIA lacks the ability to specify user interactions. Few questions/concerns:

* aria-key is device dependent, would it be useful to have generic mechanism to describe supported user interactions?

* what is value format of aria-key? Would it be possible to provide access keys (alt+letter) vs keyboard shortcuts (cntrl+letter) vs generic interactions (for example space on button)?

Thanks.

Alexander.

--
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.

[Dominic Mazzoni]

On Wed, May 13, 2015 at 9:40 AM, Alexander Surkov <surkov.a...@gmail.com> wrote:

I'd be good to see proposal, but, in general, I think ARIA lacks the ability to specify user interactions. Few questions/concerns:

To clarify, aria-key would be indicating the presence of a keyboard shortcut for a control. It wouldn't actually change any interaction. It's basically equivalent to IAccessible::accKeyboardShortcut.

 

* aria-key is device dependent, would it be useful to have generic mechanism to describe supported user interactions?

Presumably the app knows what keyboard shortcuts it listens for on the particular device, if any. This isn't a mechanism to add event listeners, just to inform AT users about the existence of a keyboard shortcut.

 

* what is value format of aria-key? Would it be possible to provide access keys (alt+letter) vs keyboard shortcuts (cntrl+letter) vs generic interactions (for example space on button)?

The value or aria-key (or maybe aria-shortcutkey?) should be the key combination you press in order to activate this control on the page, globally. Space to activate a button wouldn't apply because that only applies when the button is focused. Specifying access keys here would be redundant, right?

As for the syntax, we could work on formally defining it if we decide to move forwards, but my first thought would be to use the key identifier names from the latest KeyboardEvent spec as the only allowed names for each key. We could use '+' as a delimiter as that's a common way to specify keyboard shortcuts, or whitespace as that's common for other aria-attributes. The order of keys would not be significant. So, a button activated by Alt, Shift, and F could be written as "Alt+Shift+F" or "Shift+F+Alt", they'd be equivalent.

[Nektarios Paisios]

On 5/13/2015 12:40 PM, Alexander Surkov wrote:
> I'd be good to see proposal, but, in general, I think ARIA lacks the
> ability to specify user interactions. Few questions/concerns:
> * aria-key is device dependent, would it be useful to have generic
> mechanism to describe supported user interactions?

That's why I proposed extending the aria-interactive idea with values
indicating specific interactions that would be permitted on an element
and its descendents. There is no way to make something that is totally
device independent though. Keyboard is sufficiently different from touch.

> * what is value format of aria-key? Would it be possible to provide
> access keys (alt+letter) vs keyboard shortcuts (cntrl+letter) vs
> generic interactions (for example space on button)?
>

How about the same format as used in keyboard event listeners.

[Alexander Surkov]

On Wed, May 13, 2015 at 12:50 PM, Dominic Mazzoni <dmaz...@google.com> wrote:

On Wed, May 13, 2015 at 9:40 AM, Alexander Surkov <surkov.a...@gmail.com> wrote:

I'd be good to see proposal, but, in general, I think ARIA lacks the ability to specify user interactions. Few questions/concerns:

To clarify, aria-key would be indicating the presence of a keyboard shortcut for a control. It wouldn't actually change any interaction. It's basically equivalent to IAccessible::accKeyboardShortcut.

Sure.

 

 

* aria-key is device dependent, would it be useful to have generic mechanism to describe supported user interactions?

Presumably the app knows what keyboard shortcuts it listens for on the particular device, if any. This isn't a mechanism to add event listeners, just to inform AT users about the existence of a keyboard shortcut.

I meant a different thing I think. I was curious if the app needs to describe interactions on more devices, for example, if a control support "swipe" on touchpad.

 

 

* what is value format of aria-key? Would it be possible to provide access keys (alt+letter) vs keyboard shortcuts (cntrl+letter) vs generic interactions (for example space on button)?

The value or aria-key (or maybe aria-shortcutkey?)

I like being short :)

 

should be the key combination you press in order to activate this control on the page, globally. Space to activate a button wouldn't apply because that only applies when the button is focused.

 

Specifying access keys here would be redundant, right?

because the author is expected to use existing HTML mechanism, correct?

so is aria-key restricted to "ctrl+letter" only?

[Alexander Surkov]

On Wed, May 13, 2015 at 12:59 PM, 'Nektarios Paisios' via Browser Accessibility Development <browser-acce...@googlegroups.com> wrote:

On 5/13/2015 12:40 PM, Alexander Surkov wrote:

I'd be good to see proposal, but, in general, I think ARIA lacks the ability to specify user interactions. Few questions/concerns:
* aria-key is device dependent, would it be useful to have generic mechanism to describe supported user interactions?

That's why I proposed extending the aria-interactive idea with values indicating specific interactions that would be permitted on an element and its descendents. There is no way to make something that is totally device independent though. Keyboard is sufficiently different from touch.

this may be interesting, can you spec a proposal?

 

* what is value format of aria-key? Would it be possible to provide access keys (alt+letter) vs keyboard shortcuts (cntrl+letter) vs generic interactions (for example space on button)?

How about the same format as used in keyboard event listeners.

do you have an example at hand to make sure we are on the same page?

 

--
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/555382E9.5000902%40google.com.

[Dominic Mazzoni]

On Wed, May 13, 2015 at 10:44 AM, Alexander Surkov <surkov.a...@gmail.com> wrote:

I meant a different thing I think. I was curious if the app needs to describe interactions on more devices, for example, if a control support "swipe" on touchpad.

I think it'd be great to create another attribute for that, like aria-gesture="swipe". We'd have to clearly define the gesture language.

Do you agree that aria-key is compatible with the idea of also working on aria-gesture, and we wouldn't have to wait for aria-gesture in order to support aria-key sooner since it's more straightforward? If so maybe we can try to reach a consensus here and start a new thread on aria-gesture.

so is aria-key restricted to "ctrl+letter" only?

It can include letters by themselves, ctrl+letter, alt+shift+number, basically anything that you can register a global keyboard event listener for now.

[Alexander Surkov]

I think it sounds good with me. What is a connection with aria-interactive?

[Nektarios Paisios]

On 5/13/2015 2:55 PM, Alexander Surkov wrote:
> I think it sounds good with me. What is a connection with
> aria-interactive?
>

aria-interactive is for telling the screen reader to turn off some of
the special handling of shortcut keys. This is not related to the
aria-key proposal and so aria-key can move forward independently.
Nektarios.

[Dominic Mazzoni]

Yeah, let's continue that on a separate thread.

It sounds like the Facebook folks aren't totally convinced that aria-key will meet their needs, so I'd like to see them either get on board or propose an alternative, but I do think it solves a number of other interesting use cases and it's easy to implement, so let's bring it to PFWG next for more feedback.