Progressive functionality Must

Apps and websites must be built to work in a progressive manner that ensures a functional experience for all users.

Lower end and older mobile devices may have poor support for the latest software and hardware features, or a device may be experiencing network issues. Additionally, users may have some features disabled, including users of assistive technology and those on secured networks.

Building apps and websites in a progressive manner means dynamically changing a basic experience when new features are detected that can enhance the experience. For some content, such as video or frameworks that require Javascript, it may be necessary to provide a message explaining to the user what is required and linking to alternative content.

Jump to:

Examples

Testing

Examples

iOS

Use version or feature detection to determine whether or not to enhance a basic experience.

Android

Use version or feature detection to determine whether or not to enhance a basic experience.

HTML

Use version or feature detection to determine whether or not to enhance a basic experience. Use noscript to provide information if any content requires JavaScript to function. The basic experience should work without depending on fillers or ARIA. Check newer Javascript methods are supported, and check newer CSS rules are supported.

Testing procedures

  1. Identify content and functionality that may be dependent on JavaScript.
  2. Run the app or site on a device or mobile browser, or assistive technology that does not support JavaScript, or has Javascript disabled.
  3. Verify that content is available, or information is provided about why it isn't available.
  4. Verify that functionality is available.

Testing results

The following checks are true:

  • Content and functionality are available when run on a mobile device, browser, or a screen reader that does not have JavaScript enabled.

Controlling media Must

Media that updates or animated content must have a pause, stop or hide control.

Some users with cognitive impairments can find too much movement and change distracting and overwhelming. Users of assistive technology, such as screen readers, may not be aware of content updates and may not read the content before it changes.

This guideline applies to any content, decoration or background that moves, updates, scrolls or blinks. The user must be able to stop, hide or pause changes, or updates must stop automatically after three cycles.

An exception may be made, with sought advice, for:

  • Short adverts or idents that play before AV content,
  • Media that is playing fullscreen without other surrounding content,
  • The core content or mechanic of interactive content such as a game (though all background and non-editorially significant animation must have the option to be paused or disabled).

Examples

iOS

iOS media playback view provides these controls. All other elements providing animation subject to this requirement must provide these controls manually.

Android

Application developers must provide all playback control elements.

HTML

To provide notifications in an inclusive way, combine a visual cue with audio and haptic Provide buttons to stop, hide, or pause the content. Buttons should also be provided to step through the content, for example, next, previous, etc. or in the case of media an accessible scrub bar or rewind/fast forward.

Testing procedures

  1. Activate the app.
  2. Determine if the screen contains dynamically updating, moving, blinking scrolling content or animation.
  3. If so, determine if there are controls to stop, hide, pause, or control the content.
  4. Verify that the controls correctly control the media in the indicated fashion.
  5. Verify that these controls can be accessed via assistive technology and that the dynamic content can be controlled using assistive technology.
  6. Verify that animated content that is decorative does not last for more than five seconds.

Testing results

The following checks are true:

  • When the screen contains dynamically updating, moving, blinking scrolling content or animation, a method is available to stop, hide, pause, or control the content;
  • This method can be accessible with assistive technology;
  • Decorative content animation does not last for more than five seconds.

Page refreshes Must not

Automatic page refreshes must not be used without warning.

Assistive technology, such as a screen reader, may lose its place in the content and announce the wrong information when an entire page reloads automatically. This can be confusing and disorienting for the user.

Techniques that would trigger an entire page to be reloaded must not be used unless the user has been notified.

Jump to:

Examples

Testing

Examples

iOS

Avoid using UIAccessibilityScreenChangedNotification unless the entire screen changes (not just updates). Use UIAccessibilityLayoutChangedNotification to updated content on change. Frequently updating content should include the UIAccessibilityTraitUpdatesFrequently trait to ensure content is updated without disrupting the user.

Android

Content is announced as requested by accessibility events sent by accessibility assistant applications.

HTML

Do not use a setTimeout to update the location object's href property and do not use meta tag refreshes via the http-equiv="refresh" attribute value pair.

Allow the user to control a total page refresh.

Testing procedures

  1. Activate a screen reader.
  2. Navigate through all content.
  3. Verify that the entire screen does not refresh or update:
    • Automatically, or
    • Based on navigation.

Testing results

The following check is true:

  • Entire screen does not refresh or change automatically or when focus moves between objects, elements, or controls.

Timeouts Must

A timed response must be adjustable.

Some people may not be able to respond or interact before a time limit is reached. If a timeout is essential, allow users to extend, change or disable the time limit to ensure they can still access content, complete forms, and make choices at their own speed.

For example, as appropriate for the content:

  • Provide a means to adjust or disable a timing feature before starting an interaction,
  • Warn the user of a timeout and provide a means to extend the time.

An exception may be made, with sought advice, for real-time content and content that would be invalidated by allowing more time, such as a quiz or vote.

Jump to:

Examples

Testing

Examples

iOS

Allow at least 30-60 seconds for each field on the screen for the default timeout and display a popup allowing the user to extend the time. After the timeout time is reached a UIAlertView is displayed offering the user a chance to extend their time.

Android

Allow at least 30-60 seconds for each field on the screen for the default timeout and display a popup allowing the user to extend the time. After the timeout time is reached an AlertDialog is displayed offering the user an opportunity to extend their time. This would fail if after the timeout time is reached the form is reset or closed without any warning to the user or offer to extend the time.

HTML

The JavaScript setTimeout method to track the time can be used to manage time-outs.

Testing procedures

  1. Activate the app.
  2. Determine if the app contains a form or activity that must be completed within a given amount of time.
  3. Verify that the app allows the user to do one of the following:
    • disable the timeout before it occurs,
    • extend the length of the current session,
    • increase the time limit.
  4. Verify that the user is warned at least 20 seconds prior to the timeout.
  5. Verify that the user is warned if any data entered during the session will be deleted upon session timeout.
  6. Verify that the user can renew or extend the session using an alternative input method.

Testing results

The following checks are true:

  • When a form or activity has a time limit:
    • The timeout can be disabled by the user;
    • A mechanism exists whereby the user can request more time to complete the form/activity;
    • The user can modify the session to extend the amount of time before timeout.

Input control Should

Interaction input control should be adaptable.

People with motor or other physical impairments may need to adapt the input control for interactive content, to best accommodate their abilities. For example, someone who is left-handed may prefer to use a pattern of control keys on the left of the keyboard that are within closer reach; and someone with developing or impaired fine motor skills would benefit from simpler controls that allow for less precise gestures.

Adaption could be through user settings or automatic detection. Things to consider for adaption include:

  • The mapping of control keys,
  • The complexity of controls (such as offering both multi-button and one-button control modes),
  • The sensitivity and pace of reaction to input signals, and
  • The quantity, size and distance between targets or paths.

Examples

iOS

Options offered will depend on the complexity of the interaction and input required.

Android

Options offered will depend on the complexity of the interaction and input required.

HTML

Options offered will depend on the complexity of the interaction and input required.

Testing procedures

  1. Identify interactive content.
  2. If the default interaction is a single action control, verify it works with mouse, touch, and keypress actions.
  3. If the default interaction has complex controls, determine if a mode with simpler controls is offered.
  4. Determine if there is a mode to adjust the interaction pace or difficulty.

Testing results

The following checks are true:

  • The user can control interaction with their choice of input device;
  • The user can adapt the input control.