Navigating with a screen reader
A screen reader interacts with a web page in a linear fashion, which means its always top to down or down to top. While navigating a web page using screen reader, a user can either move forward or backward, but at any given point of time, focus will be only at one portion or component of the interface. A screen reader also has numerous key commands to navigate efficiently between different elements on a UI such as headings, links, buttons and likewise, but it only reads one focusable element at a time.
As a native screen reader user, beyond just interacting with individual UI components, my challenge is how to even perceive all that is dynamically changing or updating on UI due to the actions I perform, or an event that takes place. For me it is important that the screen reader should read back or announce each and every content update happening on the screen.
Dynamic content notifications/live regions
There are two ways a screen reader can announce a dynamic content update on the screen:
-
By notifying screen reader of the changes when they happen with help of live regions, or,
-
By moving focus to the update directly
So how do we decide whether to use live regions to announce a dynamic content update versus using focus management to communicate the change in content on the page? The first thing to consider is Web Content Accessibility Guideline (WCAG) success criteria.
The WCAG 2.1 Success criterion 4.1.3 -Status messages states that the intent “is to make users aware of important changes in content that are not given focus, and to do so in a way that doesn't unnecessarily interrupt their work. For screen readers, this is generally done through live regions.”
Live regions are not region landmarks, that identify the main areas on a given page for quick navigation. Live regions are elements in the html that are used to hold messages which are provided to a screen reader at a certain time. The elements are initially empty and in case of any content update, this live region receives the message and this is announced by screen reader in the form of a live notification. When any visible notification or message is textual, brief, and momentary in nature, then the same can be announced by a screen reader with help of live regions or aria-live attribute. For example, consider an email application where we observe confirmation messages in event of an email sent, email delivery failure or a draft saved.
Live region types
Live regions can be created as assertive or polite based upon the urgency, importance and proactiveness of the message.
Assertive is used in cases when the message is urgent and the user needs to be informed immediately so they can react, for example, error messages or timeout alerts.
Polite is used when the message is to notify a status and can wait for a screen reader to complete the current task before announcing the message, for example, a success or confirmation message.
However, note that Aria-live provides inconsistent behavior with different screen readers and browsers, and are not always reliable, and used excessively can make a page very noisy. In many use cases, moving focus to the updated content is more appropriate, and is acceptable to meet WCAG.
Using focus to convey new content
In complex applications, new content is always being introduced and other content may be changing based upon an action. Using live announcements for all these changes can be quite noisy for a screen reader user. Therefore, there are various scenarios where moving focus to the new content is an alternative to using a live announcement. Consider the following scenarios.
-
Scenario 1 - Consider when you have a list of followers or stakeholders on a case. Each has remove icon button next to the name of each individual. If we delete any of the follower or stakeholder from the list by triggering its respective remove icon button, focus should immediately move to next remove icon button or any other control in logical sequence. Here live notification of the removal of item is not necessary as the focus movement to another expected location itself communicates that the action has been performed.
-
Scenario 2- In case of a table or grid while adding or deleting rows/ columns, instead of live notifications confirming the action, moving focus to the desired cell of table after the action itself would be sufficient. If adding a row, then focus would move to the new row. If deleting a row, then focus would move to the previous row. The user understand their action was successful.
-
Scenario 3- Consider UI widgets such as a search page, where based upon user choice or filters the content keeps on updating. Making live notification on each user choice will make UI noisy for screen reader user with limited additional benefit. Rather, just having an instruction at the beginning which states the action and its effect would be sufficient, stating “based upon the selections main content will get filtered” may be a better approach. This can even be seen within the WCAG guidance page itself.
Live regions are a useful method to convey visual content changes on a screen for a screen reader user. We must also consider if there are others way to convey that same information through another means like focus management. Both are acceptable for meeting WCAG guidance. Therefore, we need to consider our users and the level of information that is being announced to them from a single page. Live announcements are an excellent method to convey information, but clean user experience design can provide a much more positive and productive experience for all users in many use cases. Thus, a holistic inclusive design thinking is required before making the best choice for your users.
For more discussion, check out the following recorded webinar:
Accessibility: When to use live announcements for a screen reader user