• Media Type Web > ARIA and Dynamic Content
  • State Active
  • Advisory No

When content is inserted, made visible, or made invisible on a page via scripting after the page loads, users of assistive technologies such as people who are blind or low vision who use screen readers may not be aware that a change in the page occurred. Developers must use certain methods to alert assistive technologies that content has changed through JavaScript. When these methods are not used, users of assistive technology such as screen readers may have an outdated/stale view of page content.

Compliant Example

/* This compliant example demonstrates how to use a non-user facing hidden input field to
alert screen readers to update the view of the entire page's content.  This specific
method need only be used when the screen reader is not able to detect the method of
updating content being used.  Typically changing the innerHTML textContent, or innerText
properties should be sufficient and use of the extra input field should not be required
*/
... 
<script type="text/javascript"> 
var xmlHttp
... 

function updateContent(str) // called by onKeyUp
{
  ...
  xmlHttp=GetXmlHttpObject();  // function not shown
  ...
  xmlHttp.onreadystatechange=stateChanged;
  xmlHttp.open("GET",url+"?param="+str,true);  // url is   defined in
code not shown
  xmlHttp.send(null);
} 

function stateChanged() 
{ 
  if(xmlHttp.readyState==4) 
  { 
    document.getElementById("txtToUpdate").innerHTML=xmlHttp.responseText;
    updateForScreenReaders();
  } 
}

function updateForScreenReaders()
{
  var d = new Date();
  document.getElementById('specialElement').setAttribute('value',d.getTime());
}

function init()
{
  var objNewDiv = document.createElement('div');
  var objSpecial = document.createElement('input');
  var d = new Date();

  objSpecial.setAttribute('type', 'hidden');
  objSpecial.setAttribute('value', d.getTime());
  objSpecial.setAttribute('id', 'specialElement');
  objSpecial.setAttribute('name', 'specialElement');

  objNewDiv.appendChild(objSpecial);
  document.body.appendChild(objNewDiv);
}
... 
</script> 
... 
<body onload="init();" ... >
<form> 
 <p>Enter text in the search field and results will be  displayed incrementally
below the search text field<p> 
 <label for="textSearch">Incremental Search:</label> 
 <input type="text" id="txtSearch" 
onkeyup="updateContent(this.value)"> 
</form> 
<p>Results: 
 <span tabIndex=0 accessKey="s"
id="txtToUpdate"></span></p> 

Non-Compliant Example

/* this non-compliant example is for legacy browser and AT combinations such as IE 7 and
JAWS 11 */
... 
<script type="text/javascript"> 
var xmlHttp
... 

function updateContent(str) // called by onKeyUp
{
...
xmlHttp=GetXmlHttpObject();  // function not shown
...
xmlHttp.onreadystatechange=stateChanged;
xmlHttp.open("GET",url+"?param="+str,true);  // url is defined in code
not shown
xmlHttp.send(null);
} 

function stateChanged() 
{ 
  if(xmlHttp.readyState==4) 
  { 
    document.getElementById("txtToUpdate").innerHTML=xmlHttp.responseText;
  } 
}

... 
</script> 
... 
<form> 
<p>Enter text in the search field and results will be displayed incrementally below
the search text field<p> 
<label for="textSearch">Incremental Search:</label> 
<input type="text" id="txtSearch" 
onkeyup="updateContent(this.value)"> 
</form> 
<p>Results: 
<span tabIndex=0 accessKey="s"
id="txtToUpdate"></span></p> 

Developers need to alert screen readers of changes in content. This is typically accomplished by changing the attributes such as innerHTML (IE only), innerText (IE only), value (when set by setAttribute on form fields), textContent, other style property changes such as visibility and display, and class name changes, which will cause screen readers to detect and refresh their custom view of the page and content. Testing should be performed with commonly used assistive technology such as screen readers to verify the updated content is seen when changed. If the updated content is not detected, developers should create a non-user facing hidden form field and change its value after dynamic content has changed to force the assistive technology to update its view of the page content. This process is described in the above compliant code example. In addition, if page content is set to be hidden or appear immediately after page without user interaction it is best to render that content in its final state before the page finishes loading. If this is not possible, developers should use the techniques above to cause the screen reader to update its view of the page via updating a form field property or a class name.

Organization Standards

  • § 508-1194.22 Web Sites and Applications
    • (l) Ensure scripts are accessible
  • Section 508 and 255 (Revised 2017)
    • Chapter 3: Functional Performance Criteria
      • 302.2 With Limited Vision
      • 302.1 Without Vision
  • WCAG 2.0 Level A
    • 4.1.2 Name, Role, Value
  • WCAG 2.1 Level A
    • 4.1.2 Name, Role, Value

Other Mapped Standards

  • § 508-1194.21 Software Applications and Operating Systems
    • (b) Applications shall not disrupt or disable accessibility features
    • (c) On-screen & programmatic indication of focus
  • § 508-1194.22 VA Testing Checklist - Web Sites and Applications
    • (l) When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology.
      • (l.3) Is all content information of the scripted element available to a user of assistive technology?
        • (l.3.a) Can assistive technology detect change in content?
  • § 508-1194.31 VA Testing Checklist - Web Functional performance criteria
    • (a) At least one mode of operation and information retrieval that does not require user vision shall be provided, or support for assistive technology used by people who are blind or visually impaired shall be provided.
      • (a.17) Is each element or interactive component on a page read only once by AT?
  • § 508-1194.31 Functional performance criteria
    • (a) Ensure access for blind and visually impaired
    • (b) Ensure access for low vision users
  • 47 CFR 14. Advanced Communication Services
    • 47 CFR 14.21 Performance Objectives
      • (b) Accessible
        • (b)(2) All information necessary to operate and use the product
          • (b)(2)(i) Availability of visual information
  • BITV 2.0 (Priority I)
    • 4.1.2 Name, Rolle, Wert
  • EN 301 549 v3.2.1 [beta]
    • Chapter 9: Web
      • 9.4 Robust
        • 9.4.1 Compatible
          • 9.4.1.2 Name, role, value 
  • HHS HTML 508 Checklist (Pre 2019)
    • HHS Web 508 Checklist (p)
      • (16.2) Is the functionality of the content predictable, i.e. will a user experience contextual changes when unbeknownst to them?
  • JIS X 8341-3: 2004 - Technical Standards Subpart 5
    • 5.1 (b) Accessible object and such technology should be used in Web content.
  • KWCAG
    • 4-1 - Ensure plug-ins are directly accessible
      • 4-1-1 - Ensure that the embedded content itself is accessible
  • NFB Certification
    • Client Side Content Changes
  • Telecommunications Act Accessibility Guidelines
    • 1193.43 Output, display, and control functions.
      • (a) Availability of visual information. Provide visual information through at least one mode in auditory form.
  • WCAG 1.0 Priority 1
    • 08.1 Ensure programmatic elements such as scripts and applets are accessible
  • WCAG 1.0 Priority 2
    • 06.5 Ensure dynamic content is accessible.
  • WCAG 2.2 Level A
    • 4.1.2 Name, Role, Value
  • Severity

    9 (red)
    in range of 1 to 10
  • Noticeability

    8 ()
    in range of 1 to 10
  • Tractability

    8 ()
    in range of 1 to 10