Note

This archival content is maintained by WebAIM and NCDAE on behalf of TEITAC and the U.S. Access Board . Additional and up-to-date details on the updates to section 508 and section 255 can be found at the Access Board web site.

Web and Software: Requirements by content type

Contents

Requirements by content type

The following Section 508 provisions are grouped together for discussion purposes and address different types of content. The TEITAC Web and Software subcommittee is reviewing these for issues, gaps, and keeping in mind the themes.

Discussion of these provisions should take place on the mailing list. Be sure to include an appropriate subject line that begins with "Group B". Rewording proposals may be made by editing this page:

Alternatives

21(e)

Current wording: When bitmap images are used to identify controls, status indicators, or other programmatic elements, the meaning assigned to those images shall be consistent throughout an application's performance.

Summary of discussion on 21(e)
  • ISO: no equivalent requirements in 9241-171. There are two recommendations:
    • 8.5.9 Present user notification using consistent presentation techniques. Alerts, warnings, and other user notification should be presented by software using consistent presentation techniques that enable a user to locate them and identify the category of the information (e.g., alerts versus error messages).
    • 8.2.7 Provide text label display option for icons. Every icon provided by software should have an associated text label and the user should be given the option of choosing between displaying only the icon image, the icon image with the text label or only the icon text label.
  • No mailing list discussion on this provision.
    • Is this needed for AT interoperability or cognitive disabiliites?
    • Is this testable?
    • Are there any issues with the current wording?
  • Discussed at the November 22, 2006 meeting.

22(a)

Current wording: A text equivalent for every non-text element shall be provided (e.g., via "alt", "longdesc", or in element content).

Summary of discussion on 22(a)

22(b)

Current wording: Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation.

  • Discussed at the November 15, 2006 meeting. Defer this to the Audio Video Subcommittee.

22(e) and 22(f)

Current wording: (e) Redundant text links shall be provided for each active region of a server-side image map. (f) Client-side image maps shall be provided instead of server-side image maps except where the regions cannot be defined with an available geometric shape.

Summary of discussion on 22(e) and 22(f)
  • WCAG 2.0: Since these are technology-specific, there is no direct equivalent in WCAG 2.0. WCAG 2.0 does, however, have a requirement that all content be keyboard operable. The purpose of 22(e) is to make the server side image map keyboard operable but there are other techniques that could be used to achieve this outcome.
  • Since a polygon can have an infinite number of sides, there is no shape for which a server side image map is allowed by 22(f) even though the code to manage complex shapes as a client side image map becomes burdensome.
  • Image maps are a problem for screen magnifier users due to pixelation and lack of ability to adjust colors and contast.
  • Proposal: Combine 22(e) and 22(f) into one provision
    • Option 1: Client-side image maps shall be provided instead of server-side image maps.
    • Option 2: Server-side image maps which use the <ismap> tag method are prohibited.
  • Proposal: Option 3: Remove 22(e) and 22(f) and add a provision on keyboard operability as in WCAG 2.0.
  • Discussed at the November 22, 2006 meeting.

22(k)

Current wording: A text-only page, with equivalent information or functionality, shall be provided to make a web site comply with the provisions of this part, when compliance cannot be accomplished in any other way. The content of the text-only page shall be updated whenever the primary page changes.

Summary of discussion on 22(k)
  • The WCAG 2.0 last call draft contains a requirement for this that is less stringent than 508. Allows for an accessible alternative but it doesn't have to be "text only". But this is being moved out of the standards as it is really a conformance issue.
  • Do we even need this as long as we have "equivalent facilitation" as a general provision in 508? Requirew anyone claiming this provision to document the logical rationale for following this path, when in fact, they could just indicate they meet the other provisions by equivalent facilitation.
  • Even though the requirement is "text only", most interpret this to mean accessible HTML. Otherwise, you wouldn't even be able to have navigation links. As a last case scenario to provide an equivalent alternative and to do this using proven accessible technologies seems more useful and helpful.
  • Proposal: Alternate versions of pages which comply with these provisions with equivalent information and functionality shall be provided when compliance cannot be accomplished in any other way. The content of the alterative pages shall be updated whenever the primary pages change and available with the same ease as the primary pages.
  • Scanned documents (TIFF and PDF files) are a particular problem area especially for medical records.
  • Discussed at the November 22, 2006 meeting.

Moving Content

21(h)

Current wording: When animation is displayed, the information shall be displayable in at least one non-animated presentation mode at the option of the user.

Summary of discussion on 21(h)
  • ISO: Provide non-animated alternatives to animations. When animation is displayed that will last for more than three seconds, and the user is expected to carry out other activities at the same time, software shall give the user the option to choose an alternative non-animated version of the same content. If the animation is not task relevant then a version where the non-task-relevant item is missing would conform.
  • ISO is less restrictive - only requires a non-animated version if the animation lasts for more than 3 seconds. ISO also only requires the non-animated version if the user is expected to carry out other tasks at the same time.
  • The ISO provision is a concern for some because it does not cover the case where the animation is the sole task.
  • Are animations that show progress expected to comply with this provision?
    • Requiring progress indicators to stop after 3 seconds seems to defeat their purpose.
    • Progress indicators that simply show progress are not a problem but those that show an animation are distracting to those with cognitive disabilities. These need to have a way to be turned off.
    • HFES 200 is including the following note and is proposing it to ISO: "A simple progress indicator that has no movement other than to indicate current completion status is not considered animation."
  • Should we make a distinction between informational and decorative animations?
  • The ISO provision also includes this clause: "If the animation is not task relevant then a version where the non-task-relevant item is missing would conform." This addresses decorative animations and might also be beneficial to users with cognitive disabilities. If you have an animation going on that is not relevant to your task, it is distracting. And if it's not relevant, why require a non-animated version of it? Offering up a way way to remove it altogether seems like a viable option for accessibility in some contexts and may help those with cognitive disabilities.
  • Need to define what an "animation" is versus "updated content"
  • Discussed at the November 22, 2006 meeting.
Proposal for change to 21(h)
  • Proposal: When an informational animation is displayed that will last for more than three seconds, software shall give the user a means to pause and restart the animation. When a decorative animation is displayed that will last for more than three seconds, software shall give the user a means to stop the animation or remove it entirely.
  • Discussed at the January 17, 2007 meeting

21(k) and 22(j)

Current wording: 21(k) Software shall not use flashing or blinking text, objects, or other elements having a flash or blink frequency greater than 2 Hz and lower than 55 Hz. 22(j) Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz.

Summary of discussion on 21(k) and 22(j)
  • ISO provision does not specify the rate but refers to international and national standards
  • WCAG 2.0 defines two standards, general flash threshold and red flash threshold, as the rates to avoid.
  • Discussed at the November 22, 2006 meeting.
Proposals for 21(k) and 22(j) and summary of discussion
  • Proposal for 21(k): When software has flashing or blinking elements that occupy more than one quarter of any 341 x 256 pixel rectangle anywhere on the displayed screen area when viewed at 1024 x 768 pixels, the flashing or blinking elements shall not have a flash or blink frequency greater than 2 Hz and lower than 55 Hz.
  • Proposal for 22(j): When software has flashing or blinking elements that occupy more than one quarter of any 341 x 256 pixel rectangle anywhere on the displayed screen area when viewed at 1024 x 768 pixels, the flashing or blinking elements shall not have a flash or blink frequency greater than 2 Hz and lower than 55 Hz.
  • Needs to be more general. Seems too specific to one screen resolution.
  • Upper bound should be 50 Hz, not 55 Hz. Gregg thinks this is a typo in the current 508 standard.
  • Summary of the research behind the WCAG 2.0 specification provided by Gregg.
  • Discussed at the January 17, 2007 meeting.

Color

21(i) and 22(c)

Current wording: 21(i) Color coding shall not be used as the only means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. 22(c) Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup.

Summary of discussion on 21(j) and 22(c)
  • ISO requires this only for conveying information and indicating an action. So 508 is more comprehensive.
  • WCAG 2.0 is currently more restrictive than 22(c): "Any information that is conveyed by color is also visually evident without color." (Web Content Accessibility Guidelines 2.0, http://www.w3.org/TR/2006/WD-WCAG20-20060427/, 27 April 2006, W3C Working Draft. Latest version at http://www.w3.org/TR/WCAG20/)
  • Discussed at the November 22, 2006 meeting.

Timed Responses

22(p)

Current wording: When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required.

Summary of discussion on 22(p)
  • Not testable - What is "sufficient" time?
  • WCAG 2.0 provides several testable strategies for addressing time limits in 2.2.1 and two exceptions for time limits that are allowed:
    • Timing: For each time limit that is a function of the content set by the content , at least one of the following is true:
      • Deactivate: the user is allowed to deactivate the time limit; or
      • Adjust: the user is allowed to adjust the time limit over a wide range that is at least ten times the length of the default setting; or
      • 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
      • Real-time Exception: the time limit is an important part of a real-time event (for example, an auction), and no alternative to the time limit is possible; or
      • Essential Exception: the time limit is part of an activity where timing is essential (for example, competitive gaming or time-based testing) and time limits can not be extended further without invalidating the activity.
    • (Web Content Accessibility Guidelines 2.0, http://www.w3.org/TR/2006/WD-WCAG20-20060427/, 27 April 2006, W3C Working Draft. Latest version at http://www.w3.org/TR/WCAG20/)
  • Discussed at the November 22, 2006 meeting.

WebAIM is an initiative of:
Center for Persons with Disabilities (CPD) Utah State University