Where did this paradigm that, when role “application” is being used, browse mode can no longer be enabled, come from? Could it not be implemented in a less strict fashion?

There are both practical and principle reasons to strictly treat them differently. The practical reasons include the following. (I’m using NVDA terminology here, but the same is true for other Windows screen readers.)
In focus mode, certain keys such as escape and alt+upArrow are still captured to switch back to focus mode (the latter is conditional).
Also, if auto focus mode is enabled, the screen reader would switch between focus and browse modes depending on the focused element, which should not happen inside an application.
The screen reader shouldn’t have to do browse mode rendering at all for applications, which improves performance.
If the body is marked as an application, NVDA at least doesn’t even know it’s a web document.

In terms of principle, if an author has marked a region as an application, it should be treated as such. Otherwise, they don’t get the full power of “being an application”. (As always, power incurs responsibility.)

Marco continued:

But what’s the guideline? How can we help web developers make that decision?

I agree this is tricky. Your revised advice is probably as good as we can get: only use it if you want a user to navigate this region in a desktop-like fashion (as opposed to document-like fashion).

Marco’s revised article says:

▪dialog and alertdialog. These cause screen readers to go into a sort of application mode implicitly once focus moves to a control inside them.

For NVDA at least, this is not just “a sort of application mode”. It really is the same thing. (For the technically curious, a better way to think of this is that it *doesn’t* use browse mode. Only documents use browse mode; documents are special, not applications. There is actually no “application” mode in NVDA. I believe JAWS does have a separate app mode though.)

Marco wrote:

The problem here, I think, is that they change the focus visually only.

Yup, I had to do some serious Greasemonkey magic on Twitter for the same reason. Basically, I detect the visual focus and make it real focus. It is a very annoying habbit in quite a few mainstream web sites.

Steve Faulkner wrote:

Inclusion of role=”application” as a landmark is a point of confusion, as is the differing affects it has across platforms.

The key then is to understand when and why to use it, not what effect it will have on a given platform.

Steve continued:

This may be a dumb question, but why can’t screen readers just set the appropriate interaction mode based on widget roles?

Aside from the answers already given, another reason is that sometimes, an application globally overrides the arrow or alphanumeric keys; e.g. j and k to move to previous/next item or g to go somewhere. In this case, if you’re focused on a link (which would normally trigger browse mode) and there’s no way for the author to specify this is an application, those shortcut keys would be unusable. Btw, to answer a later question, focus isn’t an indicator for the same reason: focus on a link suggests browse mode.

Marco wrote:

Mac OS X and iOS use a completely different user interaction paradigm. … if you need to input something and focus an element, you just start typing. The only exception is if quick navigation is enabled by pressing left and right arrow keys simultaneously. This causes all keyboard input to be captured even when the focus is in a text field or the like.

While many claim there are only advantages to this approach and that it frees you from the mode switching problems of the Windows world, it actually doesn’t. Quick nav mode is just that: a different mode. At least on iOS, quick nav mode is enabled by default a lot of the time and it switches automatically if you activate an editable text field (and then switches off when you navigate out). This means that users still have to be educated about modes. This leads me to ask: why do people complain about these “modes” in Windows screen readers while the same complaint is not made about iOS? Why is it so unacceptable for screen reader users to just be a little educated about them? In NVDA, for example, you can lock focus mode with NVDA+space, after which it will not switch to browse mode again until the user does it manually or a different page loads. This is no more complex than quick nav mode on iOS.

This is a great article and I will recommend it to anyone who might be interested.

Steve, Mac OS X and iOS use a completely different user interaction paradigm.

That was my point, role=application means different things, on Mac its not a problem as it is merley a semantic indicator.
you wrote:

The tricky part is that there is no standard way to tell a screen reader that “this element is interactive”.

Isn’t focus an indicator?

You then ask:

why can’t screen readers just set the appropriate interaction mode based on widget roles?

They do, in many cases, as I point out above. In NvDA, for example, you can tab to a tree view, and NVDA will automatically switch to focus mode. The tricky part is that there is no standard way to tell a screen reader that “this element is interactive”. Screen readers can only whitelist roles for which they allow switching to focus mode. If we had something standard that widget authors could use, that would be extremely helpful!

First and foremost, thanks for your great comments! Here are a few points I’d like to respond to.

Jamie writes:

First, it’s important to note that role=”application” does not just enable focus mode. In focus mode, you can normally hit escape or some other key to switch back to browse mode. Also, if auto focus mode switching is disabled, the screen reader won’t automatically switch to focus mode when an interactive widget gains focus. In contrast, in NVDA, if role=”application” is used, you cannot switch back to browse mode at all; as far as NVDA is concerned, this is no longer a document. As I understand it, the same is true for JAWS, though you can force enable the virtual cursor there.

Where did this paradigm that, when role “application” is being used, browse mode can no longer be enabled, come from? Could it not be implemented in a less strict fashion?

Jamie writes:

role=”application” should never be used unless you truly believe a given section or the entirety of what you are developing should behave like an application and not like a document.

yes I agree that this is the main point to make! And I’m considering making the above blog post even more restrictive based on your and others’ comments (some of which I received through other channels). But what’s the guideline? How can we help web developers make that decision?

Jamie continues:

Dialog and alertdialog should already be implicitly treated as applications, so a specific application role isn’t required here either.

Right, thanks for the pointer! This is, of course, assuming that the screen reader vendor treats these roles properly.

Pratik writes about Gmail:

Other than the assistive technology user not knowing these keyboard commands, there is an additional problem of the screen reader not providing appropriate feedback. Even if the focus is visually moving from message to message with j and k, there is no audible confirmation, leaving the user completely confused.

The problem here, I think, is that they change the focus visually only. or they use elements to focus they didn’t make focusable before, causing browsers not to emit focus events. These are usually what tell screen readers that the element of interaction has changed. Or a combination of both above mentioned.

Again: I’m certainly going to update this post to incorporate some of the points mentioned in your comments, so stay tuned!

Great post for the most part, though I very strongly disagree with a few points which I think could actually make this situation worse.

First, it’s important to note that role=”application” does not just enable focus mode. In focus mode, you can normally hit escape or some other key to switch back to browse mode. Also, if auto focus mode switching is disabled, the screen reader won’t automatically switch to focus mode when an interactive widget gains focus. In contrast, in NVDA, if role=”application” is used, you cannot switch back to browse mode at all; as far as NVDA is concerned, this is no longer a document. As I understand it, the same is true for JAWS, though you can force enable the virtual cursor there.

role=”application” should never be used unless you truly believe a given section or the entirety of what you are developing should behave like an application and not like a document. Tree views, sliders, interactive tables, tab controls (tab/tablist), toolbars, menus, etc. are all single compound widgets and should be handled just fine by browse mode/focus mode switching (excepting bugs in screen readers). This enables any of these widgets to be used as part of a document without breaking normal document interaction, just like the traditional widgets.

role=”application” is placed on the body of the Yahoo! Mail interface because the entire site has been structured to enable interaction as an application. To be honest, it is probably the only mainstream example I have ever seen where role=”application” is necessary and correctly used. Google Documents and Spreadsheets also do this, but the problem there is that there are too many links, etc. in the tab order before you hit the main part of the application.

Dialog and alertdialog should already be implicitly treated as applications, so a specific application role isn’t required here either.

Great article on the ‘application’ role! This could be turned into documentation for that role on MDN with only slight adaptation (similar to Using the alert role). If that’s OK with you (I didn’t find a copyright or licensing statement on your blog), I’ll add that to the list of possible tasks for MDN contributors.