The ARIA application role changes the way screen readers interact with web content. Several good articles explain (rightly) why the application role should be used with caution, but this post looks at a use case where the application role is used to good effect.
Screen readers sometimes intercept keystrokes and repurpose them for screen reader specific tasks, like navigating content by headings or reading a line of text. The application role prevents the screen reader from intercepting keystrokes, and passes them back through to the browser as though the screen reader wasn’t running. Read Understanding screen reader interaction for more information.
The decision to use the application role must therefore be taken carefully. It should only be used when there is no need for a screen reader user to be able to use any of the standard keyboard commands at their disposal. To put it another way, if you use the application role, the responsibility to provide all keyboard interaction lies with you.
In gallery view a screen reader user might want to navigate slides by heading, list or other element type, or to query content by word, line or paragraph. When in slideshow view and giving a presentation there is (almost) no need for any of the standard screen reader commands to be used though.
The exception is that a screen reader user needs to be able to query the title of each slide, and possibly the content of each slide as it appears. Instead of providing a specific keyboard shortcut to enable screen reader users to do this, the Shower engine accomplishes this using an ARIA live region, that causes screen readers to automatically announce the title and content of each slide as it appears in the slideshow view.
Thanks to a contribution from Dan Hopkins, the Shower engine applies the application role to theelement whenever slideshow view is enabled. When switching back to gallery view, the application role is removed and standard screen reader behaviour resumes.