Web Application Reserved Keystrokes in JAWS

[Dominic Mazzoni]

The latest version of JAWS includes the option to allow web applications to reserve keystrokes so that they aren't intercepted by JAWS. I think this might be a good idea but I don't like the syntax they chose to use. What do others think of this idea, and any ideas for a more standards-based way to accomplish the same thing?

http://www.freedomscientific.com/downloads/jaws/JAWSWhatsNew

https://www.facebook.com/help/1619443878293091

http://tink.uk/time-to-revisit-accesskey/

http://podcast.freedomscientific.com/FSCast/episodes/FSCast107-JAWS_Improved_Facebook_Support,_J-Dictate_and_Leasey.mp3

[James Teh]

Copying Jeff Wieland from Facebook.

We understand how this might be useful, but we have some reservations
concerning both UX and technical implementation.

Regarding UX, the problem is that this idea, while convenient, creates
inconsistency. When in browse mode, users should be able to expect that
single letter keys perform quick navigation as they usually do for
browse mode and as they do on every other page. If you want otherwise,
you can switch to focus mode. The question is whether convenience
outweighs inconsistency in this case. It all depends what a user is more
likely to try first: a web app key or a quick nav key.

It's worth noting that this is not just applicable to Windows screen
readers with "virtual buffers". It also applies to quick nav with
VoiceOver on the Mac when single-key webpage navigation is enabled. This
isn't enabled by default, but it's reasonable to assume that many users
would enable this for efficient navigation. I've had several users
confirm that these keys *are* overridden in this case.

Regarding implementation, using a data- attribute is never going to be
something that could be properly standardised. It also requires direct
DOM access (which not all AT/browser combinations have).

I also think this concept could be broadened somewhat. For example, on
iOS, there is a rotor setting which allows you to select quick actions
for the current element that sighted users would access using other
gestures (some of which might not be possible with VoiceOver running).
(This would also be useful with other touch-based screen readers and may
already be implemented for some others already.) This concept could be
broadened so that it was a list of actions and the key to trigger the
action was just one piece of data associated with that action. I'm not
sure of the syntax, though. It's rather complicated because it needs to
be a list of maps or similar. JSON does seem to fit nicely, but that
hasn't been done anywhere else in the ARIA spec.

We're certainly very keen to hear others' thoughts on this.

Jamie

On 9/05/2015 3:51 AM, 'Dominic Mazzoni' via Browser Accessibility

> --
> 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
> <mailto:browser-accessibil...@googlegroups.com>.
> To post to this group, send email to
> browser-acce...@googlegroups.com
> <mailto:browser-acce...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/browser-accessibility-dev/CAFz-FYxwqXSti8bYR7r0M5OE%3DU%3DTEaaY1P6jnOg7hxACHq0B1A%40mail.gmail.com
> <https://groups.google.com/d/msgid/browser-accessibility-dev/CAFz-FYxwqXSti8bYR7r0M5OE%3DU%3DTEaaY1P6jnOg7hxACHq0B1A%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

--
James Teh
Executive Director, NV Access Limited
Ph +61 7 3149 3306
www.nvaccess.org
Facebook: http://www.facebook.com/NVAccess
Twitter: @NVAccess
SIP: ja...@nvaccess.org

[Dominic Mazzoni]

On Mon, May 11, 2015 at 12:08 AM, James Teh <ja...@nvaccess.org> wrote:

We understand how this might be useful, but we have some reservations concerning both UX and technical implementation.

Regarding UX, the problem is that this idea, while convenient, creates inconsistency. When in browse mode, users should be able to expect that single letter keys perform quick navigation as they usually do for browse mode and as they do on every other page. If you want otherwise, you can switch to focus mode. The question is whether convenience outweighs inconsistency in this case. It all depends what a user is more likely to try first: a web app key or a quick nav key.

I totally understand your concerns. Anecdotally, though, I've heard from many users who found the help documentation for web apps like Gmail or Google Drive and weren't able to figure out how to press global shortcut keys. They realized that when they pressed a key that the screen reader was interpreting it as a browse mode / quick nav key, but they didn't know what to do, they didn't know there was a passthrough key and didn't even know such a thing might exist.

I think role=application was originally intended to address this problem, but it ended up going too far, because it leaves users with too few screen reader commands to work with. I think some sort of hybrid really is needed.

By the way, I think aria-interactive ought to be part of this solution. It doesn't help with global keyboard shortcuts, but it perfectly solves the problem where an application has a control on the page that supports more than just its typical default action.

Still, I think that the idea of allowing web apps to take over a few keyboard commands while the screen reader is still in browse mode / virtual cursor mode might be a good idea. If implemented well, a web app could provide better access with its own global shortcuts, while leaving alone basic virtual buffer navigation using the arrow keys. (In cases where the app wants arrow keys, it can do so when the user is focused on a specific control, possibly using aria-interactive to help.)

Jamie, what would you think if the screen reader announced the presence of web app key commands when a page loads, giving users the choice at that time?

Another idea that one of our Google colleagues, Nektarios, had, was to provide another passthrough option, perhaps the Right-Ctrl key, and then this spec could simply be a way to advertise keystrokes.

 

It's worth noting that this is not just applicable to Windows screen readers with "virtual buffers". It also applies to quick nav with VoiceOver on the Mac when single-key webpage navigation is enabled. This isn't enabled by default, but it's reasonable to assume that many users would enable this for efficient navigation. I've had several users confirm that these keys *are* overridden in this case.

Good point.

 

Regarding implementation, using a data- attribute is never going to be something that could be properly standardised. It also requires direct DOM access (which not all AT/browser combinations have).

Totally agreed. Options include an ARIA attribute, a meta tag, or even a JavaScript API.

 

I also think this concept could be broadened somewhat. For example, on iOS, there is a rotor setting which allows you to select quick actions for the current element that sighted users would access using other gestures (some of which might not be possible with VoiceOver running). (This would also be useful with other touch-based screen readers and may already be implemented for some others already.) This concept could be broadened so that it was a list of actions and the key to trigger the action was just one piece of data associated with that action. I'm not sure of the syntax, though. It's rather complicated because it needs to be a list of maps or similar. JSON does seem to fit nicely, but that hasn't been done anywhere else in the ARIA spec.

I also feel like JSON is a bit unusual in the value of an HTML attribute. I feel like there ought to be a cleaner way to do it.

 

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/55505586.9080308%40nvaccess.org.

[Dominic Mazzoni]

Here's a specific alternate proposal.

Instead of declaring all of the keyboard shortcuts in one place, the web app takes buttons, links, menu items, and any other HTML elements on the page that have a default action when pressed, and adds attributes to them that specify what global keyboard shortcut also triggers this action.

Web apps would be free to create offscreen buttons or links and take them out of the default tab order if they wish to expose these commands only to screen reader users, but whever possible, they should just add these annotations to existing elements.

As an example, there's a "Compose" button in Gmail that has a default global keyboard shortcut of 'c'. I propose we annotate it like this:

<button aria-key="c">Compose</button>

This fits really easily with the idea that we could later add support for gestures, too. The hard part there might be describing gestures in a neutral way.

As for describing keystrokes involving other keys, I propose that we use the string names from the latest KeyboardEvent spec to define the exact spelling for each non-alphanumeric key and modifier key.

- Dominic

[Dominic Mazzoni]

A couple of other notes about this proposal:

* It allows a screen reader to announce the keyboard shortcut when the user browses to a button or menu item, increasing discoverability. This is similar to how users can discover shortcuts for menu items by browsing an application's menu bar. I think people learn far more shortcuts there than they do reading help.

* It ensures there's a programmatic way to activate any global command without necessarily pressing the key - for example, voice control software could expose these commands to users, or a mobile screen reader could provide a menu of all global commands on the page.

[Nektarios Paisios]

I don't think that we necessarily need another standard in order to provide specific keystrokes or gestures that would be exclusively used by users of assistive technology. All we need, in my opinion, is for a way to specify that a widget is interactive and to what extend.

I propose merging this with Dominic's "aria-interactive" idea in the following manner:

1. aria-interactive="all": Don't intercept any keys while this widget is focused. Works like Focus / Forms Mode.

2. aria-interactive="typing": Dont intercept any typing keys while the focus is on this widget, but cursors and other navigation keys may optionally be intercepted if the assistive technology so desires.

3. aria-interactive="navigation" Don't intercept any navigation keys but you may intercept typing keys. Useful for list or treeview widgets that can handle the cursors properly but which don't provide first letter navigation, a feature that the screen reader may want to provide.

I know that this idea needs improvement, specifically, we should think how to improve the wording of the attribute's value in such a way that it would be well-understood by web authors. Nevertheless, it can be a startingpoint.

I find this easier than trying to come up with a new way of attaching special keystrokes or gestures. It doesn't compete with the existing ways of specifying keyboard listenners and so would need minimal changes to existing web apps.

Concerning Dominic's latest idea for aria-key, it also deals with an orthogonal issue, the discoverability of keyboard shortcuts. Personally, I think that we should distinguish between global vs. widget-specific shortcuts. On Facebook or in Gmail "j" and "k" should not be used when you are not focused on the timeline as they are specific to moving among your posts. Similarly, you don't want a global shortcut for "like". So, I don't think that we should use an aria attribute to define global shortcuts like this.

For discoverability, we could use the "title" attribute for listing the shortcut key because it's already being used for that purpose on some websites. We should agree on a syntax that screen readers could parse.

Nektarios.

[Nektarios Paisios]

To be clear, I am not against defining an aria-shortcut attribute, but
we should think carefully before proposing it so that we don't cause
confusion between local vs. global shortcuts. I mentioned the "title"
attribute because at least the author can see its effect and would be
less likely to use it to display local shortcuts or display shortcuts
that would not be valid for the current context. I know it has various
shortcomings though.
Nektarios.

[Alexander Surkov]

I prefer aria-key approach since it is part of the standard and it benefits in that it will be exposed at no cost in IA2/ATK/Firefox as object attribute.

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/browser-accessibility-dev/CAFz-FYw7JxrbChwnfxV8p4%2Bnk1c_ka8G0ZTkRnJqr-u7mMLjFA%40mail.gmail.com.

[Victor Tsaran]

Hi Nektrarios.

While I agree with your bullets in principal, I think we may be overloading the issue before it had a chance to grow! :)

In particular, defining what's global and what's local is probably going to cause a lot of head-scratching among developers -- not impossible, just may call for more questions than  it's worth.

Also, I am not sure I would tie the user of web app-specific shortcuts to the aria-interactive attribute as tempting as it may be. I am not saying the two attributes should not work together, just not certain they should be coupled as a requirement.

[Nektarios Paisios]

On 5/11/2015 2:39 PM, Victor Tsaran wrote:
> Hi Nektarrios.

> While I agree with your bullets in principal, I think we may be
> overloading the issue before it had a chance to grow! :)

I am trying to decouple the two issues: discoverability and passthrough.

> In particular, defining what's global and what's local is probably
> going to cause a lot of head-scratching among developers -- not
> impossible, just may call for more questions than it's worth.

Correct. But we don't need to make local shortcuts discoverable with an
aria attribute, only global ones for now.

> Also, I am not sure I would tie the user of web app-specific shortcuts
> to the aria-interactive attribute as tempting as it may be. I am not
> saying the two attributes should not work together, just not certain
> they should be coupled as a requirement.
>

Indeed. I am not coupling them.
1. Discoverability: aria-shortcutkey or whatever we call it will enable
screen readers to announce global shortcuts to the user either in the
form of a list (upon request) or when navigating to the element that has
the global shortcut defined. Optionally, the screen reader could allow
the user to invoke such shortcuts from a screen reader menu, without
having to press them. Much like users of desktop apps can go through the
global commands in an application menu.
2. Passthrough: aria-interactive="typing" or whatever we choose to call
it would allow certain groups of keystrokes to be passed through to the
web app instead of being "eaten" by the screen reader. This will only
occur if the widget with the "aria-interactive" attribute is focused and
not in cases where the virtual screen reader cursor is on any other
widget. This solves the issues created by role="application" whilst also
defining that only certain categories of keys should not be intercepted,
thus allowing the use of the cursors to navigate through text in certain
types of interactive elements.
I am aware of the fact that this proposal needs to be fleshed out more.
Nektarios.

[Dominic Mazzoni]

On Mon, May 11, 2015 at 1:46 PM, 'Nektarios Paisios' via Browser Accessibility Development <browser-acce...@googlegroups.com> wrote:

2. Passthrough: aria-interactive="typing" or whatever we choose to call it would allow certain groups of keystrokes to be passed through to the web app instead of being "eaten" by the screen reader.

I don't understand why this is needed. When the user lands on an element with a role of text field, slider, combo box, list box, etc. now, they're automatically put in focus mode / forms mode, and then all keystrokes go to the web app. That already works pretty well. Aria-interactive just allows the web app to specify that an element wants that same behavior even if it's not one of those predefined roles. So I don't see the need for a value like "typing".

Or are you proposing that aria-interactive could also allow some keystrokes to go to the web app even in browse mode / virtual cursor mode? If so, that seems potentially really confusing. Suppose you land on such an element that eats all keystrokes even though you're still navigating the virtual buffer - how would you override that element and jump to the next heading or link? The advantage of the current aria-interactive proposal is that it preserves the existing two modes and the feedback you get when auto focus mode / auto forms mode is on.

[Nektarios Paisios]

On 5/11/2015 4:56 PM, Dominic Mazzoni wrote:

On Mon, May 11, 2015 at 1:46 PM, 'Nektarios Paisios' via Browser Accessibility Development <browser-acce...@googlegroups.com> wrote:

2. Passthrough: aria-interactive="typing" or whatever we choose to call it would allow certain groups of keystrokes to be passed through to the web app instead of being "eaten" by the screen reader.

I don't understand why this is needed. When the user lands on an element with a role of text field, slider, combo box, list box, etc. now, they're automatically put in focus mode / forms mode, and then all keystrokes go to the web app. That already works pretty well. Aria-interactive just allows the web app to specify that an element wants that same behavior even if it's not one of those predefined roles. So I don't see the need for a value like "typing".

But we don't want that same behavior when we are on Facebook's timeline or when in Gmail's email list. We want to be able to use "j" and "k" to navigate but also be able to use the cursors to read the text at our own pace.

Or are you proposing that aria-interactive could also allow some keystrokes to go to the web app even in browse mode / virtual cursor mode? If so, that seems potentially really confusing. Suppose you land on such an element that eats all keystrokes even though you're still navigating the virtual buffer - how would you override that element and jump to the next heading or link? The advantage of the current aria-interactive proposal is that it preserves the existing two modes and the feedback you get when auto focus mode / auto forms mode is on.

If it eats all keystrokes it would not be called browse / virtual cursor mode, it would be interactive /focus mode. If only the typing keys would be sent to the application but cursors would not, then it would behave closer to browse / virtual cursor mode and you would still be able to use cursors and tab to move out of that widget.
How this is surfaced to the user is up for discussion. However, the confusion that might arise out of this is not greater and I would say it's much less than the ability for websites to globally override some screen reader shortcuts.
Nektarios.

[Nektarios Paisios]

* It ensures there's a programmatic way to activate any global command without necessarily pressing the key - for example, voice control software could expose these commands to users, or a mobile screen reader could provide a menu of all global commands on the page.

That's a good idea. I think that modal screen readers could implement it for example by using the right control key as a way to activate such a global menu. If a user presses and then releases the right control key, a menu with all the global commands would appear. If the user presses the right control with a specific shortcut listed in the menu, the associated command would be activated without opening the menu.

Some concerns though:

 1. aria-hidden should be used if a global command is temporarily unavailable, e.g., if a dialog box is being shown. For example, the Next/Previous global commands on Facebook's timeline should tempoararily be unavailable when the Comment dialog is being shown. Since these commands are offscreen, aria-hidden could be used to signify that they are unavailable. This hsould be added to the standard.

2. aria-disabled should perhaps be used if a global command should appear still on the global menu but should be grade out?

Nektarios.

[Victor Tsaran]

Nektarios.

A tiny quibble, but right control is not present on many laptop computers. Using the modifier in this way could also be confusing to novice users.

*** *** ***

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/1e53681c-1a9a-4714-a2d1-61f494dedde3%40googlegroups.com.

[Nektarios Paisios]

To be honest I have seen many laptops without the right Windows key (in fact almost all of them are without it) and without the applications key. But the right control I have always found it there. That doesn't mean that it's on all laptops, but it's something to think about.
Concerning novice users, on the contrary it would be very helpful, especially for such users, to have such a menu-like feature on the Web.
However, as with all ideas, until we try it we'll never know.
Nektarios.

[Victor Tsaran]

VoiceOver, for example, allows assigning the right COMMAND key to one of its features.

It's probably not worth discussing this right now, I just thought to point out.

:)

*** *** ***

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

[Nektarios Paisios]

I know but this solution is geared towards Windows screen readers with virtual buffers. In Voiceover effectively passing keys through to the web app might not be such a big issue because most users might not have quick nav keys on. For bringing up the menu another shortcut could be used such as VO+shift+k?
Nektarios.

[Nektarios Paisios]

Agreed. This should not be part of the standard. I was just speculating on a possible implementation.
Nektarios.

On 5/13/2015 1:50 PM, Victor Tsaran wrote:

Why don't we let screen readers decide on what shortcut key to use. 

Sent from a Mobile device

[Victor Tsaran]

Why don't we let screen readers decide on what shortcut key to use. 

Sent from a Mobile device

[James Teh]

Hi Dominic,

On 12/05/2015 1:52 AM, Dominic Mazzoni wrote:
> Regarding UX, the problem is that this idea, while convenient,
> creates inconsistency. When in browse mode, users should be able to
> expect that single letter keys perform quick navigation as they
> usually do for browse mode and as they do on every other page.

> I totally understand your concerns. Anecdotally, though, I've heard from
> many users who found the help documentation for web apps like Gmail or
> Google Drive and weren't able to figure out how to press global shortcut
> keys.

That's certainly true. However, if this were implemented and became a
default, it's highly likely we'd end up with the reverse; i.e. users who
tried to use quick navigation keys and wondered why they didn't work. In
fact, this is even worse because the user might not even be aware of the
specific shortcut keys used by the web app they're using; e.g. if
they're using it for the first time.

> I think role=application was originally intended to address this
> problem, but it ended up going too far, because it leaves users with too
> few screen reader commands to work with.

Herein lies the problem. It all depends how you define "too few screen
reader commands". I assume you're referring to the arrow keys, but many
(most?) users see quick navigation as an integral part of browse mode.
At least with role="application", it's very clear and obvious: this
isn't a document and none of your document keys work. In contrast, we're
now saying "some of your browse mode keys might work and others won't.
You'll need to keep track of which web apps use which keys from this
point forward."

> (In cases
> where the app wants arrow keys, it can do so when the user is focused on
> a specific control, possibly using aria-interactive to help.)

This should only be the case if the user switches to focus mode.
Otherwise, a user will be happily arrowing through the document until,
all of a sudden, their arrow keys start doing something different.

> Jamie, what would you think if the screen reader announced the presence
> of web app key commands when a page loads, giving users the choice at
> that time?

That would at least make things clear and give the user a choice. We'd
probably want some way of saving this choice, but that brings up the
question of how screen readers should identify a given "web app" (e.g.
domain isn't necessarily a reliable identifier).

> Another idea that one of our Google colleagues, Nektarios, had, was to
> provide another passthrough option, perhaps the Right-Ctrl key, and then
> this spec could simply be a way to advertise keystrokes.

IMO, the user may as well just use the pass through key in that case.
It's only one extra key press and it already exists.

Jamie

[James Teh]

Hi Dominic,

On 12/05/2015 2:00 AM, Dominic Mazzoni wrote:
> Instead of declaring all of the keyboard shortcuts in one place, the web
> app takes buttons, links, menu items, and any other HTML elements on the
> page that have a default action when pressed, and adds attributes to
> them that specify what global keyboard shortcut also triggers this action.

I like this proposal because it keeps the metadata with the thing it
activates. However, "global" concerns me. As Nektarios pointed out:

> Personally, I think that we should distinguish between global vs. widget-specific shortcuts. On Facebook or in Gmail "j" and "k" should not be used when you are not focused on the timeline as they are specific to moving among your posts. Similarly, you don't want a global shortcut for "like".

Dominic wrote:

> This fits really easily with the idea that we could later add support
> for gestures, too.

For touch access with a screen reader, it's probably more important just
to know that something is a quick/shortcut-worthy action. The screen
raeder can then present that as a menu. However, it seems weird for
touch screen readers to use aria-key to make this determination. It's
almost like we'd want something like <button aria-quickAction="true"
aria-key="c"> (the separate attribute because something could be a quick
action but not have an assigned keyboard shortcut).

In terms of implementation, one problem with this idea is that a screen
reader would have to crawl the entire document to cache all possible
shortcut keys. Windows screen readers currently use virtual buffers (so
they already suck in the entire document), but this may not be the case
forever. The concept behind browse mode doesn't necessarily require a
virtual buffer; that's just the current way it's implemented "behind the
scenes". Doing browse mode without virtual buffers is something I've
been thinking about quite a bit lately, and while it's not likely to
happen in the short-term, I'm still keen to explore the possibilities.
It's reasonable to expect a small delay when doing quick navigation, but
not every time a user presses a key. So, if we did go with an approach
like this, browsers would need to provide a way for ATs to get at all
shortcut keys.

Jamie

[James Teh]

On 12/05/2015 2:32 AM, Nektarios Paisios wrote:
> 1. aria-interactive="all": Don't intercept any keys while this widget is
> focused. Works like Focus / Forms Mode.

I'm not sure if this is what you intended, but as specified here, this
would mean that if you're in browse mode and you move your cursor to
such an element, browse mode keystrokes would suddenly stop working.

> 2. aria-interactive="typing": Dont intercept any typing keys while the
> focus is on this widget, but cursors and other navigation keys may
> optionally be intercepted if the assistive technology so desires.

So what if, for example, the AT binds control+f to its own find command
(as JAWS does)? That isn't a typing key, but a web app may well wish to
override it.

> 3. aria-interactive="navigation" Don't intercept any navigation keys but
> you may intercept typing keys. Useful for list or treeview widgets that
> can handle the cursors properly but which don't provide first letter
> navigation, a feature that the screen reader may want to provide.

Same comment as for (1).

> I think that we should distinguish between global vs. widget-specific
> shortcuts. On Facebook or in Gmail "j" and "k" should not be used when
> you are not focused on the timeline as they are specific to moving among
> your posts. Similarly, you don't want a global shortcut for "like".

I totally agree here. However, this raises another issue. Suppose the
user is happily rapidly pressing k in NVDA to move between links.
Suddenly, they land on a link in a timeline post. Now, they press k
again. Oops, now the web app has taken over and they just got moved to
the next post. This is precisely the sort of thing focus mode was
intended to prevent. If a user presses a quick navigation key, they
shouldn't have to think about which control they're focused on to know
what's going to happen. Otherwise, things get very confusing as
illustrated in the example I just gave.

[Dominic Mazzoni]

On Wed, May 20, 2015 at 8:59 PM, James Teh <ja...@nvaccess.org> wrote:

However, if this were implemented and became a default, it's highly likely we'd end up with the reverse; i.e. users who tried to use quick navigation keys and wondered why they didn't work. In fact, this is even worse because the user might not even be aware of the specific shortcut keys used by the web app they're using; e.g. if they're using it for the first time.

You may be right and I want to draw a clear distinction between what information the application can provide and how screen readers or other AT choose to do something with it.

I think it's really interesting what's implemented in JAWS (as an optional opt-in feature) and I'm eager to hear how users react to it. But that doesn't mean at all that NVDA has to do it the same way. There are several things you could do, knowing the list of global keyboard commands in a web app, other than override browse mode keys:

* Announce the presence of such keys when the document loads (so users know they exist)

* Announce a keyboard shortcut when a user navigates to an on-screen button or menu item that has an associated shortcut

* Offer a command that pops up a keyboard shortcut list, similar to the elements list

* Provide alternate "passthrough" keys

* Override browse mode keys, but only opt-in on a per-site basis

* Or possibly many other ideas

I think the main point is that many web apps already offer global keyboard shortcuts. It's not like we're proposing sites add new interface ideas - these things already exist. By explicitly exposing them at least screen readers have some more information than they had before.

where the app wants arrow keys, it can do so when the user is focused on
a specific control, possibly using aria-interactive to help.)

This should only be the case if the user switches to focus mode. Otherwise, a user will be happily arrowing through the document until, all of a sudden, their arrow keys start doing something different.

Yes, of course. Only if a control is marked with aria-interactive=true and if auto focus mode is on, only then would it switch modes.

Jamie, what would you think if the screen reader announced the presence
of web app key commands when a page loads, giving users the choice at
that time?

That would at least make things clear and give the user a choice. We'd probably want some way of saving this choice, but that brings up the question of how screen readers should identify a given "web app" (e.g. domain isn't necessarily a reliable identifier).

Site-specific customizations in Chrome are indexed based on the "effective TLD", which is defined as "the longest portion of a URL that should be treated as though it were a top-level domain (TLD)". Browsers all have a way to compute the effective TLD for any URL and if it's helpful that's something we could expose, or you could try to integrate something from Mozilla's libraries or data from a site like https://www.publicsuffix.org/

No, this wouldn't be perfect - you could have two apps on the same domain and want different behavior for each. But at a minimum using a calculation like that would prevent you from accidentally treating qld.edu.au as a domain when it's actually a suffix.

[Dominic Mazzoni]

In terms of implementation, one problem with this idea is that a screen reader would have to crawl the entire document to cache all possible shortcut keys. Windows screen readers currently use virtual buffers (so they already suck in the entire document), but this may not be the case forever. The concept behind browse mode doesn't necessarily require a virtual buffer; that's just the current way it's implemented "behind the scenes". Doing browse mode without virtual buffers is something I've been thinking about quite a bit lately, and while it's not likely to happen in the short-term, I'm still keen to explore the possibilities. It's reasonable to expect a small delay when doing quick navigation, but not every time a user presses a key. So, if we did go with an approach like this, browsers would need to provide a way for ATs to get at all shortcut keys.

As you said, it's not an issue today because the virtual buffer already requires scanning the whole document.

Even if you got rid of the virtual buffer, wouldn't you need to scan the whole document on load to count the number of headings and find alerts and maybe live regions?

If you want to be able to quickly find something in a large document without scanning the whole thing, we should add news APIs to make this easier. Mac OS X already has this, VoiceOver calls a special function to search for objects that match certain predefined search predicates as a way to avoid scanning the whole document.

[James Teh]

On 21/05/2015 4:30 PM, Dominic Mazzoni wrote:
> You may be right and I want to draw a clear distinction between what
> information the application can provide and how screen readers or other
> AT choose to do something with it.

That's an important distinction, but it doesn't excuse us from coming up
with solid, end-to-end use cases and their associated UX. Otherwise, we
could end up with a proposal that has massive holes in it. :)

> There
> are several things you could do, knowing the list of global keyboard
> commands in a web app

Again, this "global" thing concerns me. Even the definition of global is
somewhat sketchy when taking into account iframes, etc.

> * Announce a keyboard shortcut when a user navigates to an on-screen
> button or menu item that has an associated shortcut

This is an important use case IMO for which i can't see any flaws in the
current proposal. Btw, i agree it should be exposed via
IAccessible::accKeyboardShortcut on Windows.

[James Teh]

On 21/05/2015 4:35 PM, 'Dominic Mazzoni' via Browser Accessibility

Development wrote:
> As you said, it's not an issue today because the virtual buffer already
> requires scanning the whole document.

Right, but we want this to be future-proof...

> Even if you got rid of the virtual buffer, wouldn't you need to scan the
> whole document on load to count the number of headings

We don't do element counts. We've always believed it isn't overly
useful, creates unnecessary verbosity, introduces a performance hit and
isn't accurate on the modern web due to dynamic content.

> and find alerts
> and maybe live regions?

Both of those are handled by events in Firefox and Chrome; i.e. we don't
use the buffer for that.

> If you want to be able to quickly find something in a large document
> without scanning the whole thing, we should add news APIs to make this
> easier. Mac OS X already has this, VoiceOver calls a special function to
> search for objects that match certain predefined search predicates as a
> way to avoid scanning the whole document.

This is not a good solution for this problem because you'd have to do
this on *every* key press, which means the response needs to be near
instant (which these APIs won't be in a large document). (Try navigating
by heading in a large document on Mac or iOS.) This is very different to
quick navigation, where it's reasonable to expect a slight delay. You
can't even have the AT fetch the entire list and cache it unless the AT
invalidates the cache on every possible mutation event (which first
means listening for every mutation event).

[James Teh]

On 21/05/2015 5:37 PM, James Teh wrote:
>> If you want to be able to quickly find something in a large document
>> without scanning the whole thing, we should add news APIs to make this
>> easier.

> This is not a good solution for this problem because you'd have to do
> this on *every* key press, which means the response needs to be near
> instant (which these APIs won't be in a large document)

Correction: you'd have to do this on every press of a key for which you
want this treatment; e.g. keys which are normally quick navigation keys.
The problem still applies, though.

[Nektarios Paisios]

>> Another idea that one of our Google colleagues, Nektarios, had, was to
>> provide another passthrough option, perhaps the Right-Ctrl key, and then
>> this spec could simply be a way to advertise keystrokes.
> IMO, the user may as well just use the pass through key in that case.
> It's only one extra key press and it already exists.
>
> Jamie

Not exactly. From personal experience and from what I heard from other
screen reader users, the passthrough key is not frequently used. It's
cumbersome to have to repeatedly press it before every application shortcut.
Using the right control would solve this because you can use it as a
modifier: you simply add right control to the application's shortcut.
So, "c" for Gmail's Compose or "l" for Facebook's Like would become
right-control+c and right-control+l. That's easier to press and in fact
is very common to press control + something in all apps so it could be
quickly adopted by users.
If a web app has shortcuts that already use the control key, you
wouldn't need passthrough for those, or if you do, you could use
left-control+right-control+shortcut.
Also, the right control is handy because it can act as an app menu. If
the aria-key proposal goes through, you could show a pop-up menu upon
pressing and releasing the right-control key containing all the global
commands and their shortcut keys. It would be a similar concept to the
alt and alt+letter keyboard patterns in native Windows apps.
Nektarios.

[Nektarios Paisios]

1. aria-interactive="all": Don't intercept any keys while this widget is
>> focused. Works like Focus / Forms Mode.
> I'm not sure if this is what you intended, but as specified here, this
> would mean that if you're in browse mode and you move your cursor to
> such an element, browse mode keystrokes would suddenly stop working.
>

I expect it to work like textarea fields work today. If you move your
cursor to them while in Browse Mode and you keep arrowing down, I don't
think that it automatically switches to Focus Mode. You have to
explicitly press enter or tab into it.

>> 2. aria-interactive="typing": Dont intercept any typing keys while the
>> focus is on this widget, but cursors and other navigation keys may
>> optionally be intercepted if the assistive technology so desires.
> So what if, for example, the AT binds control+f to its own find
> command (as JAWS does)? That isn't a typing key, but a web app may
> well wish to override it.
>

Okay, typing keys == typing keys plus any modifier + typing key.

>> 3. aria-interactive="navigation" Don't intercept any navigation keys but
>> you may intercept typing keys. Useful for list or treeview widgets that
>> can handle the cursors properly but which don't provide first letter
>> navigation, a feature that the screen reader may want to provide.
> Same comment as for (1).
>
>> I think that we should distinguish between global vs. widget-specific
>> shortcuts. On Facebook or in Gmail "j" and "k" should not be used when
>> you are not focused on the timeline as they are specific to moving among
>> your posts. Similarly, you don't want a global shortcut for "like".
> I totally agree here. However, this raises another issue. Suppose the
> user is happily rapidly pressing k in NVDA to move between links.
> Suddenly, they land on a link in a timeline post. Now, they press k
> again. Oops, now the web app has taken over and they just got moved to
> the next post. This is precisely the sort of thing focus mode was
> intended to prevent. If a user presses a quick navigation key, they
> shouldn't have to think about which control they're focused on to know
> what's going to happen. Otherwise, things get very confusing as
> illustrated in the example I just gave.
>

How about quick nav keys behave in the same way as now, i.e. they
wouldn't switch mode unless the user explicitly chooses to, either by
pressing enter, tab or explicitly crossing over the widget's boundary
using cursor left / right?

When I rapidly press "e" to move among all edit fields today in NVDA, I
don't get switched in and out of Focus Mode.

I know that my proposal needs to be improved, here is the general idea:
Let's take Facebook's timeline or Gmail's email list or Twitter's feed.
Such listview type widgets are becoming common.
Using cursor keys in those widgets is important because you might want
to spell something or read it more slowly.
But once you explicitly choose to interact with such a widget by either
pressing enter, tab or crossing its boundary using left /right, you
don't need to use any quick nav keys because those widgets already
provide single-letter shortcuts for navigation ("j" and "k") and for
performing actions (e.g. Archive, Mark Read).
So, a website developer could use aria-interactive="typing" and NVDA
could play a special earcon to indicate that while you are interacting
with such a widget, quick nav keys are out of reach but you can still
use the cursors to read content.
Pressing NVDA+CTRL+space, escape or simply tabbing out of the widget
would switch full Browse Mode back on.
Once you are interacting with such a widget, pressing ctrl+home / end
would take you to the top / bottom of the widget, like embedded objects
work today.
Nektarios.

[Nektarios Paisios]

On 5/21/2015 7:15 AM, James Teh wrote:
> On 21/05/2015 5:37 PM, James Teh wrote:
>>> If you want to be able to quickly find something in a large document
>>> without scanning the whole thing, we should add news APIs to make this
>>> easier.
>> This is not a good solution for this problem because you'd have to do
>> this on *every* key press, which means the response needs to be near
>> instant (which these APIs won't be in a large document)
> Correction: you'd have to do this on every press of a key for which
> you want this treatment; e.g. keys which are normally quick navigation
> keys. The problem still applies, though.
>
> Jamie

Don't you already have to scan the document or the accessibility tree
when building up the Elements List (NVDA-key+f5) for links, headings and
landmarks? Why not have something similar for widgets with aria-key, say
the right-control?
I understand that we are lacking APIs for quickly searching the
accessibility tree. But this is a separate issue that shouldn't stall
the current proposal.
How about you never override any quick nav shortcuts. You simply:
A) Announce the aria-key when the user browses to a widget with this
attribute as exposed in the accessibility tree via IA2.
B) Only scan the whole accessibility tree upon pressing and releasing
the right-control key. Present a list of all widgets and their associate
shortcuts. Alternatively, this could be another tab in the Elements List.
C) If the user presses right-control + something, e.g. right-control+c,
remove the right-control and pass the rest of the keystroke to the web
app. No searching necessary.
Nektarios.

[Dominic Mazzoni]

On Thu, May 21, 2015 at 12:37 AM, James Teh <ja...@nvaccess.org> wrote:

If you want to be able to quickly find something in a large document
without scanning the whole thing, we should add news APIs to make this
easier. Mac OS X already has this, VoiceOver calls a special function to
search for objects that match certain predefined search predicates as a
way to avoid scanning the whole document.

This is not a good solution for this problem because you'd have to do this on *every* key press, which means the response needs to be near instant (which these APIs won't be in a large document). (Try navigating by heading in a large document on Mac or iOS.) This is very different to quick navigation, where it's reasonable to expect a slight delay. You can't even have the AT fetch the entire list and cache it unless the AT invalidates the cache on every possible mutation event (which first means listening for every mutation event).

Could you fetch the set of elements that have a keyboard shortcut, once, and then listen for EVENT_OBJECT_SHOW, EVENT_OBJECT_HIDE, and EVENT_OBJECT_ACCELERATORCHANGE events to know when to update them?

Even if you can't think of anything else you want to cache now, I have a hard time believing this is the only thing you'd ever want to search for in a document. I just don't think we should limit our design choice based on that. I'd much rather add new APIs to make it easier to access what you need quickly.

[James Teh]

On 22/05/2015 12:44 AM, Nektarios Paisios wrote:
> From personal experience and from what I heard from other
> screen reader users, the passthrough key is not frequently used. It's
> cumbersome to have to repeatedly press it before every application
> shortcut.
> Using the right control would solve this because you can use it as a
> modifier: you simply add right control to the application's shortcut.

This doesn't solve one of the problems you're trying to solve here which
is that users expect to be able to use the keyboard shortcuts that are
documented by the web app without special knowledge of some pass through
technique.

When I argue that quick nav on Mac OS is the same, I'm always told that
the reason it's different is that quick nav isn't enabled by default.
But once it *is* enabled, a user has to turn it off to use these web app
keys. The same argument can therefore be made for the user switching to
focus mode to use these web app keys with NVDA.

> So, "c" for Gmail's Compose or "l" for Facebook's Like would become
> right-control+c and right-control+l. That's easier to press and in fact
> is very common to press control + something in all apps so it could be
> quickly adopted by users.

It's very common to press control+something when the app command is
documented as control+something. It's definitely not common for the
right and left control keys to behave differently (with the exception of
virtual machine hosts). I for one use the right and left control keys
interchangeably depending on what's more physically convenient at the time.

> If a web app has shortcuts that already use the control key, you
> wouldn't need passthrough for those, or if you do, you could use
> left-control+right-control+shortcut.

So now we're hitting edge cases and this becomes even less intuitive.

I realise I'm giving back a lot of negative feedback here without
proposing a useful alternative, but I truly believe the UX here actually
just replaces current problems with more problems. Furthermore, it
requires *additional* knowledge on the part of the user, and lack of
user knowledge is part of the problem in the first place. If it weren't,
a user would simply switch to focus mode when using lots of web app
shortcut keys.

[James Teh]

On 22/05/2015 1:50 AM, 'Nektarios Paisios' via Browser Accessibility

Development wrote:
> I expect it to work like textarea fields work today. If you move your
> cursor to them while in Browse Mode and you keep arrowing down, I don't
> think that it automatically switches to Focus Mode. You have to
> explicitly press enter or tab into it.

Okay. This is different to "typing" then, as you want that to work even
when in browse mode. That distinction is important.

>>> I think that we should distinguish between global vs. widget-specific
>>> shortcuts.

>> Suppose the
>> user is happily rapidly pressing k in NVDA to move between links.
>> Suddenly, they land on a link in a timeline post. Now, they press k
>> again. Oops, now the web app has taken over and they just got moved to
>> the next post.

> How about quick nav keys behave in the same way as now, i.e. they
> wouldn't switch mode unless the user explicitly chooses to, either by
> pressing enter, tab or explicitly crossing over the widget's boundary
> using cursor left / right?

That won't work because a common pattern for navigating to such widgets
is to use quick navigation; e.g. move by heading or landmark to get to,
say, the timeline. In that case, the user may expect the widget keys to
work, but they won't. Quick nav is basically thought of the same way as
cursor navigation; it does not switch modes.

There are very good reasons we went with the approach of browse and
focus mode. It does make using web app keys a bit tricky, but the
advantage is that it's consistent, predictable and only requires
understanding of *one* concept. These proposals require both user
knowledge of yet another mode/concept (we get enough complaints about
modes as it is) and specific knowledge of the web app in question (i.e.
if I want to use j and k to move between posts, I must move to the
timeline, but I must only move to it using the cursor keys; quick nav
won't work).

I really am sorry that it seems like I'm pushing back on everything that
is said. If there were a way to do this in a simple, consistent and
completely user predictable manner, I'd be very interested. My feeling
at this point is that we are nowhere near that yet. I'll certainly think
on this some more, but I haven't come up with anything foolproof yet.

[James Teh]

On 22/05/2015 1:58 AM, Nektarios Paisios wrote:
> Don't you already have to scan the document or the accessibility tree
> when building up the Elements List (NVDA-key+f5) for links, headings and
> landmarks?

Yes. However, it's reasonable to expect that this might take some time.
In contrast, it's not reasonable to expect every quick nav or web app
key to take additional time to search for keys.

> C) If the user presses right-control + something, e.g. right-control+c,
> remove the right-control and pass the rest of the keystroke to the web
> app. No searching necessary.

That would definitely solve this problem if we went with the right
control approach. However, see my previous message on the issues with this.

[James Teh]

On 22/05/2015 2:14 AM, 'Dominic Mazzoni' via Browser Accessibility

Development wrote:
> Could you fetch the set of elements that have a keyboard shortcut, once,
> and then listen for EVENT_OBJECT_SHOW, EVENT_OBJECT_HIDE,
> and EVENT_OBJECT_ACCELERATORCHANGE events to know when to update them?

Show and hide are problematic because we get flooded with them, but yes,
I guess we could listen for acceleratorChange or some other specific new
event. There's still the issue of scope, though. If we're dealing with
global shortcuts, we can define scope as the entire browse mode
document, but that fails for widget specific considerations.

> Even if you can't think of anything else you want to cache now, I have a
> hard time believing this is the only thing you'd ever want to search for
> in a document.

It isn't, but it's the only thing we need to search with instantaneous
response (because it affects many key presses, not just specific commands).

> I just don't think we should limit our design choice
> based on that.

No, we shouldn't, but the design *must* consider this and account for
it. Otherwise, we could end up with a flawed design. That's why I raised it.

[James Teh]

Just to take this from another angle altogether, I'm starting to wonder
whether it's simplest to just implement a quick toggle in NVDA that
disables single letter keys in browse mode. Based on all of the use
cases and ideas that have come forward, this seems to solve all problems:

1. It doesn't happen without the user's knowledge, so they never have to
wonder whether single letter commands may or may not work. The user is
in complete control.
2. It disables *all* single letter commands, so the user doesn't have to
wonder which single letter commands will work and which won't.
3. It's easy for the user: just one command toggles this behaviour on or
off. There's no additional key to hold down, no pass through key, etc.
4. The user can still read with the cursor keys.
5. We don't have to worry about global versus widget specific shortcuts
making things unpredictable.
6. It's simple to understand and document.
7. If web apps were concerned about lack of user knowledge, it's simple
enough that the web app keyboard shortcut help could include a short
note that users should disable quick nav in their screen reader in order
to use these commands.

This relies on the assumption that users care more about the cursor keys
in browse mode than they do about single letter navigation commands (as
do the rest of the proposals). Personally, I don't fully believe this,
but all of these proposals seem to suggest as much.

[Victor Tsaran]

Hi Jamie.

I think this is not a bad idea, however, I would slightly modify #7. Namely, I would leave it in the hands of a screen reader to tell the user that:

1. the website offers its own shortcut keys; and

2. to enable the shortcuts (and toggle the quicknav on or off), use [NVDA shortcut key goes here].

This way we do not ask web site developers to document screen reader specific keystrokes and leave the power of this feature entirely in the hands of AT.

The one thing left to do for all of us is to figure out the spec by which AT will know the shortcut keys are available.

Aren't we back to square one? :)

--
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/555E7C58.4090806%40nvaccess.org.

[Victor Tsaran]

Interestingly enough, JAWS already provides a shortcut key to toggle quicknav on and off. It's just that users did not have an incentive to do so (because they were not aware of the shortcut keys offered by certain websites).

[James Teh]

On 22/05/2015 11:33 AM, Victor Tsaran wrote:
> I think this is not a bad idea, however, I would slightly modify #7.
> Namely, I would leave it in the hands of a screen reader to tell the
> user that:
> 1. the website offers its own shortcut keys; and
> 2. to enable the shortcuts (and toggle the quicknav on or off), use
> [NVDA shortcut key goes here].

I actually don't see the need for this. As I understand it, the basis
for this proposal was to allow users to use these web app keys without
inadvertently triggering single letter navigation. That infers the user
must *already* know the keys exist. Otherwise, they'd expect first
letter navigation to work as normal (which it will). As for
discoverability, a screen reader user can discover that these exist in
the same way a sighted user does: by reading the keyboard shortcut help.

That said, I still think it might be a good idea to announce the
shortcut key associated with a control when it gets focus. For this
purpose, aria-key would still make sense.

> Interestingly enough, JAWS already provides a shortcut key to toggle quicknav on and off. It's just that users did not have an incentive to do so (because they were not aware of the shortcut keys offered by certain websites).

Same comment applies. If they weren't aware, they would never have tried
them, so there would never have been a reason for JAWS to introduce this
web app specific keystrokes feature.

[Nektarios Paisios]

> I really am sorry that it seems like I'm pushing back on everything
> that is said. If there were a way to do this in a simple, consistent
> and completely user predictable manner, I'd be very interested. My
> feeling at this point is that we are nowhere near that yet. I'll
> certainly think on this some more, but I haven't come up with anything
> foolproof yet.
>
> Jamie

No need to apologize. As I said, I understand that I need a more fleshed
out proposal. However, let's continue thinking about aria-interactive.
It would be great if we could find a simple and consistent way of
handling Web app shortcuts.
Nektarios.

[Nektarios Paisios]

> I realise I'm giving back a lot of negative feedback here without
> proposing a useful alternative, but I truly believe the UX here
> actually just replaces current problems with more problems.
> Furthermore, it requires *additional* knowledge on the part of the
> user, and lack of user knowledge is part of the problem in the first
> place. If it weren't, a user would simply switch to focus mode when
> using lots of web app shortcut keys.
>
> Jamie
>

I feel that screen reader users are used to
having special knowledge about how to use a particular feature. For
example, NVDA+CTRL+F and not NVDA+F for find. I don't think that
learning an additional convention involving the right-control key would
be as cumbersome as you describe, although it would certainly require
some user learning. However, I get that users might like to use the two
control keys interchangeably and that might create confusion.
Let's try it out. This is the Memorial Day weekend in the US and Monday
is a holiday, so no promises but I'll try and write an NVDA extension to
do what I am proposing here. If nobody likes it, then it can stay an
extension for my personal use. If it gets popular, we can talk again.
Nektarios.

[Nektarios Paisios]

Jaws has this feature (jawskey+n) and I seldom use it because it is
global to the whole page, while I usually want quick nav keys off only
for certain widgets, i.e. aria-interactive="typing". Also, it has a
similar effect to the jawskey+z virtual cursor off shortcut and I
haven't trained myself to choose between the two shortcuts.
How about you include this feature but you make it part of the
NVDA+space cycle? Browse Mode, Typing Mode, Focus Mode. Okay the
wording needs to be improved. You may also include NVDA+shift+space for
cycling backwards through the modes and remove the escape out of
embedded object behavior currently activated with nvda+ctrl+space and
make one more mode in the nvda+space cycle. I know it sounds confusing,
but unless we try it we won't know. I don't think it's as bad as it sounds.
Nektarios.

[Victor Tsaran]

Hi Jamie.

I agree with Nektarios here.

You cannot always count on users expecting or  knowing anything and everything about the interface. This is why they have screen readers to partially alert / educate them about the UI they are interacting with.

I understand that you are concerned about the user experience, but at the same time, we need to find a way to move the web as well as its users forward. Call it an experimental feature, provide additional hand-holding assistance, etc... We just need to find a way. Let's say we try this out and fail. so what? 

You seem to agree with the fact that some solution need to be found. So, let's try out what's currently on the table and see if it sticks with users. Unless, of course, there are better ideas...

 

--
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/555F3A50.9040507%40google.com.

[James Teh]

On 23/05/2015 12:16 AM, Nektarios Paisios wrote:
> I feel that screen reader users are used to
> having special knowledge about how to use a particular feature.

They are, but only a limited number of simple concepts, particularly for
less advanced users. However, the whole point of this request was to
stop confusion about users not being able to use these single letter
keys and perhaps to make them easier to use. If they have to learn about
the right control key, they may as well learn about turning off single
letter navigation. I must point out that Mac users seem to be quite
happy toggling quick nav on and off.

> Let's try it out. This is the Memorial Day weekend in the US and Monday
> is a holiday, so no promises but I'll try and write an NVDA extension to
> do what I am proposing here. If nobody likes it, then it can stay an
> extension for my personal use. If it gets popular, we can talk again.

Sure. Happy to experiment with add-ons, but I'm not willing to consider
this for core yet.

[James Teh]

On 23/05/2015 12:28 AM, Nektarios Paisios wrote:
> Jaws has this feature (jawskey+n) and I seldom use it because it is
> global to the whole page, while I usually want quick nav keys off only
> for certain widgets, i.e. aria-interactive="typing".

The problem is that this breaks consistency/predictabillity as I already
explained. We can debate whether to do it when you move the cursor or
whatever, but if it isn't clear even to us, there's no way at all we
will be able to explain this to users.

> Also, it has a
> similar effect to the jawskey+z virtual cursor off shortcut and I
> haven't trained myself to choose between the two shortcuts.

So you're arguing that this "maybe single letter keys will work but
maybe they won't" concept is intuitive, yet you then point out that you
haven't yourself trained to distinguish between two commands with a very
clearly defined difference. I'm not criticising here--it does take
training--but this precisely proves my point. The former is most
definitely harder to understand than the latter.

> How about you include this feature but you make it part of the
> NVDA+space cycle?

Two reasons:
1. Users have already trained to quickly switch between browse and focus
modes. Changing this will break behaviours users have trained for years.
2. If you turn on or off single letter nav, it's likely you want it to
stay that way in browse mode. Adding it to the browse/focus mode cycle
makes this tricky.

> remove the escape out of
> embedded object behavior currently activated with nvda+ctrl+space and
> make one more mode in the nvda+space cycle.

Then the user would have to hit enter to get back into the embedded
object when all they wanted to do was fill a form in the object.

> but unless we try it we won't know.

There are some things that, based on knowledge of the sorts of issues
our users have, I know are not going to fly. Also, I'm not willing to
test a UX in core when I'm not even comfortable with the concepts myself.

So, at this stage, we're going to simply implement a toggle for single
letter navigation (without fully disabling browse mode). This solves
pretty much all of the original use cases without introducing
inconsistency or unpredictability, albeit with a potential extra
keystroke for the user.

[Michael Curran]

Hi all,

As Jamie explained, we have decided to at least implement a toggle for
single letter navigation, allowing the user to stay in browse mode (for
reading with the arrows and such) but be able to turn on and off single
letter navigation (h for heading etc) at their will.

Please test the following NVDA try build where I have implemented this
feature:
http://community.nvda-project.org/try/toggleSingleLetternav/nvda_snapshot_try-toggleSingleLetternav-11103,f402958.exe

To toggle single letter navigation on and off when in browse mode, press
NVDA+shift+space.

Regards
Mick

--
Michael Curran

Executive Director, NV Access Limited

Ph + 61 7 5667 8372
www.nvaccess.org
Facebook: http://www.facebook.com/NVAccess
Twitter: @nvaccess

[Nektarios Paisios]

Thanks for the quick implementation! Let's give it some time and we can
revisit the topic if we come up with better ideas.
Since this implementation is user activated, can the aria-key proposal
move forward?
Nektarios.

[James Teh]

On 27/05/2015 1:34 AM, Nektarios Paisios wrote:
> Since this implementation is user activated, can the aria-key proposal
> move forward?

I guess that depends on your intent for it. At this stage, I don't see
this being used to automatically activate anything in NVDA. However, I
certainly think it is probably worthwhile to expose the shortcut keys to
users. This could even be useful for keyboard-only, non-screen reader
users (though displaying these visually would probably require a browser
extension).

That said, I don't think this is going to fly for keys which don't have
on-screen controls. Having off-screen buttons for Next tweet, Previous
tweet, etc. just so we can expose the key seems like a really ugly hack
to me, especially because they only make sense when focus is within the
list. In general, I think off-screen text is almost always a bad thing,
with a few very rare exceptions.

Jamie

--
James Teh

Executive Director, NV Access Limited

Ph +61 7 3149 3306
www.nvaccess.org
Facebook: http://www.facebook.com/NVAccess
Twitter: @NVAccess
SIP: ja...@nvaccess.org

[Dominic Mazzoni]

I'm happy with taking a conservative approach. I do think it'd be good to announce shortcut keys to users when they encounter a control, and now NVDA users have an option to get the same behavior as JAWS users, the only difference is that NVDA users explicitly toggle that mode. I think it will be really interesting to see what fraction of users end up liking this mode (whether in NVDA or in JAWS) and what fraction end up not using it, but maybe become more aware of accessing these shortcuts via the passthrough key thanks to Facebook's popularity.