{"id":314,"date":"2018-12-10T16:13:44","date_gmt":"2018-12-10T16:13:44","guid":{"rendered":"https:\/\/pressbooks.library.ryerson.ca\/wafd\/?post_type=chapter&p=314"},"modified":"2022-12-16T18:09:11","modified_gmt":"2022-12-16T18:09:11","slug":"application-and-presentation-roles","status":"publish","type":"chapter","link":"https:\/\/pressbooks.library.torontomu.ca\/wafd\/chapter\/application-and-presentation-roles\/","title":{"raw":"Application and Presentation Roles","rendered":"Application and Presentation Roles"},"content":{"raw":"The application and presentation roles in WAI-ARIA change the way assistive technologies interact with web content. Both have \u201cuse with caution\u201d warnings. Their use and where and when to use them are described here.\r\n

Application Role<\/h2>\r\nThe application role is used when there is not a corresponding widget interaction pattern available to provide semantics for a custom widget.\r\n\r\nImagine, for instance, a file manager application embedded in a web page, which does not have widget roles specifically defined. It may have many of the functions a typical file manager might have on a Windows, Mac, or Linux system. It might have the typical File, Edit, and View menus that most applications have, including browsers. Those menus in the file manager should function like these same menus in other applications. When the application role is used in a container containing the embedded file manager, keystrokes are intercepted and repurposed to operate the file manager, instead of the browser and the assistive technology.\r\n\r\nWhen in the file manager application, this behaviour may be desirable. But, defined with the application role, all of the standard screen reader shortcut keys are also disabled, so the user is no longer able to navigate the pages by headings, or landmarks, for instance, while inside the application. This may be fine in such a case because the screen reader user will likely temporarily want shortcut keys to file manager functions, and not those of the browser or screen reader.\r\n\r\nIf, however, the application role is used to contain a carousel widget, for example, then browser and assistive technology functionality may be unnecessarily disabled, potentially creating barriers. A carousel widget typically has limited functionality. For example, carousels may contain scripted Arrow keys to move back and forth between slides, between headings within each slide for added structure, or link to another section of the site presented in a slide. In such cases, screen reader users would be unable to navigate through the slides by listing headings or links, using their screen reader\u2019s default heading and link list functionality. By removing the application role, the scripted next\/previous link, as well as the heading and the links could be used to navigate the carousel.\r\n\r\nThe bottom line is to use the application role carefully. Be sure it is not creating more barriers than it is intended to prevent.\r\n

Presentation Role<\/h2>\r\nMuch like the application role disables default keyboard functionality, the presentation role (and its synonym role=\"none\"<\/code>), theoretically, removes the default semantics from children of the element it applies to.\r\n\r\nSo, for instance, if you have a list with role=\"presentation\"<\/code>, it should not announce as a list, and its list items should not announce as list items. However, nested lists within those suppressed list items will announce as usual.\r\n\r\nThere are a couple of intended exceptions where the presentation role will not remove default semantics:\r\n