WCAG 2 and 508 New: WCAG 2.0 and Section 508/255 Refresh Side-by-Side [Draft]

Advisory 603.2 Pre-recorded Audio Content with No Video Content or User Interaction.  A best practice is to provide synchronized captions for pre-recorded and real-time (live) audio-only media.  This best practice is not a requirement.  Complementing an audio-only stream with captions entails the addition of a visual stream and translation of the data.  An example where this would be a fundamental alteration is a radio broadcast.

An audio-only presentation used in a public setting may require captions or other real-time visual equivalent under sections 501 and 504 of the Rehabilitation Act.

Advisory 603.4 Pre-recorded Video Content with Synchronized Audio Content.  Captions are either closed or open.  “Closed” means capable of being turned on and off.  “Open” means visible to all users.

A best practice is for captions to conform to Chapter 5 (Electronic Documents) to provide alternate formats for people who are deaf-blind and rely on braille.

Advisory 604.2 Pre-recorded Video with No Audio or User Interaction.  An example of pre-recorded video with no audio information or user interaction is a silent movie.

The purpose of the transcript is to provide an equivalent to what is presented visually.

The purpose of the audio alternative is to be an equivalent to the video. 

A text equivalent is not required for audio that is provided as an equivalent for video with no audio information.  For example, it is not required to caption video description that is provided as an alternative to a silent movie.

A video-only presentation used in a public setting may require video description or other real-time audio equivalent as a reasonable accommodation under section 501 and 504 of the Rehabilitation Act.

Advisory 604.4 Real-Time Video.  A best practice is for speakers to incorporate verbal descriptions of any visual information presented.  This practice is necessary for any live presentation to be accessible.  This practice may also avoid having to add video description to presentations that are recorded.

An example of real-time video is a live “on-site” news broadcast.

Advisory 604.4 Real-Time Video Exception.  An example of real-time video that is unattended and has the primary purpose of extending a sensory experience is an automated fixed camera that overlooks a national park and continuously broadcasts sights and sounds.

A best practice to provide as much textual based information as possible, even when only descriptive identification is required.  An example of this is adding current wind speed and temperature information to the text alternative associated with an unattended “beach cam”.

Advisory 604.5 Multiple Visual Areas of Focus.  Video may contain more than a single visual focus.  This provision requires that video description be provided for each area of focus.  An example is in-house agency broadcast programs where scrolling event notices appear under the main program.  People who are blind have traditionally missed out on visual information in videos, when it was necessary to understand more than one thing at the same time.  For example, a video of an interview should audibly describe who is speaking when their names are visually displayed.  In addition, streaming information, such as daily news highlights, should also be video described.

In particular, visual emergency communication, such as emergency announcements in the form of text scrolling on a screen, is covered by this requirement.  This is consistent with the Federal Communications Commission (FCC) rule requiring broadcasters and cable operators to make local emergency information accessible to persons who are deaf or hard of hearing, and to persons who are blind or have visual disabilities.  This part extends that requirement to ICT.

A second method for meeting this requirement is to stream the audio information in two tracks that can be fed separately into the right and left ears.  Since the video description stream can be closed, people without disabilities would not have to listen to the competing audio streams.  People who are blind often have the skill to listen to two audio streams simultaneously or can be trained to do so.

Advisory 503.2 Information, Structure and Relationships.  The intent of this provision is to ensure that information and relationships that are implied by visual or auditory formatting are preserved when the presentation format changes.  An example is the presentation format changing when the content is read by a screen reader or when a user style sheet is substituted for the style sheet provided by the author.

The sub provisions under 503.2 are not an exhaustive list of information, structure, and relationships that might be presented to an end-user.

Advisory 503.3 Logically Correct Reading Sequence.  A logically correct reading sequence is a sequence where words and paragraphs are presented in an order that does not change the meaning of the content.

There may be more than one choice for a logical reading sequence of some content.  An example is a sidebar item that might reasonably be read before, after, or in the middle of the main body content.  Content authors and developers have flexibility in deciding a logically correct reading sequence.

An example of a reading sequence that is not logically correct is where content is divided into two or more newspaper-style columns, but the programmatically determined reading sequence reads across columns rather than down each column. 

Another example is using a style sheet to visually position blocks of text on a page.  If the reading sequence used by assistive technology follows a reading sequence implied visually, then the reading sequence is logically correct.  If the programmatically determined reading sequence seems random and does not follow any reading sequence implied visually, then the reading sequence is not logically correct.

Advisory 503.4 Sensory Characteristics.  Rather than stating, “Click the oval button to the right when done”, an instruction should tell the user to “Activate the Submit button when done.”

Object information (provided per 503) which describes the necessary visual cues or relationships, may be used in providing instructions that conform to this provision.

Advisory 305.1 Not Only Color.  This requirement allows color to be used.  An example is an electronic form with required and optional fields.  Instructions at the beginning of the form explain that required fields are both labeled with an asterisk and appear in red text.  In this example, the asterisk is the non-color dependent visual means of conveying information.

This provision only addresses the ability to distinguish color.  Other forms of perception are addressed by 503.2 Information, Structure, and Relationships which includes programmatically determinable access to information conveyed by visual presentation.

Advisory 403.1 General.  Many individuals with visual and hearing disabilities have difficulty separating foreground and background information.  A best practice to make it easier for users to see and hear content is to separate foreground from background.

For visual presentations, this involves making sure that information presented on top of a background contrasts sufficiently with the background.  For audio presentations, this involves making sure that foreground sounds are sufficiently louder than the background sounds.

Advisory 504.2 Text and Images of Text Contrast Ratio Exception.  An example of an “inactive user interface component” is an item within a menu that automatically “grays out” when its selection is not available.  In this example, the deemphasized item remains in the menu as a placeholder.

An example of images of text in “part of a picture that contains significant other visual content” is the lettering on a shop window in a photograph of a street scene when the lettering on the window is not relevant to the purpose of the photograph.

504.3 Resize and Reflow Text.  Most content formats and platforms natively provide a capability for users to adjust font size.  Content can be developed which interferes with this native capability and thus creates a barrier to accessibility for users with low vision.

Reflow of text is necessary because just making letters larger would result in text moving off the screen or text appearing on top of other text.

A best practice is for captions and images of text to support the resizing and reflow of text.

Another best practice is to use text, rather than images of text, wherever possible, because text gives users more control over font size.

Web documents that support resize and reflow of text are sometimes described as “fluid”, “liquid”, or “elastic”.

Advisory 404.2 Keyboard Interface.  This provision refers to the underlying function of the input method.  This provision does not prohibit and should not discourage providing for mouse input or other input methods in addition to providing for keyboard operation.

An example of ICT that requires a keyboard interface is a product which by default provides for handwriting as a means to enter text.  The default input technique (handwriting) requires path-dependent input, but the underlying function (text entry) does not.  Therefore, Exception 1 is not applicable.

The phrase “without requiring specific timings” is included so that end users can enter keystrokes through a keyboard interface at their preferred pace.

Examples of “specific timings for individual keystrokes” include situations where a user would be required to repeat or execute multiple keystrokes within a short period of time or where a key must be held down for an extended period before the keystroke is registered.

The use of “MouseKeys” would not satisfy this provision because “MouseKeys” is not a keyboard equivalent to the application; it is a mouse equivalent (that is, it looks like a mouse to the application).

Advisory 404.2 Keyboard Interface Exception 1.  The phrase “underlying function requires input that depends on the path of the user’s movement, and not just the endpoints” is included as an exception to distinguish operations that cannot reasonably be controlled from a keyboard.

This exception refers to the underlying function, not to the default input technique.

An example of an underlying function that uses path dependent input is a watercolor painting program.  The brush strokes (the user’s input in this example) vary depending on the speed and duration of the movements, therefore a keyboard interface is not required.

Another example where the exception might appear to apply but does not apply, involves the use of drag and drop functionality.  Although performing a drag and drop function with a mouse would require path-dependent movement and would thus seem not to require keyboard access, here again, the underlying function, moving items from one location to another or selecting an item from one list while another item is highlighted in another list of items would in fact require keyboard access, since the moving or selecting of data can be accomplished through non-path-dependent keyboard mechanisms such as select boxes and other similar controls.

Advisory 404.2 Keyboard Interface Exception 2.  An example of a product that does not require a keyboard interface is a voice operated speaker telephone that does not have a screen and that provides for all dialing and on/off hook functions to be executed through voice commands.

Advisory 404.4 Presentation of Keyboard Shortcuts.  Keyboard shortcuts include keystroke commands such as those used to activate a menu item or button, for example, the “S” of a “Save File” menu item.

An example of one mode of operation is a help screen that lists keyboard commands.

A best practice is for the keyboard shortcuts to be available directly as part of the live user interface.

This provision does not require adding keyboard shortcuts beyond those usually associated with a platform.

There are many common conventions that do not require a visual indication of keyboard shortcuts because they are not associated with specific visual elements of the user interface.  Examples include the command to switch windows (such as Alt-Tab) and the command to advance the caret in text (such as Ctrl-Arrow).

User-configurable keyboard shortcuts are not considered to be directly tied to interface elements and thus are not required to be displayed.  However, a best practice is to display user-configurable keyboard shortcuts.

Advisory 404.5 Visible Keyboard Focus Indicator.  An example of a visible keyboard focus indicator is an I-beam cursor.

The focus indicator may be provided by the interface itself or by the interface in combination with accessibility services provided by the platform.

For a text area, the presence of the default text insertion point indicator (for example, an I-beam cursor) is sufficient for most platforms to conform to this provision.

When a user relies on the keyboard to interact with content, this provision requires a visible cursor so that the user can visually determine the component with which keyboard operations will interact at any point in time.

People with low vision (but who are not using assistive technology), attention limitations, short term memory limitations, or limitations in executive processes benefit by being able to determine where the focus is visually located.

Advisory 405.2 Control Over Time Limits Exception 1.  A server time out, even for security reasons, is not a situation when user modification of the time limit would invalidate the activity.  Therefore, a server time out is not an appropriate use of Exception 1.

Advisory 405.2 Control Over Time Limits Exception 2.  An example is an on-line ticket-purchasing site which gives the user two minutes to confirm a purchase before the seats are returned to the general pool.  Because tickets on such sites can sell out quickly, this is a case in which the time limit is a required part of a real-time event.  A best practice is for the site to move as much of the process out of the time-limited period as possible, allowing users to provide necessary information like name, payment method, etc., before entering the time-limited period.

Advisory 405.2 Control Over Time Limits Exception 3.  A best practice is to provide the option to turn off, adjust, or extend the time limit even when the time limit is at least eight hours.

Advisory 405.3 Control Over Moving, Blinking, or Scrolling Information, and Automatic Updates.  Content that is streamed, or otherwise automatically updated periodically, might not be preserved when paused.  Preservation might not be technically possible, and in many situations might be misleading.

Examples of moving, blinking, scrolling, or automatically updating information include:

• A Web site helps users understand “how things work” through animations that demonstrate processes.  Animations have “pause” and “restart” buttons.
• An advertisement blinks to get viewers attention but stops after five seconds.
• A form blinks an arrow near the submit button if a user finishes filling out the form but does not activate the submit button.  The blinking stops after five seconds.
• An animation runs in the upper portion of the page but has a “freeze animation” button near the bottom of the animation.

Advisory 405.3 Control Over Moving, Blinking, or Scrolling Information, and Automatic Updates Exception 1.  An example of essential moving content is animation that occurs as part of a preloading phase, when interaction cannot occur during that phase for all users.  In this situation, not indicating progress would likely confuse users or cause them to think that content was frozen or broken.

Advisory 405.3 Control Over Moving, Blinking, or Scrolling Information, and Automatic Updates Exception 2.  Automatically updating information does not start automatically when users have to activate a control to start the update and are advised of the behavior before the automatic update starts.

Advisory 405.3 Control Over Moving, Blinking, or Scrolling Information, and Automatic Updates Exception 3.  An example is animation that is shown on a web page which requires a certain percentage of a large video file to be downloaded before video play can begin.  The animation is the only content on the web page.  The user has to wait while the video loads.  Because the moving content is not presented at the same time and in the same location as other content, no mode of operation to pause, stop, or hide the animation is required, even though the animation may run for more than five seconds for users with slower connections.

Another example is a web site that requires all users to view a fifteen second advertisement before they can access free content available from the site.  Because the advertisement is not presented in parallel with other content, a mode of operation to pause, stop, or hide the advertisement is not required.

Advisory 202.11 Minimize Photosensitive Seizure Triggers.  ICT that emits light in flashes at any time may visually induce seizures for people who have photosensitive seizure disorders.

For further clarification of this requirement, consult WCAG 2.0 Success Criteria 2.3.1 Three Flashes or Below Threshold and Success Criteria 2.3.3 Three Flashes.

See also the WCAG 2.0 definitions for “general flash and red flash thresholds”.  These are found at:  http://www.w3.org/TR/WCAG20/#general-thresholddef.

Advisory 306.1 Flash Threshold.  For further clarification of this requirement, consult WCAG 2.0 Success Criteria 2.3.1 “Three Flashes or Below Threshold”.

See also the WCAG 2.0 definition for “general flash and red flash thresholds” found at:
http://www.w3.org/TR/WCAG20/#general-thresholddef.

Advisory 406.2 Bypass Blocks of Content.  The ability to bypass blocks of content is used to jump focus (or “reading”) to get to other portions of content.

An example is when the start of the content of an onscreen interface includes a set of menu options.  A user may choose to bypass this set of menu options by jumping focus to the main content.

A best practice that meets this provision is consistently providing headings within content.  Assistive technologies often allow users to navigate from heading to heading.  Therefore, consistently providing headings is providing a mode of operation that provides users the ability to bypass blocks of content.

Use of tables of content and internal “same page” links can be used to meet this requirement as they allow navigation to specific content without requiring lengthy sequential “skimming”.

Advisory 505.3 Link Purpose.  The intent of this provision is to help users understand the purpose of each link so that they can decide whether they want to follow the link.

A best practice is to provide link text that identifies the purpose of the link without needing additional context.

Assistive technology has the ability to provide users with a list of links that are on the Web page.  Link text that is as meaningful as possible will aid users who want to choose from this list of links.  Meaningful link text also helps those who wish to tab from link to link.  Meaningful link text helps users choose which links to follow without requiring complicated strategies to understand the page.

In some situations, authors may want to provide part of the description of the link in logically related text that provides the context for the link.  An example of this is when only one word in a sentence is a link, and the purpose of this link is made apparent from the context provided by the entire sentence.

When the link text alone is not sufficiently descriptive, this provision requires that a user be able to identify the purpose of a link without moving focus from the link.

Users should be able to arrive on a link and find out more about where the link leads without losing their place in content.  Examples of programmatically determined link context include:  putting the description of the link in the same sentence, paragraph, list item, a heading immediately preceding the link, and table headings cell for a link in a data table.

An example of link text being used together with its programmatically determined link context is a list of books available in three formats:  HTML, PDF, and MP3.  In this example, so that screen reader users do not have to hear the title of each book three times (once for each format), the first link for each book is the title of the book, the second link says “PDF”, and the third says “MP3”.

Text that is in title or alt attributes is programmatically determinable and may also be used for compliance with this provision.  An example of this technique is a news article summary where the main page lists the first few sentences of each article followed by a “Read More” link.  In this example, each “Read More” link includes a title attribute with a value that is unique to each article.

505.3 Link Purpose Exception.  An example where links are ambiguous to all users in general is an online quiz that has possible answers identified only with an arbitrary number.  In this example, descriptive link text might influence choices, and invalidate the purpose of the quiz.

Advisory 505.4 Headings and Labels.  An example of this provision would be descriptive section headings in a document. 

An example of a technology that does not allow the document author to create headings or labels which describe topic or purpose is a spreadsheet; therefore, this provision would not apply to spreadsheets. 

An example of a situation where headings and labels are not appropriate to the task is a data table.  Short non-descriptive identifying labels are appropriate for this task.  Headings for data tables are required by 503.2.1.

Advisory 407.2 No Change of Context from Focus.  A change of context is a major change in the content that, if made without user awareness, can disorient users who are not able to view the entire page simultaneously.

This provision does not prohibit changes of context.  Changes of context are an expected consequence of the user actively interacting with components.  This provision prohibits changes of context that are triggered by the user only moving the focus around the user interface.

Users of assistive technology move the focus around the user interface in order to explore and read the web page or screen.  This provision prohibits components from activating because the component receives focus.

Focus can be indicated by keyboard, mouse-over cursor, or through other input devices.  Any component that is able to trigger an event when it receives focus must not change the context.

Examples of automatically changing context when a component receives focus which are prohibited by this provision include, form submission without a submit button, new windows opening without activation of a link (pop-over and pop-under), and changing (jumping) focus from the current component to another (perhaps on the same screen or in the same document).

Advisory 408.2 Input Error Identification and Description.  The intent of this provision is to ensure that users are aware that an error has occurred and can determine what is wrong.

A best practice is for the error identification and description to be as specific as possible.

Advisory 507.2 Labels or Instructions.  The intent of this provision is to ensure that enough information is provided for the user to accomplish the task without undue confusion or navigation.

Labels do not need to be lengthy.  A word, or even a single character, may be sufficient if it provides an appropriate cue to finding and navigating content.

An example of a sufficient label for a telephone number data entry field is the use of a hyphen, and not just white space, to separate parts of the phone number.

An example of an insufficient label for a telephone number data entry field is the use of formatting implied only visually by shape, size, or location of the parts of the phone number.

Advisory 411.1 General.  ICT content includes information and sensory experience communicated to the user and encoding that defines the structure, presentation, and interactions associated with those elements.  Examples of content are text, images, sounds, videos, controls, and animations.

A best practice is to maximize compatibility with current and future technologies, including assistive technology.

Advisory 411.2 User Interface Components.  Providing role, state, and value information on all user interface components enables compatibility with assistive technology.  Examples of assistive technology that can make use of role, state, and value information include screen readers, screen magnifiers, and speech recognition software.

This provision is primarily aimed at content providers who develop or script their own user interface components and includes but is not limited to form elements, links, and components generated by scripts.

For example, standard HTML controls and form elements conform to this requirement when used according to specification.

A best practice is for the information which is programmatically determinable to be descriptive.  Examples include:

• Any possible value ranges, including any minimum or maximum.
• Any relationship a component has as a label for, or how it is labeled by, another component.
• The name of any parent or containing component, and a list of any children components (nesting).
• Boundary information, including size and coordinates.
• Whether the component can accept focus.
• Whether the component can be used for “drag-and-drop” operations, either as object or target.

Advisory 411.3 Use of Platform Accessibility Services.  Platform accessibility services define the rules for interaction between assistive technology, other applications, content, and the platform.

This provision requires the use by assistive technology of the information exposed through platform accessibility services to deliver the alternate interface to the user with a disability.  This ensures that electronic content designed to be accessible is available to the end-user.  An example is an alternate text description of an image, which is invisible, but which a screen reader vocalizes.

This provision is not intended to limit the creativity of assistive technology developers or to limit methods of delivering alternate user interfaces.  This provision requires that when a platform provides accessibility services, such services must be used to provide accessibility.

Advisory 508.2 Markup Language Used According to Specification.  HTML (hyper text markup language) and XML (extensible markup language) are examples of markup languages which are used in the creation of electronic content.

The intent of this requirement is to ensure that user agents, including assistive technologies, can accurately interpret and parse content using markup language.  Content that is properly coded using all of the above requirements is correctly read by user agents, such as screen readers.

In markup languages, errors in element and attribute syntax and failure to provide properly nested start and end tags lead to errors that prevent user agents from parsing the content reliably.  This provision requires that the content can be parsed using only the rules of the formal grammar for the technology.

Many authoring tools ensure unambiguous parsing.  When available for the content format, validation ensures unambiguous parsing.  A best practice is to use authoring tools that provide validation or otherwise ensure unambiguous parsing.  See section 413 for more guidance on the use of authoring tools.

Content which is poorly coded and omits any one of the requirements in the provision may be unreadable by a user agent.  For example, a table is coded, but the nested (508.2.2) start and end tags (508.2.1) are omitted.  As a result, the screen reader tool reports “not in a table” when the user tries to invoke table navigation commands to move from one data cell to another.  The screen reader is unable to properly read the poorly coded document, since some of the requirements, such as properly nested start and end tags in this case, were omitted. 

Some user agents use “repair techniques” to render poorly coded content but the resulting rendering can be unpredictable, and documents that rely on such repair techniques are not conformant to this provision.  If the content cannot be parsed into a data structure, then different user agents may present it differently or be completely unable to parse it. 

Repair techniques vary among user agents.  A best practice is for content to be created according to the rules defined in the formal grammar for that technology.  When this best practice is not followed, authors cannot assume that content will be accurately parsed into a data structure.  Authors also cannot assume that content will be rendered correctly by specialized user agents, including assistive technologies.  Markup language must be used according to specification.

Advisory 508.3 User Interface Components.  The intent of this provision is to ensure that document authors do not disrupt accessibility features.  This provision is applicable but not limited to form elements, links, and components generated by scripts.

Examples of user interface components in documents include hypertext links, buttons, and form elements or fields.

Standard HTML controls and form elements conform to this requirement when used according to specification.

Chapter 4 (Platforms, Applications, and Interactive Content) contains requirements for user interface components.