Changes of context

Impact: Strong to major

Users mainly impacted: Blind, visually impaired, mentally impaired.

Explanation

A change of context is a change in the page that is likely to be ignored or misunderstood by a user who cannot see the page as a whole. This is particularly the case for blind users using a screen reader and visually impaired users who navigate with a screen magnifier.

Example: updating dynamic form fields or changing the dynamic content of the page.

To understand these changes, they must be notified in advance or the changes must be the result of an explicit action on their part.

People with mental and cognitive impairment may not be able to understand these changes if they are not informed in advance.

The changes of context are numerous on a page or a web application. A change of context is considered to occur in the following cases:

Change of user agent, for example a link on a phone number that open the call manager.
A change of restitution space, for example the display of a new page.
Change of focus, for example moving the focus from one place to another.
Change of content that changes the meaning of the page or an item, for example a dynamic content update, opening a modal window.

A change of content is not always a change of context. Changes in content, such as an expanding outline, dynamic menu, or a tab control do not necessarily change the context, unless they also change one of the above (e.g., focus).

The cases are multiple, here are some concrete cases.

Change of user agent

User agent changes can be multiple, here are a few examples:

Opening the call manager for a phone number.
Opening an email client for an email address.
Opening a specific software such as a PDF reader.

In order to make this accessible in practice, it is possible to give the link an accessible name.

Single page application

In a “Single page application” the reloading of a page is dynamic. After the user’s action, he/she is not informed of the page reload and loses his focus.

It is therefore necessary to inform him/her when the page reloads and to manage the focus return. So we’re going to simulate a page reload.

Update page title

As there was no real reload of the page by the user agent, it is necessary to update with Javascript the <title> of the page with a relevant page title.

Updating the <title> of the page is important because the user has the possibility at any time to ask for it to be read.

However, when reloading in Javascript, this is not enough because the <title> of the page is still not automatically returned in the technical assistance.

Simulate reloading the page thanks to focus

When the content is reloaded, the element activated by the user may no longer be present in the page, so he/she loses focus.

It will therefore be important to force the reading of the page title and to return the focus to the right place.

For a “Single page application” for example, in order to simulate a page reload, it will be necessary to reposition the focus at the top of the page.

To do this, let’s add a paragraph to the first element of the DOM:

<p class="sr-only" tabindex="-1" id="title-page">[TITLE]</p>

This content will be hidden in an accessible way with the “sr-only” class.
As the paragraph is not focusable by default, the tabindex attribute with the value -1 will allow to resume focus on the element with the Javascript method focus().

With the negative value, the element is not reachable via sequential keyboard navigation, but could be focused with Javascript.
The [TITLE] text will be synchronized with the <title> of the page with the document.title property.
Once the [TITLE] is up to date we can force the focus on this paragraph with the method focus().

Once the content is loaded, the user is at the top of the page and the title of the page is rendered by the technical support.

Major update of a content in the page with faceted search

Let’s take as an example a faceted search system. The whole page is not necessarily reloaded, only the results can be updated.

In a faceted search system, multiple filters (often in the shape of links or checkboxes) are related to each other and update the results. The action of one filter reloads the results dynamically and it is often necessary to activate several filters to obtain the desired results.

In this case, it is therefore necessary not to send the user back to the top of the page after each action on a filter because the user is likely to activate a new filter.

Update page title

As for a “Single page application” (See above) it is necessary to update the <title> of the page.

Inform the user of a content modification in the page

We assume that there are no changes to the filters, they are always displayed, only their status changes, active or inactive.

In this case the focus is not changed, we keep the user on the filter he/she just activated. This allows him/her to accumulate the filters quickly.

However, it is necessary to give him the information of the update of the results. Indeed, each time a filter is activated, the number of results in the list changes.

For this we will add above the list in a visible way a paragraph with the number of results.

<p id="results" aria-live="polite" aria-atomic="true">10 results</p>

The aria-live attribute with the value polite indicates that the helper should wait until the user is inactive before presenting an update to the user.
The aria-atomic attribute with the value true indicates to the technical assistant to read the whole area, not just the modified elements.

Never declare with the aria-live attribute a content area with too much information. This would cause the restitution of the entire area which would be inappropriate for the user.

Some fields such as text or date fields for example may require submission by a button to avoid reloading the list at each action in the field.

Status messages

The status messages are changes of context, more information on status messages can be found on this page.