User Interface and Electronic Content Provisions

Andi Snow-Weaver
January 7-8, 2008

3.I Pausing

• [criteria]
  • A mechanism must be provided to pause moving, blinking, or scrolling information that lasts for more than three seconds unless it is part of an activity where the moving, blinking, or scrolling is essential.
  • A mechanism must be provided to pause auto-updating information, or allow the user to control the frequency of the update, unless it is part of an activity where auto-updating is essential.
  • A mechanism must be provided to either pause, stop, or hide moving or blinking content that is pure decoration.
• Issues:
  • “auto-updating” not well understood by lay audience
  • Major impact – need rationale
• Proposal:
  • Refer to WCAG 2.0 information
  • Add to rationale: Needed for people with attention deficit disorders and those using screen readers.

3.K Consistent Identification

• Components that have the same functionality within a product must be identified consistently.
• Issues
  • Should be advisory, not mandatory.  May not be possible to achieve in portals where content comes from multiple vendors.

3.L Audio Turnoff

• When any audio plays automatically for more than 3 seconds, there must be a mechanism to pause or stop the audio, or a mechanism to control audio volume which can be set independently of the system volume.
• Issues:
  • Scope to Web pages only
    • When any audio plays on a web site automatically for more than 3 seconds, there must be a mechanism to pause or stop the audio, or a mechanism to control audio volume which can be set independently of the system volume. Use of a web browser with the ability to turn off audio is sufficient to meet this provision.
  • Move to advisory
  • May not be appropriate for closed products Additional text proposed for harmonization with 255:
    • when a product delivers audio output through an external speaker, provide an industry standard for headphones or personal listening devices (e.g., phone-like handset or earcup which cuts off the speaker(s) when used.
• Rationale:
  • Audio that plays automatically interferes with screen readers.  When Web browsers provide mechanisms to turn off audio in the content, the content author doesn’t have to provide a mechanism.  Turning off audio at the system level is not sufficient as that turns off the screen reader audio too.

3.M Reading Sequence

• When the sequence in which information is presented affects its meaning, a correct reading sequence must be programmatically determinable.  The navigation sequence must be consistent with the reading sequence.
  • Note 1: In order to achieve this provision, objects in data operated on by the software which can be presented in 2 dimensions, would need to be associated with sufficient information to identify a logical one dimensional presentation of the same objects, that the software can obtain as readily as it can obtain the 2 dimensional objects themselves.
  • Note 2: For products with closed functionality the visual and (linear) audible presentation should match navigation
• Issues:
  • “Correct reading sequence” is unclear. Previous wording “logical linear reading order” was clearer.
  • Note: this was harmonized with WCAG 2.0.  Current WCAG 2.0 draft has removed the sentence on navigation sequence as it is addressed in another provision (Focus Order) which is not in the current TEITAC draft.
    • If a Web page can be navigated sequentially, focusable components receive focus in an order that follows information and relationships conveyed through presentation.
• Proposal:
  • When the sequence in which information is presented affects its meaning, a correct linear reading sequence must be programmatically determinable.

3.N Link Purpose

• On Web pages, it must be possible to determine the purpose of each link from the link text or the link text together with its programmatically determined link context.
  • Note: In order to achieve this provision, links encoded in data operated on by the software would need to be associated with link text that the software can obtain as readily as it can obtain the link itself.
• Issues:
  • “purpose” may be different for different users
• Proposal:
  • Use current WCAG 2.0 wording:
    • On Web pages, it must be possible to determine the purpose of each link from the link text alone, or from the link text together with its programmatically determinable link context, except where the purpose of the link would be ambiguous to users in general.

3.Q Disruption of Accessibility Features

• Applications must not, except by specific user request, disrupt the features of the platform that have an accessibility usage defined in the platform developer documentation.
• Issues
  • Seems to be missing the concept of not interfering with AT
  • Developers will get around this by not defining an accessibility usage
  • Need to clarify the meaning of platform developer documentation
• Proposal:
  • Applications must not, except by specific user request, disrupt the features of the platform that are defined, in the documentation intended for platform developers, as having an accessibility usage.

3.Q Disruption of Accessibility Features

• Applications must not, except by specific user request, disrupt the features of the platform that have an accessibility usage defined in the platform developer documentation.
• Issues
  • Seems to be missing the concept of not interfering with AT
  • Developers will get around this by not defining an accessibility usage
  • Need to clarify the meaning of platform developer documentation
• Proposal:
  • Applications must not, except by specific user request, disrupt the features of the platform that are defined, in the documentation intended for application developers, as having an accessibility usage.

3.R Timing

• For each time limit that is set by the product or content, at least one of the following must happen:
  1. Turn off: the user is allowed to turn off the time limit before encountering it; or
  2. Adjust: the user is allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or
  3. Extend: the user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (for example, "hit any key"), and the user is allowed to extend the time limit at least ten times; or
  4. Real-time Exception: the time limit is a required part of a real-time event (for example, an auction), and no alternative to the time limit is possible; or
  5. Essential Exception: the time limit is part of an activity where timing is essential and time limits can not be extended further without invalidating the activity.
• Issues:
  • Add another exception “Inconsequential Impact Exception: the impact of the user failing to react within the time limit is inconsequential – no data, state, or opportunity is lost.”
  • Delete real-time exception as it is a special case of the essential exception
  • ITAA suggests that the NIST security imperative is a better example of an essential exception than the one provided – OBE – there are no longer any examples in the essential exception
• Proposal:
  • Modify beginning of the provision to “For each time limit that is set by the product or content and that impacts the user’s work, …”