20088 2012-11-26 16:57:53 +0000 Discuss benefits of using role=application 2014-01-29 22:43:32 +0000 1 1 1 Unclassified HTML WG Using ARIA in HTML unspecified PC All RESOLVED FIXED a11y, aria P2 normal --- 1 dmazzoni david100 david100 hans.hillen mike public-html-bugzilla dave.null oldest_to_newest 78840 0 dmazzoni 2012-11-26 16:57:53 +0000 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. 98696 1 david100 2014-01-17 12:52:13 +0000 ======= 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 98709 2 david100 2014-01-17 13:21:55 +0000 This can now be closed