Making Ember Applications’ UI Transitions Screen Reader Friendly


Note: An image of the LinkedIn-created logo for the self-focused open source project accompanies this post.
 

At LinkedIn, we strive to make our user interfaces (UIs) accessible for all of our users, including people with disabilities. So when the modernized, Single Page Application (SPA) version for linkedin.com was being developed a few years ago, we wanted to ensure that it was compatible with screen reading software such as JAWS (Job Access with Speech) and VoiceOver.

For context, when UI transitions happen in a SPA (or in any dynamic web application), there is visual feedback; however, for users of screen reading software, there is no spoken feedback by default. Traditionally, screen reading software automatically reads out the content of a web page during page load or page refresh. In single page applications, the UI transitions happen by rewriting the current page, rather than loading entirely new pages from a server; this makes it difficult for screen reading software users to be aware of UI changes (e.g., clicking on the navigation bar to load a new route).

Initially we wanted to use the existing ember-a11y addon to make the dynamic UI transitions screen reading software compatible. However after initial integration, we discovered that this addon could not be used as is and needed a couple of prerequisites to be addressed. Since the launch date of the modernized, Single Page Application (SPA) version for linkedin.com was set and could not be postponed, we worked on an internal solution, which not only addresses the use cases for linkedin.com, but also improves developer ergonomics for handling nested route transitions.

The solution

For background, if the corresponding HTML node of the dynamic content can be focused programmatically, screen reading software will start speaking the textual content of that node. Focusing the corresponding HTML node of the dynamic content can be considered guided focus management. Not only will it facilitate the announcement of the textual content of the focused HTML node, but it will also serve as a guided context switch. Any subsequent “tab” key press will focus the next focusable element within/after this context.

However, keeping track of the HTML nodes to be focused can be tedious, repetitive, and error-prone since there could be hundreds of nodes that need to be programmatically focused in a SPA, thus we created the ember-self-focused addon. It makes an Ember application’s UI transitions screen reading software friendly, and we are pleased to open source it today.

Architecture and design

The ember-self-focused addon provides two features: a contextual component, named “self-focused,” and a service, named “focus-manager.”

The self-focused component can be consumed like so:



Source link