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: Reorganized Web and Software provisions 2

Contents

User Interface and Electronic Content Provisions

  • WhitneyQ comment: We need to normalize the wording of these provisions to use the 508 style (using "must" not "shall", and not the checklist style).

These provisions apply to all electronic user interfaces and content.

3-A Color

Color must not be used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. For example, mandatory form fields are identified with red text and labeled as "mandatory".

  • Color Harmonization Analysis
  • Additional information on Color
  • Assessment of change in economic impact
    • Minimal
    • Currently the Section 508 software provision on color is equivalent to this one so no impact for software. The Web provision allows for the color to be programmatically determinable so there is a slight impact there.
    • Beneficial for people who are color blind which is a large portion of the population.

3-B Contrast

Presentation of text (and images of text) in electronic documents must have a default contrast ratio of at least 5:1, except if the text is unavailable items or pure decoration. Large-scale text (or images of large-scale text) can allow a contrast ratio of at least 3:1.

3-C Size, shape, location

Instructions provided for understanding information and operating user interfaces must not rely on shape, size, visual location, or orientation of components.

  • Note: Object information provided per the "Information and Relationships", "User Interface Components", or "AT interoperability" provision that describes the necessary visual cues or relationships is sufficient.
  • Note: This applies to onscreen information only.

3-D User Preferences

Applications must provide a mode that utilizes platform settings for color, contrast, font type, font size, and focus cursor. In the absence of platform settings for color and contrast, all text (and images of text) must have a contrast ratio of at least 5:1 except for unavailable items or pure decoration. Large scale text (or images of large scale text) must allow a contrast ratio of at least 3:1.

  • Note: Application software that is also a platform would need to expose the underlying platform's color, contrast, and other individual display settings to applications running within its platform, so that those applications can meet the User Preferences provision.

3-E Color adjustment

When a product permits a user to adjust color and contrast settings, at least one color selection capable of producing a minimum luminosity contrast ratio of 7:1 must be provided.

editorial suggestion: When a user interface permits a user to adjust color and contrast settings, at least one color selection capable of producing a minimum luminosity contrast ratio of 7:1 must be provided.

3-F Non-text Objects

Non-text Objects: All non-text objects that are presented to the user must have a text alternative that presents equivalent information, except for the situations listed below.

  • Controls-Input: If a non-text object is a control or accepts user input, then it must have a name that describes its purpose. (See also User Interface Components provisions)
  • Media: If a non-text object is synchronized media, live audio-only or live video-only content, then text alternatives at least identify the non-text object with a descriptive text label. (For synchronized media, see also Audio and/or Video provisions)
  • Test: If a non-text object is a test or exercise that must be presented in non-text format, then text alternatives at least identify the non-text object with a descriptive text label. (For synchronized media, see also Audio and/or Video provisions)
  • Sensory: If a non-text object is primarily intended to create a specific sensory experience, then text alternatives at least identify the non-text object with a descriptive text label. (For synchronized media, see also Audio and/or Video provisions)
  • CAPTCHA: If the purpose of a non-text object is to confirm that content is being accessed by a person rather than a computer then text alternatives that identify and describe the purpose of the non-text object must be provided and alternative forms in different modalities must be provided to accommodate different disabilities.
  • Decoration, Formatting, Invisible Objects: If a non-text object is pure decoration, or used only for visual formatting, or if it is not presented to users, then it is implemented such that it can be ignored by assistive technology.
  • Note: In order to achieve this provision, non-text objects in data operated on by the software would need to be associated with textual equivalents that the software can obtain as readily as it can obtain the non-text object itself. Where a non-text object is a scanned image of text, textual equivalents would need to allow for the inclusion of the text of the scanned image of text. Where a non-text object is a dynamic presentation, graphs, or other derived information from a data source, textual equivalents would need to allow for the inclusion of the data used.

3-G Human Language

When presentation of electronic documents supports it, the default human language of electronic documents can be programmatically determined.

  • Note: In order to achieve this provision, text encoded in data operated on by the software would need to be associated with sufficient information to identify both the primary language of the text, and the language of any sections of the text that are in another language from the primary language, that the software can obtain as readily as it can obtain the text itself.

3-H Language of Parts

When presentation of electronic documents supports it, the human language of each passage or phrase in electronic documents can be programmatically determined.

3-I Pausing

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 the auto-updating is part of an activity where it is essential.

A mechanism must be provided to either pause, stop, or hide moving or blinking content that is pure decoration.

3-J Flashing

Content and applications must not contain anything that flashes more than 3 times in any one second period or the flashing is below the general flash and red flash thresholds.

editorial suggestion: Content and user interfaces must not contain anything that flashes more than 3 times in any one second period or the flashing is below the general flash and red flash thresholds.

3-K Consistent identification

Components that have the same functionality within a product must be identified consistently.

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.

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: 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.

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.

3-O Information and relationships 

*** There is an outstanding issue on the meaning of programmatically determinable with regard to
    actual AT interoperability. This issue is related to the issues around the functional 
    performance criteria.

Information and relationships conveyed through presentation must be programmatically determinable or are available in text, and notification of changes to these is available to user agents, including assistive technologies. For example:

  1. row and column headers are identified for data tables
    • Note: In order to achieve this provision, table objects in data operated on by the software would need to be associated with sufficient information to identify any row and column headers for the table, that the software can obtain as readily as it can obtain the data itself.
  2. markup is used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers.
    • Note: In order to achieve this provision, cells in table objects with multiple logical levels of headers in data operated on by the software would need to be associated with sufficient information to identify any row and column headers for the table cell, that the software can obtain as readily as it can obtain the table cell itself.
  3. markup is used to identify section headings
  4. markup is used to identify form element labels

3-P User Interface Components 

*** There is an outstanding issue on the meaning of programmatically determinable with regard to
    actual AT interoperability. This issue is related to the issues around the functional 
    performance criteria.

For all user interface components, including form elements and those generated by scripts, the name and role must be programmatically determined. States, properties, and values that can be set by the user must be programmatically determined and can be programmatically set. Notification of changes to these items must be available to user agents, including assistive technologies. For example, frames must be titled with text that facilitates frame identification and navigation.

3-Q Disruption of access 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.

3-R Timing

For each time limit that is set by the software or content, at least one of the following is true:

  • Turn off: the user is allowed to turn off the time limit before encountering it; or
  • 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
  • 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 a required 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 and time limits can not be extended further without invalidating the activity.

editorial suggestion: change "software or content" to "user interface or content"

  • Timing harmonization analysis
  • Additional information on Timing
  • Assessment of change in economic impact
    • None for Web sites. Significant for software.
    • Currently 508 only allows one strategy for dealing with timeouts on Web sites. Any current 508 compliant Web site will continue to comply with this provision. New requirement for software.

3-S Keyboard Operation

Where products have a keyboard or a keyboard interface, all functionality of the product operable through the user interface must be operable through the keyboard, or a keyboard interface. Specific timing for individual keystrokes must not be required. This provision does not apply where the underlying function requires input that depends on the full path of the user's movement, not just the endpoints.

  • Note: This exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path dependent input but the underlying function (text input) does not.
  • Note: This does not forbid and should not discourage providing mouse input or other input methods, such as gestures, in addition to keyboard operation.
  • Note: Keyboard interface can be either a hardware keyboard interface, a wireless interface or a software keyboard interface where AT can generate keystrokes that would be seen by software."
  • Note: For platform software, this includes the ability to move the keyboard focus into and out of applications.


3-T Focus Cursor

Any keyboard operable user interface must have a mode of operation where the indication of keyboard focus has a high degree of visibility. This can be provided by the interface itself or by the interface in combination with focus services provided by the platform.

editorial suggestion: User interfaces must support at least one mode that provides a highly visual indication of which user interface object currently has the keyboard focus.

  • Note: The presence of a highly visible text insertion point can be considered a visual indication of keyboard focus for a text area.
  • Note: A focus cursor that is visually locatable by people (familiar with what the focus cursor would look like) who have 20/20 vision at 3.5 times the typical viewing distance without moving the cursor is sufficient.
  • Note: Since computer software would be displayed on unknown screen sizes: for computer software a focus cursor that is visually locatable by people (familiar with the cursor) who have 20/20 vision at 2.5 meters when software is displayed on a 38 cm (15 inch) diagonal screen at 1024 x 768 pixels resolution, without moving the cursor is sufficient.

3-U AT interoperability 

*** There is an outstanding issue on the meaning of this provision with regard to actual
    AT interoperability. This issue is related to the issues around the functional performance
    criteria.

On platforms that support AT interoperability, software that provides user interface components must either use the accessibility services provided by platform software or other services to cooperate with assistive technologies when such services allow the software to meet the accessibility provisions of this standard. Using such services, software must:

  • provide assistive technology with object information including but not limited to:
    • role, state(s), boundary, name, and description
    • the row and column a component is in, and the headers for the row and column for that object if it is in a table that has row or column headers.
    • current value and any minimum or maximum values, if the component represents one of a range of values
    • relationship this component has as a label for another component, or being labeled by another component
    • parent or containing element, and any children components
    • text contents, text attributes, and the boundary of text rendered to the screen
    • Note: In order to achieve this provision, interactive elements encoded in data operated on by the software would need to be associated with sufficient information to determine a role, state(s), name, and description for the interactive element, that the software can obtain as readily as it can obtain the interactive elements itself.
  • provide assistive technology with a list of actions that can be executed on a component and allow assistive technology to programmatically execute any of those actions;
  • allow assistive technology to track and modify focus, text insertion point, and selection attributes of user interface components;
  • provide assistive technology with notification of events relevant to user interactions, including but not limited to changes in the component's state(s), value, name, description, or boundary
  • Note: This provision applies to forms in the software.
  • Note: Software that provides remote access to graphical user interfaces (GUIs) would need to ensure that AT has access to the information required by this provision. There are two known ways to accomplish this: run the AT remotely as well or run the AT locally and provide a mechanism for it to communicate accessibility information with the remote GUI.

3-V Accessibility Services

Platform software must provide access to a set of services that enable applications running on the platform to interact with other assistive technology sufficient to enable compliance with the "AT interoperability" and "User Interface Components" provisions. If accessibility services are provided by the platform on which they are run, software toolkits and applications that are also platforms must make these services available to their client software.

  • Additional information on Accessibility Services
  • Assessment of change in economic impact
    • None for desktop operating system platforms. Significant for platforms on platforms and for non-desktop platforms.
    • All desktop operating system platforms meet the requirement. Not all platforms on platforms and non-desktop platforms meet the requirement.

3-W Multiple Ways (New Provision)

More than one way is available to locate content within a set of Web pages where content is not the result of, or a step in, a process.

3-X Labels or Instructions (New Provision)

Labels or instructions are provided when content requires user input.

3-Y On Focus (New Provision)

When any component in content or electronic documents receives focus, it does not initiate a change of context.

3-Z On Input (New Provision)

Changing the setting of any user interface component in content or electronic documents does not automatically cause a change of context unless the user has been advised of the behavior before using the component.

3-AA Error Identification (New Provision)

If an input error is automatically detected in content or electronic documents, the item that is in error is identified and described to the user in text.

3-BB Advisory Notes

The following best practices are recommended best practices. As they are not testable criteria, they should not be included in the normative requirements for compliance with Section 508 or 255.

Suppression of unneeded function

Software should provide a mechanism enabling users to simplify the interface including the modification or hiding of command buttons. If such a function is provided, a mechanism should be provided to reset to the default user interface.

  • EXAMPLE 1 A user with a cognitive disability may, when using a given application, change the interface via a “skin” to simplify the application’s look and feel.
  • EXAMPLE 2 A word processor allows users to hide menu items and tool bar buttons that they do not find useful.

Writing guidelines

Authors should follow best practices for creating content that is accessible for people with disabilities. These guidelines include:

  1. Organize the content to serve the reader's needs, considering their tasks and goals.
  2. Use everyday words that convey meaning clearly and directly.
  3. Use the present tense and the active voice.
  4. Use short, simple sentences.
  5. Include useful headings.
  6. Use lists and tables to simplify complex material.

Interaction guidelines

Applications should design interaction paradigms that are accessible for people with disabilities including:

  1. Provide a means to undo actions, such as by resetting the form to the original information
  2. Provide a way to move backwards one step in a process to fix mistakes or check answers
  3. Provide a way to cancel actions before submitting

Software that is an authoring tool

8.2-A Accessible output

For each accessible content format supported, authoring tools must allow the author to produce content, including content derived from programmatic sources, that meets applicable Section 508 provisions.

8.2-B Preserve accessibility information

Authoring tools must preserve accessibility information necessary to meet applicable Section 508 provisions, unless the user explicitly indicates otherwise. (Note: after Aug 17, write up a rationale that includes an explanation of why "unless the user explicitly indicates otherwise" is necessary, so that the phrase is not lost during later work)

8.2-C Prompts

For authoring tools with a user interface, authoring tools must provide a mode which prompts authors to create accessible content.

8.2-D Accessible templates

Authoring tools which provide pre-authored content, or templates to facilitate production of content, must provide at least one version that meets applicable Section 508 provisions.

8.2-E Advisory notes

  1. Evaluation support
    • For authoring tools with a user interface, authoring tools must either provide a mode which assists authors in checking for accessibility problems, or compatability with evaluation tools that provide that function.
      • Note: after Aug 17, further discuss and write up a rationale explaining what is meant by "compatability with..."

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