5. Findable Added Content

Make sure screen reader users can find dynamic additions to the screen

Ensure that screen reader users can find new dynamically-added content (e.g. expanding menus, alerts, error messages, hints that appear on rollover).

Rationale

When the content of page changes once the page has loaded, some accessibility concerns arise that are not addressed by accessibility guidelines for static content:

How will a screen reader user who may already have read much of the page know that the new content is now available?
How will a screen reader user know where to find the new content?
Will common screen reader applications recognize changes to the page?

Since dynamic content changes and additions are most often designed and tested by users who can see a large portions of the screen at once, these features most often work well for such users. These features can also work well for screen reader users, but they must be designed and tested with this type of access in mind.

HTML & JavaScript

Error Messages that Appear without a Page Refresh | Custom Alert Windows that don’t Contain Buttons or other User Interaction

The goal is to alert screen reader users to the new information. In addition, especially if the feedback appears while the user is typing into a field, the goal will be to provide the error message without moving the screen reader user’s focus (i.e. without taking the text-insertion point out of the form field).

The WAI-ARIA “alert” role makes this possible. Simply make role=“alert” an attribute of both:

The outer-most container that is added to the page

~AND~
The parent element of that element. Create a container just for the purpose of receiving the alert. (Needed for Safari with VoiceOver as well as, the lower priority configuration, Window-Eyes with IE)

To support TalkBack with Chrome on Android devices add aria-live=“assertive” to the container element that will receive the alert. Although not a top priority configuration, this is also needed to support NVDA with IE.

** HI PRIO ** external link

A test page for alert

This will cause screen readers to speak the error or alert when it appears visually. But, it won’t make any change to the screen reader user’s location on the page. So, for example, if a user is typing a password when the message is read, the user can continue to type that password, uninterrupted.

In screen magnifiers, sometimes the magnification level is so high that only a small section of the screen is shown at once. Magnifiers can be set to move focus to alerts and this will cause the error message or the upper left corner of the error message (in left-to-right languages) to be shown on the screen. Because of this, the upper left corner (or upper right in right-to-left languages) of the alert object should show the beginning of the error message.

Note: role=“alert” has no effect if it is just on the page when the page loads. The role only comes into play when the area is updated without a page refresh. As such, when an identical page, except for an added alert message, is loaded, different techniques are needed. See the section just below on this topic.

Error Messages that Appear with Page Refresh

In this scenario, screen reader users will hear that a new page has loaded. Because of this, the error message is not actually dynamically-added content! However, particularly if the page is the very same page shown again, it is good usability for screen readers users to make it easy to locate the error message. Some combination of the following techniques should be used:

Most often, screen readers read the title of the page when the page loads. So, it is helpful to including all or part of the error message in the page title.
The most common way that screen reader users explore a new page is that they read the headings on the page. Making all or part of the error message a heading is very helpful.
Screen reader users often tab from form element to form element, hearing the form label for each form element. In cases where detailed form error messages are provided for each form field, including those errors as part of the form label can be a helpful technique. See Pearson Guideline 14 for techniques on how to code form labels so that they will be read when screen reader users tab to form elements.

If you allow the page to load without the error message, and then add the error message using JavaScript after the page has fully loaded, you can use the role=“alert” technique described in the section just above.

Standard JavaScript Alert, Confirm, and Prompt Messages

Common screen readers and screen magnifiers should be able to handle these without any special coding.

Confirm: var r=confirm(“Continue?”);
Alert: alert(‘Please login first’); OR
Prompt: var name=prompt(“Please enter your name”,“”);

For information on using these and for examples, see: w3schools.com’s JavaScript Popup Windows (opens in new window).

Custom Dialogs that need to be Dismissed by the User | Custom Modal Windows

When the dialog appears, use JavaScript to move focus to the interactive element in the dialog that is most likely to be used first. When the dialog is closed, be sure to return focus to a logical location, such as the control that caused the dialog to appear.

If the dialog serves an “alert” function, add the following two attributes to the outermost element that is added to the page when the message appears:

role=“alertdialog”

~AND~
aria-describedby=“id” where id is the id of the message you want read automatically when the alert dialog first appears.

If the dialog isn’t really an “alert” and is more of just a separate window, add the following two attributes to the outermost element that is added to the page when the message appears:

role=“dialog”

~AND~
aria-label=“my message” where my message is the message you want read automatically when the dialog first appears OR aria-labelledby=“id” where id is the id of the message you want read automatically when the alert dialog first appears. (Yes, aria-labelledby should have the repeated letter l.)

These attributes tell screen readers and screen magnifiers to announce these additions to the screen as alert dialogs or as dialogs. Some screen readers will also switch into “forms mode” for navigation of the dialog. In this mode, the dialog is announced and then screen reader users move between active elements, often skipping inactive content. So, be sure that all content in the dialog is included through aria-describedby, aria-label, or aria-labelledby and/or through form labels. Form labels are discussed in detail in Pearson Guideline 14.

For older configurations that don’t support role=“alertdialog” or role=“dialog”, try to give an overview of the purpose of the dialog with the control that gains focus. For example, you might use “stay on this page” as your button text, instead of something less descriptive, such as “stay”.

Buttons that Reveal Content (e.g. expanding menus, expanding help topics)

One of the simplest techniques is to place the new content in the reading order just after the control that initiated the change.

It is important that users will know whether the section is expanded or collapsed. See Pearson Guideline 20 for information on this.

When Important Information Appears on Mouse Over

Often information is coded to appear onmouseover and onfocus. For example, when a mouse is pointed at a book cover image, a div element might appear as a box that provides more information about the book.

This information is at risk of being inaccessible to screen reader users. It only appears in the reading order for a short time, often while the screen reader is reading other content. You will have to decide if the information should always be read by the screen reader. If the information is essential or particularly brief, it is likely it should always be read, so you might:

Include the information as alt-text for a related image, OR
Keep the information visible to screen readers even when it is hidden for visual users by placing the information off-screen:
```
.screen_readers_only {
position:absolute;
left:-999px;
top:auto;
width:1px;
height:1px;
overflow:hidden; }
```

If the information is rather long and not necessary for a basic understanding of the page, it might be best if it is not part of the general reading order. To allow the content to be read on-demand only:

Include the information in the longdesc attribute of a related image:

<img src=“weather_today.gif”
alt=“Sunny 73 degrees”
longdesc=“weather_detail.html>“

Place the information on a second page and provide a link placed off screen so that the link is only available to screen reader users:
```
a.screen_readers_only {
position:absolute;
left:-999px;
top:auto;
width:1px;
height:1px;
overflow:hidden;
}
```

Areas that Update Periodically (e.g. News Feed, Social Features)

First, place the new content in a predictable consistent location within the page structure. The containing structure for this content should have a heading that tells the user what the section is for. Consider including the following information:

That the area is dynamic
Which conditions that will cause an update
Which content is currently present (or newest)

For example:

<h2>Hourly News as of 1 PM Today</h2>

In this case, a screen reader user will know that the section may be updated and can use heading reading techniques to scan the headings on the page and discover whether an update has been made.

If all or part of the heading is not needed for sighted users, you can hide the heading as follows:

h2.hidden {
position:absolute;
left:-999px;
top:auto;
width:1px;
height:1px;
overflow:hidden;
}

Second, particularly for social features, there should be a way for students or instructors to be notified that new information is available. The following techniques are some options. You may wish to allow your users to select an option in user preferences.

Make any text that announces the new content into an alert by placing role=“alert” on the outermost HTML element that is added to the page when the icon or the alert appears. For example: <div role=“alert”>You have a new message</div>
Play a beep or a tone when a new message appears. (Thanks to Michael Brooks of Penn State University for suggesting this technique and for pointing out that this has worked well for some students.)

Progress Bars and Loading Messages

If you know the percent progress, use progress bar as is shown here. Of course, the visual can be whatever you like. While the WAI-ARIA specification implies that a variety of types of values may one day work, this only works in current screen readers/browser with percent values.

If you don’t know the percent progress, and the load times are very short, one possibility is to use an alert that says “Page is loading” and then move focus to the new content when it is ready.

If you don’t know the percent progress and if the load times are longer, chose what you think is a max load time for the activity, then create a time-base version of this where the progress bar reaches 100% at that max time. This way, most of the time, the progress will be better than what the bar reports, which is fine. Have the progress bar code loop (start over at 0%, once it reaches 100%), just in case there is a very long load time.

Android Applications

The goal is to help Talkback (the Android screen reader) users know about the important information. When the application interface elements change dynamically, the contentDescription and hint property should be updated to reflect the current state of the interface element. If the dynamically-added content should be read by the screen reader, move focus to that component on the page so it will be read by Talkback.

TalkBack users MUST be notified of dynamic content changes either through spoken accessibility announcements OR focus management.

Android has different methods to speak content changes to TalkBack users including native controls that are already accessible like Toast messages. There’s an accessible announcements property similar to WAI-ARIA in HTML called android:accessibilityLiveRegion=“assertive” or “polite”. You can also speak any text strings aloud using announceForAccessibility. It’s also possible to move focus directly to the element you want spoken with AccessibilityEvent.TYPE_VIEW_FOCUSED.

iOS Applications

When the application interface elements change dynamically, the accessibilityLabel and accessibilityHint should be updated to reflect the current state of the interface element.

If the layout of the application screens change or if there is an event that happens on the screen, use the UIAccessibilityNotifications in the UIAccessibility protocol to send status notifications to VoiceOver to help users navigate the new layout.

Using UIAccessibilityAnnouncementNotification to Speak Messages


DispatchQueue.main.asyncAfter(deadline: .now() + 0.1) {
//need delay to hear announcement with voiceover
UIAccessibilityPostNotification(UIAccessibilityAnnouncementNotification,
self.errorText.text) //anounces the error message text
}

Using UIAccessibilityLayoutChangedNotification to Set Focus to Elements


UIAccessibilityPostNotification(UIAccessibilityLayoutChangedNotification,
self.errorText) // send focus to the error text

For more information, see the section in the iOS Accessibility Programming Guide called Make Dynamic Elements Accessible.

PowerPoint

PowerPoint presentations can have dynamic content in the form of slide animations. Be sure to test animations with a screen reader because a content is not always read consistently. It is best to use animations triggered by mouse clicks so that it can be controlled by the user during a slideshow. Animations triggered by mouse clicks can be controlled using both a mouse and keyboard.

Testing HTML

Testing technique	Description
Tools	First just use a browser to observe whether content is added to the page dynamically or whether user actions will trigger content to be added. For example, try opening and closing menus and try entering invalid information into form fields to see if there are error messages. If you find such added content, test the interactions with at least JAWS, and ideally with other screen readers as well.
Output	If things are going well when items are added to the page, JAWS may announce the change or the new content may appear just below the button that triggered it, so that the user experience is something like this: User presses expand button Button changes to a collapse button User presses the down arrow to read the new content Or JAWS may announce a new page if the content is not truly dynamic and appears with a page refresh. Alternatively, if things are not going well, the new information may appear visually, but its arrival may be silent in JAWS and/or it may be in an unpredictable location in the reading order.
Analysis	Will a screen reader user know when items were added or removed? Will they be able to locate the new content with no more than a reasonable amount of effort? If the answer is “no” for either question, this is an error.

Tools

First just use a browser to observe whether content is added to the page dynamically or whether user actions will trigger content to be added. For example, try opening and closing menus and try entering invalid information into form fields to see if there are error messages. If you find such added content, test the interactions with at least JAWS, and ideally with other screen readers as well.

Output

If things are going well when items are added to the page, JAWS may announce the change or the new content may appear just below the button that triggered it, so that the user experience is something like this:

User presses expand button
Button changes to a collapse button
User presses the down arrow to read the new content

Or JAWS may announce a new page if the content is not truly dynamic and appears with a page refresh. Alternatively, if things are not going well, the new information may appear visually, but its arrival may be silent in JAWS and/or it may be in an unpredictable location in the reading order.

Analysis

Will a screen reader user know when items were added or removed? Will they be able to locate the new content with no more than a reasonable amount of effort? If the answer is “no” for either question, this is an error.

Testing Mobile Applications

Testing technique	Description
Tools	Interactive with the screen and note any areas where content is added to the page dynamically or whether user actions will trigger content to be added. For example, try opening and closing menus and try entering invalid information into form fields to see if there are error messages. If you find such added content, test the interactions with the mobile screen reader http://www.freedomscientific.com/products/fs/jaws-product-page.asp (VoiceOver on iOS and TalkBack on Android).
Output	The screen reader should either: Announce the change when it appears on the screen Change occurs below the current focus point so users will get to it when they continue reading the page In both scenarios, the screen reader should be in a predictable location in the reading order.
Analysis	Will a screen reader user know when items were added or removed? Will they be able to locate the new content with no more than a reasonable amount of effort? If the answer is “no” for either question, this is an error.

Tools

Interactive with the screen and note any areas where content is added to the page dynamically or whether user actions will trigger content to be added. For example, try opening and closing menus and try entering invalid information into form fields to see if there are error messages. If you find such added content, test the interactions with the mobile screen reader http://www.freedomscientific.com/products/fs/jaws-product-page.asp (VoiceOver on iOS and TalkBack on Android).

Output

The screen reader should either:

Announce the change when it appears on the screen
Change occurs below the current focus point so users will get to it when they continue reading the page

In both scenarios, the screen reader should be in a predictable location in the reading order.

Analysis

Related Guidelines

WCAG 2.0 4.1.2 Name, Role, Value

For all user interface components (including but not limited to: form elements, links ,and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies. (Level A)

Note: This success criterion is primarily for Web authors who develop or script their own user interface components. For example, standard HTML controls already meet this success criterion when used according to specification.