Not entirely sure, but we might discuss/investigate this:

What about setting the application role to the body element and wrapping the page content with a div with the document role as soon as it contains administrative controls?

Comments

casey’s picture

casey commented

Examples:

Toolbar

<body role="application">
<div id="toolbar" role="menubar">
...
</div>
<div id="page" role="document">
...
</div>
</body>

Modal dialogs

Related: #1175830: Update to jQuery UI 1.10.2
Screenreaders don't use virtual buffers for applications, so we should be able to keep the focus trapped inside the modal dialog.

<body role="application">
<div id="page" role="document" aria-disabled="true">
...
</div>
<div role="dialog">
...
</div>
</body>

Overlay

Again, screenreaders don't use virtual buffers for applications, so we should be able to keep the focus trapped inside the overlay.

<body role="application">
<div id="page" role="document">
...
</div>
<div id="overlay" role="document">
...
</div>
</body>

Contextual links

Related: #1182522: Use <menu> and contextmenu attribute for contextual links

<body role="application">
<div id="page" role="document">
...
  <article id="node-123" contextmenu="node-123-contextual">
    <menu type="context" id="node-123-contextual">
      <command label="Edit">
    </menu>
    ...
  </article>

</div>
</body>
Everett Zufelt’s picture

Everett Zufelt commented

@Casey

What is the problem that you are trying to solve here, that isn't super clear to me.

casey’s picture

casey commented

Actually several:

  1. In applications you have full focus control
  2. You could have multiple documents on one page while giving only access to one. This could make overlay accessible. See example in my previous comment.
  3. This could be a solution for modal dialogs as we can control focus; drawback might be that modal dialogs would be only available in administrative contexts, but on the other hand that doesn't have to be a bad thing as we should be sparingly with modals. See example in my previous comment.
  4. HTML5's context menu is likely to only be available to applications if ever implemented. Not sure though. Also not sure if we really want to use this
  5. And the issue that brought me this idea: #546126: Toolbar interferes with anchor links. A styling issue rather than a accessibility issue. Proposed there was to wrap page content in a div. So we can fix issues regarding toolbar being positioned fixed. Issues like focussed elements being blocked visibly beneath the toolbar when using tab-navigation.
casey’s picture

casey commented
Status: Active » Closed (won't fix)

Nah... after some more thinking I concluded this just isn't correct. Administrative pages are no applications, so we shouldn't let AT-users think they are.

casey’s picture

casey commented

And a link to a nice article about the usage of the application role: Not All ARIA Widgets Deserve role="application".

casey’s picture

casey commented

Also it doesn't work in current version of NVDA (2011.1.1): http://www.nvda-project.org/ticket/1452

casey’s picture

casey commented

Still think we can control focus and virtual buffer some more when we can set application role on body element.

Point is you aren't supposed to change to role dynamically:

Roles are element types and authors MUST NOT change role values over time or with user actions. Authors wishing to change a role MUST do so by deleting the associated element and its children and replacing it with a new element with the appropriate role. Typically, platform accessibility APIs do not provide a vehicle to notify assistive technologies of a role value change, and consequently, assistive technologies may not update their cache with the new role attribute value.

But I found out that you can by doing the following:

$(document.body).attr('role', 'application');
document.documentElement.replaceChild(document.body, document.body);

So if application role turns out to be useful, this would be the way to do it.