This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
======= 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
This can now be closed