NVDA does not read menus when arrowing through an application role

[nvaccessAuto]

Reported by dfarough on 2013-04-30 20:12 On the WET Web Experience Toolkit examples: http://wet-boew.github.io/wet-boew/demos/index-eng.html when you access the application landmark using the arrows NVDA does not read the top level menu items within the application landmark. If you tab to the items the menus will open and behave normally, but if you use the cursor keys to browse the page Nvda moves immediately out of the application section. I do not know when this began. I know this occurs with 2013.1 RC1 and with 2012.3.1. I have tested this with 2012.1 and all of the content within the application section is spoken properly with 2012.1.

[nvaccessAuto]

Comment 1 by jteh on 2013-04-30 22:42 Applications are not meant to be part of documents, so they can't be accessed with browse mode. Thus, when an application is embedded within a document, NVDA will report "application" and you must then press enter to interact with it. Rendering applications into browse mode was a bug; see #990.

If you want the widget to be treated as part of the document, don't mark it with a role of application. Changes: Added labels: invalid State: closed

[nvaccessAuto]

Comment 2 by dfarough on 2013-05-01 18:27 I have to disagree with the approach you are taking with browse mode. I thought it was up to the screen reader to expose the content within the pages. In this case you are hiding the content within the application region. How is a user supposed to decide whether to activate application mode if you don't provide the content within the application so that a decision can be made. Why do you feel the need to protect me from this content. Do you think that I am incapable of deciding for myself?

Do you think that it helps people when one screen reader provides this information when yours does not? These subtle differences in behaviour only serve to confuse users and make the web a more difficult environment to deal with.

We have been going to a lot of effort to develop and test this content so that people will know how to use it, and now you prevent people from seeing the messaging we provide. I will provide below some comments from one of our developers.

+pjackson28 commented May 01, 2013 Reading the issue 990 for NVDA, the way they solved the problems is backwards and not good for the user. How could the user possibly know if they want to interact with the application unless you read some of it? What would have been a much smarter approach would be to activate the application mode like normal and have an easy way to exit it if needed (without trampling on the keys normally used by applications). If they are really concerned about users getting trapped, maybe they should read off the first bit of content then prompt the user as to whether or not they want to stay in application mode.

Either way, their current approach is not good for users as it punishes sites that use role="application" correctly just because there are sites that do it poorly. Telling sites that they shouldn't use role="application" to provide advanced navigation options to users, contrary to what WAI-ARIA says, is really not helpful to anyone.

NVDA needs to find much better ways of dealing with problematic application regions than forced segregation. We should be working towards integrating screen readers into the enhanced experience, letting them take advantage of the improved accessibility and usability where it is available, rather that segregating the experiences and forcing them to opt-in. That segregation is just as annoying and harmful for users as forcing visual users to click a "show content" button on every page to see certain regions of the page.

Changes: Removed labels: invalid State: reopened

[nvaccessAuto]

Comment 3 by jteh on 2013-05-02 01:28 Browse mode is for browsing documents. An application is not a document. There isn't even a such thing as application mode; browse mode simply isn't relevant for applications. If it were, it would override keystrokes you might want to use.

What you are proposing clearly demonstrates a complete lack of understanding of why rendering application content in browse mode was considered a bug in the first place. If we do as you suggest, the user will press down arrow and suddenly land in the application, after which the arrow keys and other browse mode commands won't have any effect anyway. (If they did, you wouldn't be able to use them in an application. The entire reason you're using the application role is that you apparently want to have the option of using any keystroke you choose without the screen reader interfering. That includes the arrow keys.) It is completely counter-intuitive for the user to suddenly fall into an application. They won't be able to understand why their browse mode commands suddenly just stop working.

To put it another way, we don't render the content because even if we did, once you fall inside it, you can't explore it with browse mode anyway. Changes: Added labels: invalid State: closed

[nvaccessAuto]

Comment 4 by dfarough on 2013-05-02 15:34 If you go to the following sites you will get a sense of what the Web Experience toolkit is. http://wet-boew.github.io/wet-boew/index-eng.html The working examples can be found here: http://wet-boew.github.io/wet-boew/demos/index-eng.html Most Canadian government departments are using this toolkit when designing their web sites. As a result these menus which appear within the application role will be experienced by many Canadians. It seems to me that only the screen reader developers determine how browse mode works. Prior to 2012.3.1 Nvda when in browse mode did not ignore content within the application role. You could use the down arrow key to move sequentially through any top level menus. For each item you were prompted to press enter to open the menu. if enter is pressed, the menu opens. At that point useing up or down arrow will move through the menu items for that top level menu. pressing right arrow, left arrow, Tab or shift+tab will move horizontally across the menus. Pressing escape will cause the menu to close and focus will move to the next item following the application role. NVDA and other screen readers advise the user when various landmarks are encountered, so People should not get that confused. I know that Jaws and NVDA prior to NVDA 2012.3.1 handled this situation identically. I feel that as a result of this bug as you call it, there is much more potential for frustration and confusion. The user has to activate the application mode in order to know what it does. Before this bug the user would know that the application contained some menus. It was also possible to see what each menu was before opening it. I feel that this behaviour is adding unnecessary bariers to the user experience and is making our content more difficult to use.

[nvaccessAuto]

Comment 5 by jteh on 2013-05-02 22:56 Of course screen reader vendors determine how browse mode works. It's a screen reader specific concept. That's like saying that it seems like only Microsoft determined that alt+f4 closed an application window. It's also worth noting that NVDA's User Guide describes this behaviour about applications, so users should be familiar with it.

You're only considering your own specific case. Imagine there's an application wherein the first control is a button, but you can only tab away from that button, not arrow past it. The user would arrow down in browse mode, hit the button and then the arrow keys would stop working because they're now inside the application. If you're moving through the document with reasonable speed (as efficient users will do), this is even more jarring.

I'd seriously question why you are using a role of application at all. It sounds like you primarily want this to be treated like a document, but with menu widgets. Using the application role here is incorrect. The application role is designed for content which should be treated like an application, not for individual widgets in documents. Yahoo! Mail is one example of correct usage of the application role.

[nvaccessAuto]

Comment 6 by camlorn on 2013-05-03 03:20 I'm going to link #2023, here, and say that I have to disagree with NVDA's philosophy. It is not up to NVDA to force web sites to conform to the best practices as defined by NVDA or even to the Wai-Aria spec, and this seems like another place where being able to force browse mode would be a solution, at least for some users. I do agree with how NVDA now handles applications, that is not entering the "Application mode" automatically (yes, yes, terminology, and I know it's not really a mode but it might as well be for all intents and purposes, at least for me). Being able to re-enter browse mode is a valid approach to obtaining information about the material, at least in my opinion, even if said material doesn't "work" when you do. This particular website seems fine, though, if a bit confusing. I believe the confusion is related to the fact that the application is giving counterintuitive instructions, that the menus need to be moved between with the left and right arrows, and that the down arrow as well as the enter key is opening menus of some sort or another. The point of Application in the Wai-Aria spec is that it be treated like an application, that is, in the same manner NVDA would treat notepad or whatever else that isn't web. If the application is confusing, that is the fault of the application developer, not the fault of NVDA, and (in the case of the web) if the application doesn't work with NVDA, that's someone not reading the Wai-Aris spec, or reading it and not bothering to test properly and make sure it functions with screen readers, the only reason they should be looking at Wai-Aria in the first place. The fact that all screen readers handle it differently isn't something that can be helped, and I really don't think NVDA should try to go conform to Jaws, for example.

[nvaccessAuto]

Comment 7 by jteh (in reply to comment 6) on 2013-05-03 03:39 Replying to camlorn:

I'm going to link #2023, here, and say that I have to disagree with NVDA's philosophy. It is not up to NVDA to force web sites to conform to the best practices as defined by NVDA or even to the Wai-Aria spec, and this seems like another place where being able to force browse mode would be a solution, at least for some users.

The issue here is that the reporter doesn't want to have to press enter to interact with the application, so #2023 is a very different issue.

[nvaccessAuto]

Comment 8 by briang1 on 2013-05-03 12:33 Seems to me, that no matter what the actual rights and wrongs are here, it seems the Canadian sites will do what they want, and maybe the extra forcing of browse mode function will get folk out of trouble. Its going to be hard to explain it though I fancy, in a way newbies can get what it means! Most Canadian government departments are using this toolkit when designing their web sites. As a result these menus which appear within the application role will be experienced by many Canadians.

Is the key here I think. They should not do it, but as we all know web sites are built these days often very oddly!

[nvaccessAuto]

Comment 9 by pjackson28 on 2013-05-03 16:04 The toolkit in question is putting a lot of effort into conforming to WCAG 2.0 and WAI-ARIA and has been through a lot of screen reader testing thanks to screen reader users such as dfarough. Some individuals in this thread are suggesting that the toolkit and Canadian sites are not respecting WAI-ARIA.

Conforming to the WAI-ARIA best practices is a goal of this toolkit but we are unable find where in WAI-ARIA that the toolkit does not conform. Please quote the specific references from WAI-ARIA that are not being met by the toolkit so they can be addressed.

[nvaccessAuto]

Comment 10 by camlorn on 2013-05-03 18:20 I didn't realize that the only issue was that the reporter didn't want to press enter. Sorry. I'm not implying that it is not obeying Wai-Aria, I am only saying that it is not NVDA's job to force websites to do so. My entire comment is basically invalid, as I misunderstood the issue being discussed. I have not extensively tested those websites and was speaking only of the general case.

[nvaccessAuto]

Comment 11 by pjackson28 (in reply to comment 5) on 2013-05-04 02:40 Replying to jteh:

Of course screen reader vendors determine how browse mode works. It's a screen reader specific concept. That's like saying that it seems like only Microsoft determined that alt+f4 closed an application window. It's also worth noting that NVDA's User Guide describes this behaviour about applications, so users should be familiar with it.

You're only considering your own specific case. Imagine there's an application wherein the first control is a button, but you can only tab away from that button, not arrow past it. The user would arrow down in browse mode, hit the button and then the arrow keys would stop working because they're now inside the application. If you're moving through the document with reasonable speed (as efficient users will do), this is even more jarring.

I'd seriously question why you are using a role of application at all. It sounds like you primarily want this to be treated like a document, but with menu widgets. Using the application role here is incorrect. The application role is designed for content which should be treated like an application, not for individual widgets in documents. Yahoo! Mail is one example of correct usage of the application role.

Could you please quote the specific reference in WAI-ARIA that indicates that the use of the application role is incorrect or non-conforming in the example that dfarough cited? The application role is being used to enable for screen reader users the keyboard interaction prescribed by the "menu or menu bar widget" design pattern in the WAI-ARIA 1.0 Authoring Practices (http://www.w3.org/TR/wai-aria-practices/#menu).

[nvaccessAuto]

Comment 12 by pjackson28 (in reply to comment 3) on 2013-05-04 02:48 Replying to jteh:

Browse mode is for browsing documents. An application is not a document. There isn't even a such thing as application mode; browse mode simply isn't relevant for applications. If it were, it would override keystrokes you might want to use.

Here is the WAI-ARIA reference to the application browsing mode and mode switching:

"When the user navigates an element assigned the role of application, assistive technologies that typically intercept standard keyboard events SHOULD switch to an application browsing mode, and pass keyboard events through to the web application. The intent is to hint to certain assistive technologies to switch from normal browsing mode into a mode more appropriate for interacting with a web application; some user agents have a browse navigation mode where keys, such as up and down arrows, are used to browse the document, and this native behavior prevents the use of these keys by a web application." (http://www.w3.org/TR/wai-aria/roles#application)

I'd seriously question why you are using a role of application at all. It sounds like you primarily want this to be treated like a document, but with menu widgets. Using the application role here is incorrect. The application role is designed for content which should be treated like an application, not for individual widgets in documents. Yahoo! Mail is one example of correct usage of the application role.

The example that dfarough cited includes both application and document regions much like the example from WAI-ARIA for an email application:

"For example, an email application has a document and an application in it. The author would want to use typical application navigation mode to cycle through the list of emails, and much of this navigation would be defined by the application author. However, when reading an email message the content will appear in a region with a document role in order to use browsing navigation." (http://www.w3.org/TR/wai-aria/roles#application)

[nvaccessAuto]

Comment 13 by dfarough on 2013-05-04 15:37 In the ARIA reference you quote, I believe that the word navigate is referring to the system focus moving to an element of an application that should trigger the application or focus mode. This makes sense to me. I do not believe that browse mode is meant to trigger this change of mode. And before 2012.3 NVDA would speak any content within the application role, allowing the user to decide whether to change modes when appropriate. Now NVDA is the only Screen reader to my knowledge that does not allow their users to hear this content in browse mode. Moreover I believe that you are turning the application role into something of a black hole where NVDA is concerned. Recently we modified the role to include a ARIA label so that the users would know that the application contained site menus. NVDA does not even provide this information. JAWS does speak this so there is nothing wrong with the coding. Why are your users not entitled to this information?

[nvaccessAuto]

Comment 14 by briang1 on 2013-05-05 01:41 Lets not get too worked up about this, but I believe what we need to know is two things. Is this really an app? and what do the sighted get on these slightly contentiously coded websites. If they see the menus, then whatever the rights and wrongs, a means has to be found for us to also, end of story.

[nvaccessAuto]

Comment 15 by jteh (in reply to comment 13) on 2013-05-05 10:05 Replying to pjackson28:

Could you please quote the specific reference in WAI-ARIA that indicates that the use of the application role is incorrect or non-conforming in the example that dfarough cited?

If you want to play the "quote the spec" card rather than discussing practicality, I'd counter-challenge you to quote a section of WAI-ARIA that says applications should be rendered in browse mode.

The application role is being used to enable for screen reader users the keyboard interaction prescribed by the "menu or menu bar widget" design pattern

You don't need the application role for this. NVDA will function correctly as long as you use the correct menu roles, as should other ATs.

Replying to pjackson28:

Here is the WAI-ARIA reference to the application browsing mode and mode switching:

"When the user navigates an element assigned the role of application, assistive technologies that typically intercept standard keyboard events SHOULD switch to an application browsing mode, and pass keyboard events through to the web application.

Right, which is what we do. You haven't navigated inside the application until you press enter on it. As noted earlier, if we just switched, the experience would be very jarring for a user who would wonder why they were suddenly thrown out of browse mode. If you read #990, you'll see that this was precisely why this change was made.

The example that dfarough cited includes both application and document regions much like the example from WAI-ARIA for an email application:

It is quite different in intent, though. In an email application, the application portion is the main backbone (for want of a better word) of the navigation experience until the user chooses to read a message. In this case, you're simply adding menu widgets to a document; the user navigates to these widgets by way of the document.

Replying to dfarough:

In the ARIA reference you quote, I believe that the word navigate is referring to the system focus moving to an element of an application that should trigger the application or focus mode.

NVDA does move the focus when you move in browse mode.

And before 2012.3 NVDA would speak any content within the application role

Incorrect. As soon as something inside the application got focus (which would happen if the browse mode cursor landed on something focusable), you would be thrown out of browse mode, which is why #990 was filed.

Recently we modified the role to include a ARIA label so that the users would know that the application contained site menus. NVDA does not even provide this information. JAWS does speak this so there is nothing wrong with the coding. Why are your users not entitled to this information?

Rather than confrontationally asking why our users aren't entitled to this, perhaps you should request that this be implemented, since that wasn't your original request.

[nvaccessAuto]

Comment 16 by pjackson28 (in reply to comment 14) on 2013-05-05 17:06 Replying to briang1:

Lets not get too worked up about this, but I believe what we need to know is two things. Is this really an app? and what do the sighted get on these slightly contentiously coded websites. If they see the menus, then whatever the rights and wrongs, a means has to be found for us to also, end of story.

In the context of WAI-ARIA, the application role is used to signal to the screen reader that the normal browsing mode may not be the most effective way of navigation the region in question and that the author is offering what should be more appropriate keyboard interaction. So I don't think this should be a debate over what is and isn't a Web application and instead should focus on whether or not the "application" offers task-focused keyboard interaction and whether or not the application role is needed to make that keyboard interaction available to screen reader users.

In the example that dfarough cited, visual keyboard users are provided with enhanced keyboard navigation as described in the WAI-ARIA "menu or menu bar widget" design pattern (such as navigating menus with arrow keys, navigating by the first letter of the menu items, quickly exiting a menu using escape, etc.). This enhanced keyboard navigation is being provided because mega menu navigation systems can often include 100+ navigation links which may be too cumbersome to navigate by tabbing alone. The application role is being used to offer the same enhanced navigation options to screen reader users. The application role wouldn't be needed in this case if all screen readers passed along the keyboard events to the "application" for the menubar and menu roles by default (like is done with the tablist and tab roles) rather than intercepting them, but that is not the case which is why we use the application role.

Note that the example dfarough cited is just one scenario where the application role would be used. It could also be used for other interface components where normal browsing mode may not be the most effective, such as sliders and interactive image galleries, and keyboard events are not being passed to the widgets by default. Yes those interface components should still be operable in normal browsing mode but it would be much more efficient to support moving the slider with the arrow keys when the slider is in focus rather than just tabbing back and forth between the buttons and activating them to move the slider right and left. In such a case the "application" arrow key support offers enhanced usability by reducing the number of key presses needed to accomplish the task.

What dfarough is asking for is that users be permitted to navigate the application region without having to activate it and be provided with the option to pass keyboard events to the "application" so they can opt-in to the enhanced task-focused navigation offered by the "application". Ideally there would also be a configurable option that allows the user to auto-switch or manually switch to this alternate mode much like is done for forms/focus mode so the choice is ultimately up to the end user.

Other useful features could be: 1) Announcing the key needed to exit application mode when first entering application mode (so the user knows right up front how to get out of application mode). 2) Suppressing auto-switching to application mode if the user has exited application mode while in the application region. This suppression should only continue until the user has left the application region so they don't constantly switch back on every keypress in the region but auto-switching will resume once they return.

[nvaccessAuto]

Comment 17 by pjackson28 (in reply to comment 15) on 2013-05-05 18:44 Replying to jteh:

Replying to pjackson28:

Could you please quote the specific reference in WAI-ARIA that indicates that the use of the application role is incorrect or non-conforming in the example that dfarough cited?

If you want to play the "quote the spec" card rather than discussing practicality, I'd counter-challenge you to quote a section of WAI-ARIA that says applications should be rendered in browse mode.

I am respectfully asking you to quote the spec to provide evidence to support the following statements you made: 1) "seriously question why you are using a role of application at all" 2) "Using the application role here is incorrect" 3) "The application role is designed for content which should be treated like an application, not for individual widgets in documents."

I am unable to find the references within WAI-ARIA to support your statements so I am asking you to please provide those references. The reason why I am asking is because of the following from WAI-ARIA:

1) "Authors SHOULD set the role of application on the element that encompasses the entire application. If the application role applies to the entire web page, authors SHOULD set the role of application on the root node for content, such as the body element in HTML or svg element in SVG." (http://www.w3.org/TR/wai-aria/roles#application)

The above reference indicates that the application role is to be applied to a node that encompasses the entire application and that the node is not necessarily the root node. So the application can just be a part of the page like in the case of a widget and not necessarily the whole page.

2) The application role is a landmark role which is defined as "regions of the page intended as navigational landmarks" (section 5.3.4) where landmarks are defined as: "A type of region on a page to which the user may want quick access. Content in such a region is different from that of other regions on the page and relevant to a specific user purpose, such as navigating, searching, perusing the primary content, etc." (http://www.w3.org/TR/wai-aria/terms#def_landmark).

So in this case the application role defines a region of the page that is to be treated as a Web application so there is no requirement that the entire page be a Web application.

As for rendering the application region in browse mode, WAI-ARIA doesn't specifically state that as WAI-ARIA says the screen reader should switch to application mode when navigating an application region. This is where it becomes a practicality and usability discussion as dfarough is indicating that it makes it easier for him to decide whether or not he wants to switch to application mode if he is able to navigate the region first in browse mode. His concern is that with the way application regions are being handled now requires the user to either ignore the region altogether or fully jump into the region in application mode without any idea in advance of what is in there. That is why he was suggesting that the auto-switching be a configurable option (like with focus/form mode) and that the user can have the option of navigating the application region in browse mode first before deciding whether or not to switch over to application mode. He's just asking that the choice be left to the end user on how to proceed and to not limit the available options.

The application role is being used to enable for screen reader users the keyboard interaction prescribed by the "menu or menu bar widget" design pattern

You don't need the application role for this. NVDA will function correctly as long as you use the correct menu roles, as should other ATs.

The application role is being used to offer the same enhanced navigation options to screen reader users as is being provided to visual keyboard users (such as the keyboard interaction defined by the WAI-ARIA "menu or menubar widget" design pattern). The application role wouldn't be needed in this case if all screen readers passed along the keyboard events to the "application" for the menubar and menu roles by default (like is done with the tablist and tab roles) rather than intercepting them, but that is not the case which is why we use the application role.

Replying to pjackson28:

Here is the WAI-ARIA reference to the application browsing mode and mode switching:

"When the user navigates an element assigned the role of application, assistive technologies that typically intercept standard keyboard events SHOULD switch to an application browsing mode, and pass keyboard events through to the web application.

Right, which is what we do. You haven't navigated inside the application until you press enter on it. As noted earlier, if we just switched, the experience would be very jarring for a user who would wonder why they were suddenly thrown out of browse mode. If you read #990, you'll see that this was precisely why this change was made.

The example that dfarough cited includes both application and document regions much like the example from WAI-ARIA for an email application:

It is quite different in intent, though. In an email application, the application portion is the main backbone (for want of a better word) of the navigation experience until the user chooses to read a message. In this case, you're simply adding menu widgets to a document; the user navigates to these widgets by way of the document.

There is no requirement in WAI-ARIA for the application portion to be the "main backbone" of the Web page as covered earlier in this response. The example provided by WAI-ARIA is to illustrate that application and document regions can co-exist in the same Web page and not that the only way that can happen is for the application region to be the "main backbone". From what I've read in WAI-ARIA, the point of the application role is: 1) To serve as a navigation landmark (except when it is applied to the root node) 2) To signal to the screen reader that the normal browsing mode may not be the most effective way of navigating the region in question and that the author is offering what should be more appropriate keyboard interaction.

In the case of number 2, why would this signal only be applicable if the role is defined on the root node of the page or is the "main backbone"? Why wouldn't it be applicable to widgets where the normal browsing mode may not be appropriate and the author is offering task-focused keyboard interaction?

Replying to dfarough:

In the ARIA reference you quote, I believe that the word navigate is referring to the system focus moving to an element of an application that should trigger the application or focus mode.

NVDA does move the focus when you move in browse mode.

He's not disputing that NVDA moves the focus when you move in browse mode, he's just trying to clarify what WAI-ARIA was referring to as a potential trigger point for application mode since "navigates an element" may be a bit ambiguous.

And before 2012.3 NVDA would speak any content within the application role

Incorrect. As soon as something inside the application got focus (which would happen if the browse mode cursor landed on something focusable), you would be thrown out of browse mode, which is why #990 was filed.

What dfarough was referring to was that previously he would be presented with the content within the application region rather than what is now effectively a black box. The problem cited in #990 was that the user became confused by the automatic switch to application mode and had difficulty with exiting it. What dfarough is suggesting is perhaps a more user-friendly approach to address this issue.

Here are some recommendations: 1) Auto-switching to application mode should be a user-configurable option much like with form/focus mode. You could even make auto-switching disabled by default but what was being suggested earlier was to leave it up to the user to decide what works best. 2) In the case of auto-switching being disabled, dfarough was suggesting that the user be allowed to navigate the application region in browse mode to help determine whether or not they want to navigate the region in application mode. It is much easier to make the decision when trying it out first in browse mode than when being faced by what is effectively a black box (or just a simple title if aria-label or aria-labelledby are supported). 3) Announce the key needed to exit application mode when first announcing that the screen reader is entering application mode. In #990 the user didn't know how to get out of application mode so declaring that up front will make it easier for the user to exit (since most users of any given technology won't know all the keyboard commands available to them). The exit key can be critical in the application region context, especially if they encounter problems in that mode, so it is important that the user knows what the exit key is. 4) In the case of auto-switching being enabled, the screen reader should suppress auto-switching to application mode if the user has exited application mode while in the application region. This suppression should only continue until the user has left the application region so they don't constantly switch back on every focus change within the application region but will allow auto-switching to resume once the user returns to the region. This will also help to address the issue in #990 of switching back into application mode as each element in the application region gains focus. 5) Add support for aria-label and aria-labelledby on the node that has the application role so the user has access to a simple description of the region.

Recently we modified the role to include a ARIA label so that the users would know that the application contained site menus. NVDA does not even provide this information. JAWS does speak this so there is nothing wrong with the coding. Why are your users not entitled to this information?

Rather than confrontationally asking why our users aren't entitled to this, perhaps you should request that this be implemented, since that wasn't your original request.

To be fair to all involved, there have been statements and responses from both sides that could be perceived as being confrontational so I agree with briang1 that we shouldn't be getting too worked up about this. It is clear that all involved are passionate about providing the best possible experience to the end user so it is important that we do not take this personally, that we keep this as factual and positive as possible and that we don't let the tone or past statements distract us from the goal of helping the end user.

[nvaccessAuto]

Comment 18 by jteh (in reply to comment 17) on 2013-05-05 23:23 Replying to pjackson28:

1) "Authors SHOULD set the role of application on the element that encompasses the entire application. If the application role applies to the entire web page, authors SHOULD set the role of application on the root node for content, such as the body element in HTML or svg element in SVG."

Note that it says entire application, not widget.

The above reference indicates that the application role is to be applied to a node that encompasses the entire application and that the node is not necessarily the root node.

I didn't suggest it had to be the root node.

So the application can just be a part of the page like in the case of a widget and not necessarily the whole page.

Of course it can. However, an application isn't a document, so we don't render it in browse mode. Browse mode is for documents.

His concern is that with the way application regions are being handled now requires the user to either ignore the region altogether or fully jump into the region in application mode without any idea in advance of what is in there.

"Fully jump into" is hardly difficult. You press enter on it. If you wanted it to be browseable like a document, it shouldn't be an application.

You don't need the application role for this. NVDA will function correctly as long as you use the correct menu roles, as should other ATs.

The application role is being used to offer the same enhanced navigation options to screen reader users as is being provided to visual keyboard users (such as the keyboard interaction defined by the WAI-ARIA "menu or menubar widget" design pattern). The application role wouldn't be needed in this case if all screen readers passed along the keyboard events to the "application" for the menubar and menu roles by default

NVDA already does this. If other ATs don't, that is there bug. Essentially, you're using the application role because of bugs in other ATs, yet the issue is apparently ours when this becomes a problem.

There is no requirement in WAI-ARIA for the application portion to be the "main backbone" of the Web page as covered earlier in this response.

I'll grant I didn't explain this well. The point isn't that it has to be the root. It's a question of navigation. If you navigate to the individual widgets by way of a document, then it's a document with widgets and the application role doesn't apply. If you navigate to widgets by way of keyboard navigation in an application (e.g. Yahoo! Mail), then it's definitely an application.

2) To signal to the screen reader that the normal browsing mode may not be the most effective way of navigating the region in question and that the author is offering what should be more appropriate keyboard interaction.

In the case of number 2, why would this signal only be applicable if the role is defined on the root node of the page or is the "main backbone"? Why wouldn't it be applicable to widgets where the normal browsing mode may not be appropriate and the author is offering task-focused keyboard interaction?

By that logic, every single interactive widget (editable text fields, lists, tab lists, etc., ARIA or otherwise) should be marked as an application, but surely you agree this is incorrect. The spec states:

A region declared as a web application, as opposed to a web document.

Browse mode is only relevant for web documents.

[nvaccessAuto]

Comment 19 by pjackson28 (in reply to comment 18) on 2013-05-06 05:04 Replying to jteh:

Replying to pjackson28:

1) "Authors SHOULD set the role of application on the element that encompasses the entire application. If the application role applies to the entire web page, authors SHOULD set the role of application on the root node for content, such as the body element in HTML or svg element in SVG."

Note that it says entire application, not widget.

According to the W3C a widget is a "full-fledged client-side application". So yes, where appropriate authors should set the role of application on the element that encompasses the entire widget. Here is the relevant W3C definition:

"Widgets are full-fledged client-side applications that are authored using Web standards such as [and packaged for distribution. They are typically downloaded and installed on a client machine or device where they run as stand-alone applications, but they can also be embedded into Web pages and run in a Web browser. Examples range from simple clocks, stock tickers, news casters, games and weather forecasters, to complex applications that pull data from multiple sources to be "mashed-up" and presented to a user in some interesting and useful way (see Widgets-Landscape for more information)." - Packaged Web Apps (Widgets) - Packaging and XML Configuration (Second Edition) - W3C Recommendation 27 November 2012 (http://www.w3.org/TR/widgets/#introduction)

So the application can just be a part of the page like in the case of a widget and not necessarily the whole page.

Of course it can. However, an application isn't a document, so we don't render it in browse mode. Browse mode is for documents.

According to the WAI-ARIA 1.0 Authoring Practices, a tab panel (tablist and tabpanel roles) is a widget which means according to the W3C it is also an application. Same for the menu and menubar widgets. For both these widget/application types NVDA automatically switches to focus mode so why does NVDA treat widgets/applications with the application role differently? NVDA should be consistent with how widgets/applications are treated rather than isolating one type of widget/application and treating it differently.

His concern is that with the way application regions are being handled now requires the user to either ignore the region altogether or fully jump into the region in application mode without any idea in advance of what is in there.

"Fully jump into" is hardly difficult. You press enter on it. If you wanted it to be browseable like a document, it shouldn't be an application.

Yes, the user has to press enter to "fully jump" into what is effectively a black box. We are not suggesting that it is hard to press enter, what we are saying is that we feel such an approach decreases usability by interfering with task completion and making one application type more cumbersome to interact with than the others. NVDA allows a smooth transition to focus mode for tab panel and menubar widgets/applications so why add obstacles to this transition for widgets/applications with the application role? It is especially problematic in NVDA when a widget/application type that normally has a smooth transition instead forces the user to hit enter to switch to focus mode because that is how NVDA decided to handle the application role.

What we are asking is for NVDA to please be consistent with how widgets/applications are treated and to not force the user to hit enter to switch to focus mode for widgets/applications with the application role when you allow a smooth transition to focus mode for the other widgets/applications.

You don't need the application role for this. NVDA will function correctly as long as you use the correct menu roles, as should other ATs.

The application role is being used to offer the same enhanced navigation options to screen reader users as is being provided to visual keyboard users (such as the keyboard interaction defined by the WAI-ARIA "menu or menubar widget" design pattern). The application role wouldn't be needed in this case if all screen readers passed along the keyboard events to the "application" for the menubar and menu roles by default

NVDA already does this. If other ATs don't, that is there bug. Essentially, you're using the application role because of bugs in other ATs, yet the issue is apparently ours when this becomes a problem.

What about the widgets for which NVDA doesn't stop intercepting the keyboard events by default? Would it be NVDA's problem then? What if websites choose to continue using the application role to enable enhanced keyboard interaction for certain widgets on as many screen readers as possible? Is it NVDA's problem that this presents obstacles exclusively to NVDA users?

All we are asking is for NVDA to treat widgets/applications consistently and to not implement entirely different behaviour for certain widgets/applications just because they have an application role.

There is no requirement in WAI-ARIA for the application portion to be the "main backbone" of the Web page as covered earlier in this response.

I'll grant I didn't explain this well. The point isn't that it has to be the root. It's a question of navigation. If you navigate to the individual widgets by way of a document, then it's a document with widgets and the application role doesn't apply. If you navigate to widgets by way of keyboard navigation in an application (e.g. Yahoo! Mail), then it's definitely an application.

Since the W3C considers a widget to be an application, the application role can certainly apply to the widgets within a document. Of course the application role shouldn't be used on all widgets, only the widgets that provide enhanced keyboard interaction and that aren't passed keyboard events by default because screen readers are intercepting those events.

2) To signal to the screen reader that the normal browsing mode may not be the most effective way of navigating the region in question and that the author is offering what should be more appropriate keyboard interaction.

In the case of number 2, why would this signal only be applicable if the role is defined on the root node of the page or is the "main backbone"? Why wouldn't it be applicable to widgets where the normal browsing mode may not be appropriate and the author is offering task-focused keyboard interaction?

By that logic, every single interactive widget (editable text fields, lists, tab lists, etc., ARIA or otherwise) should be marked as an application, but surely you agree this is incorrect. The spec states:

A region declared as a web application, as opposed to a web document.

Browse mode is only relevant for web documents.

Of course I agree that such an extreme interpretation is incorrect. Authors should only be applying the application role to widgets that provide enhanced keyboard interaction and that aren't passed keyboard events by default because screen readers are intercepting those events.

So for components such as editable text fields, the application role should not be applied since these are natively supported by the browser and are not considered to be widgets. For widgets that are passed keyboard events by screen readers by default, such as tab panels, the application role should not be applied (unless it is needed to signal to some screen readers to stop intercepting those events).

So it certainly isn't every widget that needs the application role, just where it is needed to signal to screen readers that they should stop intercepting the keyboard events used by the widget to provide enhanced keyboard interaction.

[nvaccessAuto]

Comment 20 by jteh (in reply to comment 19) on 2013-05-06 05:44 Replying to pjackson28:

According to the W3C a widget is a "full-fledged client-side application".

As far as I can tell from a brief glance, ARIA doesn'tspecifically refer to that particular definition of application, nor would i argue was it intended to.

In ARIA's explanation of the application role, it very specifically differentiates between documents and applications, which is precisely what we do. An application is not a document. By your argument, every ARIA widget should be marked as an application, but ARIA doesn't require this. That would suggest the application role has a very specific meaning, not just "a widget".

NVDA already does this. If other ATs don't, that is there bug. Essentially, you're using the application role because of bugs in other ATs, yet the issue is apparently ours when this becomes a problem.

What about the widgets for which NVDA doesn't stop intercepting the keyboard events by default? Would it be NVDA's problem then?

If they have proper ARIA roles, then yes, it would absolutely be NVDA's problem. In fact, we've spent considerable effort on fixing bugs like this in the past.

All we are asking is for NVDA to treat widgets/applications consistently and to not implement entirely different behaviour for certain widgets/applications just because they have an application role.

The contention here is the definition of "widget" and "application". I'd argue they are different and that ARIA intends this as explained above.

So for components such as editable text fields, the application role should not be applied since these are natively supported by the browser and are not considered to be widgets.

What about ARIA textboses? They aren't considered widgets by the browser.

[nvaccessAuto]

Comment 21 by jteh on 2013-05-06 06:08 Let's go back to basics here. What you're asking is for us to allow an application to be navigated in browse mode, but this violates the spec. The spec requires us to not intercept keys for the application role, so we don't. If we render it in browse mode, moving the focus inside the application (including via browse mode) requires us to stop intercepting keys, which caused #990 and required the subsequent fix. Whether we agree or not about definitions or practicality, what we are doing does not violate the spec. I doubt we're going to reach any agreement other than this, so further discussion is probably pointless.

[nvaccessAuto]

Comment 22 by pjackson28 (in reply to comment 20) on 2013-05-06 07:03 Replying to jteh:

Replying to pjackson28:

According to the W3C a widget is a "full-fledged client-side application".

As far as I can tell from a brief glance, ARIA doesn'tspecifically refer to that particular definition of application, nor would i argue was it intended to.

In ARIA's explanation of the application role, it very specifically differentiates between documents and applications, which is precisely what we do. An application is not a document. By your argument, every ARIA widget should be marked as an application, but ARIA doesn't require this. That would suggest the application role has a very specific meaning, not just "a widget".

WAI-ARIA doesn't define what is a Web application nor does it exclude widgets from being considered applications yet in other W3C recommendations they clearly associate the two. WAI-ARIA also makes it clear that an application can be all or part of a Web page which certainly allows for widgets to be considered applications.

WAI-ARIA is also very clear that for the application role "The intent is to hint to certain assistive technologies to switch from normal browsing mode into a mode more appropriate for interacting with a web application". This is not about labeling everything as an application that qualifies as an application it is about signalling to a screen reader when keyboard events should be passed to the application when it doesn't already do so. It is the same for the document where it is about signalling that a screen reader should "switch to document browsing mode, as opposed to passing keyboard events through to the web application".

The document and application roles are all about signalling to screen readers to change how they currently handle keyboard events (intercepting them versus padding them to the application). If the screen reader is already handling the keyboard events correctly then there is no need for either of these two roles as they are just meant to change the default behaviour.

NVDA already does this. If other ATs don't, that is there bug. Essentially, you're using the application role because of bugs in other ATs, yet the issue is apparently ours when this becomes a problem.

What about the widgets for which NVDA doesn't stop intercepting the keyboard events by default? Would it be NVDA's problem then?

If they have proper ARIA roles, then yes, it would absolutely be NVDA's problem. In fact, we've spent considerable effort on fixing bugs like this in the past.

All we are asking is for NVDA to treat widgets/applications consistently and to not implement entirely different behaviour for certain widgets/applications just because they have an application role.

The contention here is the definition of "widget" and "application". I'd argue they are different and that ARIA intends this as explained above.

As explained above, there is no evidence to support the argument that a widget is not an application but there is evidence to support the association between the two. In the end it doesn't really matter as the main purpose of the application role is to signal to the screen reader when to stop intercepting most keyboard events (much like the menubar and tablist roles signal to screen readers).

What we are asking for is that NVDA treat all signals to stop intercepting most keyboard events consistently, whether they be in the form of menubar, tablist or application roles. We don't see how it benefits the end user to single out the application role and to treat it differently than other roles that are signals to stop intercepting keyboard events. It is just as easy for an author to mess up the keyboard interaction for a menubar or tablist region as it is for an author to mess up the keyboard interaction for an application region.

So for components such as editable text fields, the application role should not be applied since these are natively supported by the browser and are not considered to be widgets.

What about ARIA textboses? They aren't considered widgets by the browser.

WAI-ARIA states that the following for the textbox role: "The intended use is for languages that do not have a text input element, or cases in which an element with different semantics is repurposed as a text field." So natively supported textboxes (input type="text" or textarea elements) are not intended to be covered by this ARIA role.

[nvaccessAuto]

Comment 23 by pjackson28 (in reply to comment 21) on 2013-05-06 08:12 Replying to jteh:

Let's go back to basics here. What you're asking is for us to allow an application to be navigated in browse mode, but this violates the spec. The spec requires us to not intercept keys for the application role, so we don't. If we render it in browse mode, moving the focus inside the application (including via browse mode) requires us to stop intercepting keys, which caused #990 and required the subsequent fix. Whether we agree or not about definitions or practicality, what we are doing does not violate the spec. I doubt we're going to reach any agreement other than this, so further discussion is probably pointless.

What we were originally asking is for NVDA to treat the application role like the menubar and tablist roles. In other words, we are asking NVDA to stop forcing the user to have to hit enter to enter an application region.

We were just suggesting rendering it in browser mode as a potential compromise solution to avoid the user being forced to hit enter to interact withenter an application region. Ideally you would just re-enable the automatic transition to focus mode like you had before (or whatever mode was used) and provide a configuration option to enable/disable that transition like you do with focus mode in general. NVDA should essentially treat the application role the same as the menubar and tablist roles by enabling a smooth transition to the appropriate mode (without forcing the enter key to be used first).

As for #990, I don't agree with the resolution as it doesn't address the underlying issue, the user entering in an application region and not knowing how to get out. All the resolution does is hide the application region from the user until they explicitly request to enter it. It also make it more cumbersome for the end user to deal with the application region than for other regions.

I don't see the issue with "falling into" an application region as that is no different than what happens for menubar and tablist. If you are concerned about a user "falling into" an application region and getting confused then make it a configurable option as to whether or not "falling into" an application region should be allowed. This choice should ultimately be up to the user regarding how they want to deal with an application region.

As for confusion when the user enters the application region, it would be helpful to declare right up front how to exit the region. That way when a user falls into an application region, they know right up front how to quickly restore the normal browse mode.

As for your statement that what NVDA is doing doesn't violate the WAI-ARIA spec, I don't disagree. What we are instead arguing is that NVDA is decreasing usability for the end user with how the application role is being handled. We feel there are better ways of dealing with #990 than forcing all NVDA users to hit enter to interact with an application region.

As for whether or not further discussion is pointless, that is your decision but we continue to recommend that you take a different approach to the application role like was suggested previously. Ultimately authors are going to use the application role regardless of what NVDA does. It will be no different with us as we are going to use the application role when we need to trigger a change in screen reader handling of keyboard events in order to provide enhanced keyboard interaction to screen reader users.

To be clear on our position, our use of the application role is conformant with the WAI-ARIA spec. We will only use the application role where necessary to maximize screen reader support for enhanced keyboard interaction that we provide. Any usability issues that may arise from how NVDA chooses to handle the application role will continue to be NVDA's responsibility.

[nvaccessAuto]

Comment 24 by jteh (in reply to comment 22) on 2013-05-06 10:32 Replying to pjackson28:

The document and application roles are all about signalling to screen readers to change how they currently handle keyboard events (intercepting them versus padding them to the application).

I disagree with your interpretation that this is all they are about. If that were so, there'd be no need for it to be included in the spec, since the spec would just require all ATs to follow the rules correctly for all ARIA widgets. Essentially, you're suggesting that the spec is providing a work around solution for broken ATs.

Doing as you suggest requires treating an entire web page as a single "document" and just switching between two so-called modes. Aside from being strange (why should web applications have browse mode when any other type of application doesn't), it also breaks (imo correct) use cases such as Yahoo! Mail. As an example, if we did this, when you open a message in Yahoo! Mail, we'd just switch to browse mode, but the entire chrome of the Yahoo! Mail application would then be browseable. This simply doesn't make sense. In an email client, a user expects the mail message to be an isolated document, not to contain the chrome of the mail client.

[nvaccessAuto]

Comment 25 by pjackson28 (in reply to comment 24) on 2013-05-06 17:00 Replying to jteh:

Replying to pjackson28:

The document and application roles are all about signalling to screen readers to change how they currently handle keyboard events (intercepting them versus padding them to the application).

I disagree with your interpretation that this is all they are about. If that were so, there'd be no need for it to be included in the spec, since the spec would just require all ATs to follow the rules correctly for all ARIA widgets. Essentially, you're suggesting that the spec is providing a work around solution for broken ATs.

Then please reference where it states in WAI-ARIA that there is more to the application role than being a navigational landmark and signalling to screen readers to stop intercepting most keyboard events. I can't find any evidence in WAI-ARIA that there is anything more to the application role.

Keep in mind that WAI-ARIA doesn't define or provide a role for all possible widgets (nor does it intend to). It also doesn't intend for the role defaults to be applicable to all situations. There needs to be a mechanism where the keyboard events handling of a role can be overridden by an author which is where the document and application roles come in. Consider the following scenarios:

1) How would you suggest we signal to NVDA to stop intercepting keyboard events for a widget that provides task-focused keyboard interaction but the associated WAI-ARIA role does not instruct screen readers to stop intercepting keyboard events (such as the slider role)?

2) What about roles where an author MAY manage focus such as the toolbar role? How would NVDA know when the author is going to manage focus and when the author won't? How can the author signal to NVDA to stop intercepting keyboard events on such roles without the application role? There is no way for NVDA to tell which is why it is important to have the application and document roles to declare the author's intentions.

With the approach NVDA has taken, it creates issues for the two scenarios above as it forces the user to have to hit enter to interact with the region in question any time the author provides task-focused keyboard interaction.

Doing as you suggest requires treating an entire web page as a single "document" and just switching between two so-called modes. Aside from being strange (why should web applications have browse mode when any other type of application doesn't), it also breaks (imo correct) use cases such as Yahoo! Mail. As an example, if we did this, when you open a message in Yahoo! Mail, we'd just switch to browse mode, but the entire chrome of the Yahoo! Mail application would then be browseable. This simply doesn't make sense. In an email client, a user expects the mail message to be an isolated document, not to contain the chrome of the mail client.

What we are asking NVDA to do is to treat the application region the same way it treats menubar and tabpanel widgets. We are asking that the requirement to hit enter to interact with the region be removed and that NVDA stop intercepting most keyboard events automatically when interacting with the application region, just like is done when interacting with menubar and tabpanel widgets. We are asking for consistency in how these regions are treated and to stop segregating the application region. This model already works for the menubar and tabpanel widgets so why is it an issue for the application region?

I don't understand the need to fully isolate users from the chrome while in the document. It is one thing to group them separately with proper semantic markup so it is clear what is part of the document and what is part of the chrome but I don't see the benefit of forcing the user to exit the document region, move to the application region then hit enter to interact with the application region just so the user can figure out what the chrome has to offer and then to start interacting with the chrome. That presents a lot of unnecessary steps for the user and would be very cumbersome and confusing. The user should be able to quickly find and interact with an option in the chrome and not have all these extra steps.

Considering this from the visual keyboard user standpoint, it would be hugely inefficient to make them have to leave the document region, move focus to the chrome and then hit enter to start interacting with the options in the chrome. I'm not aware of any keyboard accessible user interface that requires this of a user. Most keyboard accessible interfaces allow rapid access to options in the chrome with keyboard shortcuts (such as Alt+F to open the file menu) so why wouldn't a user be able to rapidly navigate to the chrome using headings, landmarks and other navigation options available to screen reader users? Why is the only option to first navigate to the application region, second hit enter to interact with that region, then finally figure out what options are available? That is way less efficient than the options that are available to keyboard users when screen readers already have the built-in navigation shortcuts.

We are asking that NVDA make this much more efficient for users by removing the requirement to hit enter to interact with the application region before the contents of the region can be discovered and interacted with.

[nvaccessAuto]

Comment 26 by jteh (in reply to comment 25) on 2013-05-06 23:34 Replying to pjackson28:

Then please reference where it states in WAI-ARIA that there is more to the application role than being a navigational landmark and signalling to screen readers to stop intercepting most keyboard events. I can't find any evidence in WAI-ARIA that there is anything more to the application role.

As I pointed out, the contention is in the definition of the term "application". You had to reference a completely unrelated spec to come up with your definition. I'll grant I can't provide any such reference, but I do know that ARIA was intended to allow for the same flexibility of access that desktop applications can attain. Browse mode is not an efficient way to navigate complex applications (e.g. mail clients), hence the application role. Aside from Yahoo! Mail, there is no other web mail client I would even consider using because of this inefficiency.

1) How would you suggest we signal to NVDA to stop intercepting keyboard events for a widget that provides task-focused keyboard interaction but the associated WAI-ARIA role does not instruct screen readers to stop intercepting keyboard events (such as the slider role)?

NVDA treats sliders as an interactive widget, which means you can manually switch to focus mode for them or they can trigger an automatic switch if they are focused.

With the approach NVDA has taken, it creates issues for the two scenarios above as it forces the user to have to hit enter to interact with the region in question any time the author provides task-focused keyboard interaction.

Even if we do as you ask, they'll still have to do this in order to use your keyboard navigation. Before that point, they'll be using browse mode navigation. Arguably, that violates the spec.

I don't understand the need to fully isolate users from the chrome while in the document. ...

Most keyboard accessible interfaces allow rapid access to options in the chrome with keyboard shortcuts (such as Alt+F to open the file menu) so why wouldn't a user be able to rapidly navigate to the chrome using headings, landmarks and other navigation options available to screen reader users?

We don't provide browse mode in applications (ARIA or otherwise) because, as you yourself point out, an application is supposed to provide efficient navigation shortcuts which are better suited than those designed for navigating documents. Every Windows desktop mail client in existence isolates the message document from the chrome and the user uses keyboard shortcuts or similar to move focus back to the chrome. This is far more efficient and is the experience Yahoo! Mail is emulating.

[nvaccessAuto]

Comment 27 by pjackson28 (in reply to comment 26) on 2013-05-07 03:49 Replying to jteh:

Replying to pjackson28:

Then please reference where it states in WAI-ARIA that there is more to the application role than being a navigational landmark and signalling to screen readers to stop intercepting most keyboard events. I can't find any evidence in WAI-ARIA that there is anything more to the application role.

As I pointed out, the contention is in the definition of the term "application". You had to reference a completely unrelated spec to come up with your definition. I'll grant I can't provide any such reference, but I do know that ARIA was intended to allow for the same flexibility of access that desktop applications can attain. Browse mode is not an efficient way to navigate complex applications (e.g. mail clients), hence the application role. Aside from Yahoo! Mail, there is no other web mail client I would even consider using because of this inefficiency.

I'm assuming your focus on the "application" definition is because of the differences between NVDA's focus mode and how it handles the application role. These differences do present a problem because it adds extra complexity for the end user whenever we try to override the screen reader's default keyboard event handling for a given widget.

This is especially problematic for widgets that the author MAY manage focus as the screen reader will normally default to intercepting keyboard events. To override that default so we can provide task-focused keyboard interaction, we would need to use the application role but that brings about the complexity of the specialized application mode when all we wanted was just the focus mode.

How can we signal to NVDA to override the widget default and switch to focus mode? Since this would normally be done with the application role, how can we make the switch without bringing about the extra complexity of the full-fledged application mode?

1) How would you suggest we signal to NVDA to stop intercepting keyboard events for a widget that provides task-focused keyboard interaction but the associated WAI-ARIA role does not instruct screen readers to stop intercepting keyboard events (such as the slider role)?

NVDA treats sliders as an interactive widget, which means you can manually switch to focus mode for them or they can trigger an automatic switch if they are focused.

Okay, I admit that wasn't the best example. The point I was trying to make was that there could be some scenarios where we want to switch into focus mode for a widget where NVDA doesn't do it by default. In such a case we need a way to signal to NVDA that it should switch into focus mode. How do we signal to NVDA to switch into focus mode in that case? From what I read in WAI-ARIA we should be using the application role to send the signal but NVDA instead switches to another mode altogether once the user hits enter.

What we are hoping to achieve in this case is to get NVDA to stop intercepting keyboard events without having to hit enter, like is done for the menubar and tabpanel widgets. How do we achieve this for those widgets for which NVDA doesn't switch into focus mode by default?

[nvaccessAuto]

Comment 28 by jteh (in reply to comment 27) on 2013-05-07 04:06 Replying to pjackson28:

I'm assuming your focus on the "application" definition is because of the differences between NVDA's focus mode and how it handles the application role.

My point is that there needs to be a difference to enable the same degree of flexibility that desktop applications can attain; e.g. the ability to have a document inside an application which doesn't expose the chrome of the application.

How can we signal to NVDA to override the widget default and switch to focus mode?

You don't. If the widget is one of the types ARIA considers to be potentially interactive, NVDA already handles this. This makes the experience consistent for the user; e.g. all buttons behave the same, all sliders behave the same, all menus behave the same. If the user is aware that this widget is inconsistent, they can force focus mode. If NVDA isn't switching to focus mode when it should for a given ARIA widget, that is probably a bug we need to fix. A way to mark arbitrary widgets as interactive might be nice, but I don't believe the application role is the correct concept, not least because it detriments things like Yahoo! Mail as I explained above. (Of course, this is the primary point of disagreement here.)

It's worth noting that even screen readers that do render the content of applications into the parent document still treat the application role separately. I believe JAWS has an app mode; it's not considered part of forms mode.

[nvaccessAuto]

Comment 29 by pjackson28 (in reply to comment 28) on 2013-05-07 04:42 Replying to jteh:

Replying to pjackson28:

How can we signal to NVDA to override the widget default and switch to focus mode?

You don't. If the widget is one of the types ARIA considers to be potentially interactive, NVDA already handles this. This makes the experience consistent for the user; e.g. all buttons behave the same, all sliders behave the same, all menus behave the same. If the user is aware that this widget is inconsistent, they can force focus mode. If NVDA isn't switching to focus mode when it should for a given ARIA widget, that is probably a bug we need to fix. A way to mark arbitrary widgets as interactive might be nice, but I don't believe the application role is the correct concept, not least because it detriments things like Yahoo! Mail as I explained above. (Of course, this is the primary point of disagreement here.)

I still think WAI-ARIA intended that application role for changing the keyboard event handling for arbitrary widgets but I understand why you wouldn't want to compromise your enhanced support for complex applications. Is there a way to have the best of both worlds? Have the application role trigger focus mode in certain contexts and the full application mode in others? For instance trigger full application mode if the application role is applied to the root node or a document role is nested inside the application region, otherwise trigger focus mode. Would that work? There may be more use cases to cover but I think it would be in the best interest of end users if the application role handling can adapt to both complex applications like Yahoo Mail and embedded custom widgets.

It's worth noting that even screen readers that do render the content of applications into the parent document still treat the application role separately. I believe JAWS has an app mode; it's not considered part of forms mode.

JAWS does have an application mode but it is almost identical to forms mode except with a few extra keyboard events passed along (such as events for the escape key).

[nvaccessAuto]

Comment 30 by jteh on 2013-05-07 06:11 As a final word on this, at this stage, we will not implement this. If the spec is ever changed such that what we are doing is unambiguously incorrect, we will reconsider this issue.

It seems that even if we could propose an alternative, you still need to use the application role to work around other ATs. Regardless of your disagreement with the way we handle the application role, I would hope you are putting as much pressure on other AT vendors to fix their handling of the widget types you had problems with as you are on us, since you wouldn't need the application role in the first place if such problems hadn't arisen.

[nvaccessAuto]

Comment 31 by jteh on 2013-05-07 06:11 Changes: Removed labels: invalid Added labels: wontfix

[nvaccessAuto]

Comment 32 by pjackson28 (in reply to comment 30) on 2013-05-08 03:27 Replying to jteh:

As a final word on this, at this stage, we will not implement this. If the spec is ever changed such that what we are doing is unambiguously incorrect, we will reconsider this issue.

This issue was never about whether NVDA was meeting the spec or not. All along it has been about our concern that NVDA's approach to the application role is creating usability issues for end users (when used with widgets). Our testers found the end result to be more cumbersome in NVDA than in other screen readers because of the requirement to use enter to interact with the region and no information being provided about what can be found within the region (beyond it being an application).

Regardless of whether or not you feel it is appropriate to use the application role on widgets, there are many examples on the Web where this is happening. For example, all the widget examples provided by OpenAjax Accessibility and the Illinois Center for Information Technology and Web Accessibility use the application role. The reason why this is interesting is some of those examples are referenced from the WAI-ARIA Authoring Practices 1.0. Now I am not saying I agree with how they coded these widgets, I am simply pointing out that they are using the application role for their widgets and there are sites that implement these examples.

I acknowledge that you have decided not to address the usability concerns that we raised. I may not agree with that decision, but it is ultimately NVDA's decision to make and to be responsible for. Should you decide to reconsider at some point, you may want to try having the application role trigger focus mode in certain contexts and the full application mode in others (like I suggested in my previous response).

It seems that even if we could propose an alternative, you still need to use the application role to work around other ATs.

NVDA is not the only screen reader out there or even the most used according to the most recent WebAIM survey (http://webaim.org/projects/screenreadersurvey4/#primary). So you are right, Web sites can't just focus on supporting NVDA so inevitably the application role is going to be used in some cases which will mean usability issues for NVDA users unless NVDA's approach to the application role changes.

Regardless of your disagreement with the way we handle the application role, I would hope you are putting as much pressure on other AT vendors to fix their handling of the widget types you had problems with as you are on us, since you wouldn't need the application role in the first place if such problems hadn't arisen.

We have in the past and will continue to do so when our testing finds issues with the screen readers themselves.