Skip to main content Skip to Table of Contents
U.S. flag

An official website of the United States government

Section 508 ICT Testing Baseline

5. Changing Content

Accessibility Requirements

  • WCAG2 SC 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.

Test Method Rationale

The purpose of this Baseline test is to identify visual changes to content and component states that occur without a page refresh and to correlate those changes with equivalent programmatic and/or textual information. Notification of such changes must be provided.

  • Content changes could include component state changes (e.g., closed/open sections, sort order, collapsed/expanded menus), dynamic and/or calculated values (e.g., “34 characters remaining”), and automatically updating content (e.g., stock prices).
  • Content that changes in the course of a user’s interaction with the content (including, but not limited to changes in text, component states, structure, relationships, or functionality) must provide a means by which the change in content is programmatically determinable or is otherwise available in text.

Limitations, Assumptions, or Exceptions

  • The state of form elements (checked, unchecked, etc.) are included in this Baseline.
  • User initiated changes and automatic updates are included in this test.
  • If an ARIA live region is used to provide programmatic notification of changes in content, a value of "off" for an aria-live attribute is NOT sufficient to provide programmatic notification (whether implicitly or explicitly defined).

5.1 Test Procedure for Changes in Content

Baseline Test ID: 5.1-ChangeContent

Identify Content

  1. Identify changes in presented content (both user driven and automatic). Examples include changes to images, navigation trees, data table sort controls, automatic information updates, form elements, revealed content, etc.
    • It may be necessary to use the mouse to determine whether state changes occur on hover or on click.
    • Depending on the component, a change of state may be triggered by various actions, such as changing values or states of other components, toggling a function, entering data in the component, mouseover, etc.

Test Instructions

  1. Check that the page provides a notification of the change in content programmatically. [SC 4.1.2]
    • Programmatic event notifications include alert dialogs, focus shifts to the content that changed, and ARIA live regions.
  2. For each change in content, check that the combination of name, role, state, and value of the changed content is accurate. [SC 4.1.2]
    1. Name: the name is accurate after a change.
    2. Role: the role accurately describes the purpose of the element after a change, if applicable.
      • Consider ARIA role, element type, and other descriptive text.
    3. State: the state of the element is accurate after a change, if applicable.
      • Evaluate ARIA and element-specific attributes (e.g., <option selected=”true”>).
    4. Value: the value is updated after a change, if applicable.

Test Results

If any of the above checks fail, then Baseline Test 5.1-ChangeContent fails.

Advisory: Tips for streamlined test processes

  • Changing content might also include changes in color to convey information. If so, this test should check that the information is programmatically determinable. If color is used as the only visual means of conveying information (or changes in information), then the content would fail to meet SC 1.4.1 Use of Color (addressed in Baseline 7. Sensory Characteristics.
  • The number of event notifications can be very large; if the number of changes to an element is unknown or very large, a sampling approach may be necessary.
  • Although an ARIA live region with an aria-live attribute set to "off" is not sufficient to provide programmatic notification of content changes, a web page may provide the user with an option to change the value of the aria-live politeness setting to provide desired level of notification. Such an option must meet all of the requirements defined in 20. Conforming Alternate Version in order to be considered a “conforming alternate version”. It would be helpful to provide instructions for the tester to change the aria-live from “off” before testing the page.

Contact the ICT Baseline Working Group


Related Projects

The Baseline Alignment for Web is being developed to aid in determining if a test process aligns with the ICT Baseline for Web.