Dynamic content: accessibility for developers

  • Author: Access iQ ®
  • Date: 1 Feb 2013
  • Access: Premium

Quick facts

The challenge for developers is making dynamic changes available to users with assistive technologies, without stealing focus or disrupting the user. The only way to ensure this is to test every interaction from the perspective of a person with a disability.

  • Make autocomplete text accessible
  • Test every interaction from the perspective of a person with a disability

Web standards outline the separation of structure from presentation and functionality. These are broadly split between HTML, CSS and JavaScript:

  • HTML provides the semantic structure for the document.
  • CSS takes care of the presentation of the content, the colours, layout, sizes and backgrounds.
  • JavaScript is commonly used to manage functionality and manipulation of the Document Object Model (DOM), previously referred to as Dynamic HTML (DHTML).

Dynamic content can be described as content that changes in the webpage without requiring a request for a complete refresh or a new URL.

A common method for creating dynamic content is to use JavaScript to manipulate the DOM to either change what is displayed on the page or to call the server and update portions of the page with something new, and not disrupting the other parts of the page.

The main problem with dynamic activity on a webpage for people with disabilities is that dynamic changes are usually visual, and therefore not available to users who cannot perceive it. This is a major problem when creating dynamic content because users who can see the changes happening have no problem shifting their focus between what they are doing and what is changing. People who are blind or vision impaired, however, may not be able to notice the changes since their experience of web content is linear. Therefore, if the changes happened higher up the page, they won't know it since they passed it. Equally, if changes happen below the page, they have not reached it yet so are unaware of the previous state it changed from.

The challenge for developers is making dynamic changes available to users with assistive technologies, without stealing focus or disrupting the user. The only way to ensure this is to test every interaction from the perspective of a person with a disability.

Making autocomplete text accessible

Google search has a well-known feature that starts to provide possible solutions to typed inputs.

Google search box showing predictive solutions to typed inputs.

The problem for people with disabilities is that they may not be aware of these hints being delivered to the user, and it may be confusing and distracting for screen reader users to hear what is being offered as they type.

In addition, Google changes the page results as you continue typing, which continues the breach of Success Criterion 3.2.2 On input that states:

Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behaviour before using the component. (Level A)

The solution to this is to create an autocomplete that works the same as a select form element, where the keyboard allows a user to navigate through the options and the Enter/Return key commits the selection.

An example of this solution is the search box at http://certifiedtorock.com/

For autocomplete:

  • Determine if a select element might be a better fit.
  • Label the area preceding the autocomplete.
  • Consider adding the WAI-ARIA property aria-autocomplete to the textbox.

Changing the content on a webpage

One example of dynamic content that will have an impact on people with disabilities is a form that modifies what is displayed based on what has been previously entered. For instance, a form that asks for an address but start with the country field in order to format the rest of the address accordingly. Selecting "Australia" from a dropdown list might change the form fields to be more specific for this country. It may use the label  "Postcode" instead of the American "Zip code". The form may error-check for four numbers as opposed to the six characters of a UK postcode.

The important points to remember in this situation is to preserve the focus as described in Success Criterion 3.2.1 On focus so that when a user activates the country selector, they are offered a "set" button to set the country and initiate the change. The user's focus should not be moved away from this field so they can continue with the rest of the form uninterrupted.

If you need to change content:

  • Ensure changes do not occur to preceding elements.
  • Test to ensure that changed items can receive sequential focus.
  • Verify screen readers can access the changed elements.

Form validation

A simple example is a dynamic form validation checking the user's entries against known conditions without waiting to submit the completed form beforehand.

If a user is inputting an email address, it is possible to check that it is formatted as required, with something@somewhere.tld, for example. We won't go into the logic to find the patterns to validate the input here, just recognise that the aim is to indicate success or fail for the input field based on pattern matching.

In Example 1 below, the developer has decided to use tabindex="-1" when the form element was adequately filled in to speed up the process. You may decide otherwise based on research or feedback.

Example 1:

The form as shown on the left will move focus to the error message when the user uses the Tab key to navigate through the form. They will hear "Alert. Oops! Are you sure that's your email address?" and will have the opportunity to Shift+Tab to go back to the input field, hear what they typed and correct it. With the tabindex=”0” setting, even items not normally tab-navigable become an element that can receive focus.

A screenshot of a form with an error message to the right of a form field.

A screenshot of a form with a message confirming a field has been completed correctly to the right of a form field.

<form action="" name="registration">

      <label for="firstname">Name

      <span class="required">(required)</span></label><br />

      <input type="text" name="fname" id="firstname" /><br />

      <label for="lastname">Name

      <span class="required">(required)</span></label><br />

      <input type="text" name="lname" id="lastname" /><br />

      <label for="email-address">Email address

      <span class="required">(required)</span></label><br />

      <input type="text" name="email-address" id="email-address" />

<span class="form-error-bad error-show" id="email-validate-msg1' tabindex="0"><img src="" alt="" /> Oops! Are you sure that’s your email address?</span>

<span class="form-error-good errorhide" id="email-validate-msg2" tabindex="-1"><img src="" alt="" /> Excellent! That looks like an email address!</span>

<br />

      <input type="submit" value="Submit" />


One element of this solution is to use tabindex with the document order to ensure the flow is uninterrupted for the user.

This method uses JavaScript (not shown here) to assess the input against a desired pattern and manipulate the span and class so it shows the appropriate message and hides the others. The tabindex of the span is manipulated so that it includes the message in the tab order and the class is swapped between the hidden and not hidden classes.

There are other ways to change this, for example, by adding an inline style like: style="visibility:hidden; display:none;" to hide the span and removing it to unhide it. This JavaScript/CSS method would need to be tested with the browsers and screen readers you want the form to work with.


WAI-ARIA (Accessible Rich Internet Applications or ARIA) is a W3C protocol for enhancing and supporting the accessibility of scripted and dynamic content. One condition ARIA can help with is allowing dynamically updated content to be understood by screen readers. These dynamically updated areas are called "live regions" and are labelled with one of four values depending on the level of intrusiveness desired for announcing the updating content.

The values are:

  • aria-live="off" means the screen reader will ignore the updates.
  • aria-live="polite" means the screen reader will wait for the user to complete what they are doing, then notify them of the change with a simple sound like a beep, then the user can jump straight to the change. This is the most common setting.
  • aria-live="assertive" means the screen reader will alert the user immediately or as soon as possible. This is good for errors and other important information.

ARIA can help with other situations where content is changed without refreshing the page, as well as to help set navigation landmarks and keyboard accessibility.

These are only examples of what can be achieved to minimise or remove accessibility from dynamic content in some conditions. There are many different examples of dynamic content — you are welcome to contribute examples, which may influence further versions of this guide.