This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 20088 - Discuss benefits of using role=application
Summary: Discuss benefits of using role=application
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: Using ARIA in HTML (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: dmacdona
QA Contact: This bug has no owner yet - up for the taking
URL:
Whiteboard:
Keywords: a11y, aria
Depends on:
Blocks:
 
Reported: 2012-11-26 16:57 UTC by Dominic Mazzoni
Modified: 2014-01-29 22:43 UTC (History)
4 users (show)

See Also:


Attachments

Description Dominic Mazzoni 2012-11-26 16:57:53 UTC
The section on using role=application is good in that it cautions web developers from using role=application in cases where it could be harmful. However, I feel like what is missing is the *why*: why is it occasionally useful to use role=application, what are the actual effects? And why is it often harmful to use it, what are the negative consequences?

For example, I think it'd be helpful to quickly note that for "modal" screen readers, most keystrokes are captured by the screen reader and not the web page when the user is in browse mode. This prevents screen reader users from having access to global keyboard shortcuts in a web app. Application mode means that screen reader shortcuts for browsing the page are no longer available, all keystrokes go to the page. The user won't be able to skip around the page by headings or read a paragraph of static text line-by-line. So, if the advantages of keyboard shortcuts outweigh the loss of those features, role=application is warranted.

I think that's clearer than the 90-95% guideline, which is arbitrary. A web app could only be 50% focusable controls but still benefit from role=application (with judicious use of role=document), and another web app could be 95% focusable controls but there'd be no reason to use role=application because it has no global keyboard shortcuts.

Also maybe note that it is not necessary to use role=application to have control-specific keyboard shortcuts while the user is in focus mode: a custom control with ARIA role=listbox can easily capture all keys pressed including arrow keys, while the user is interacting with it.
Comment 1 dmacdona 2014-01-17 12:52:13 UTC
=======
For example, I think it'd be helpful to quickly note that for "modal" screen readers, most keystrokes are captured by the screen reader and not the web page when the user is in browse mode. This prevents screen reader users from having access to global keyboard shortcuts in a web app. Application mode means that screen reader shortcuts for browsing the page are no longer available, all keystrokes go to the page. The user won't be able to skip around the page by headings or read a paragraph of static text line-by-line. So, if the advantages of keyboard shortcuts outweigh the loss of those features, role=application is warranted.

DONE
===========

I think that's clearer than the 90-95% guideline, which is arbitrary. A web app could only be 50% focusable controls but still benefit from role=application (with judicious use of role=document), and another web app could be 95% focusable controls but there'd be no reason to use role=application because it has no global keyboard shortcuts.

DONE Already fixed in previous edits

=======

Also maybe note that it is not necessary to use role=application to have control-specific keyboard shortcuts while the user is in focus mode: a custom control with ARIA role=listbox can easily capture all keys pressed including arrow keys, while the user is interacting with it.

DONE
Comment 2 dmacdona 2014-01-17 13:21:55 UTC
This can now be closed