This document maps Section 508 Standards for Electronic and Information Technology, Subpart B – Technical Standards, Section 1194.22 (Web Criteria) into the Sufficient Techniques for the Web Content Accessibility Guidelines 2.0. The needs identified by the Section 508 Criteria must be satisfied by all web content or web technologies purchased by a University or System that receives federal funding. In particular, all custom web sites along with their web technologies must meet the needs given in Section 508. The threshold of satisfaction will be the equally effective access test required by Section 504, the nondiscrimination section of the Federal Rehabilitation Act. This level of compliance is required for a University to satisfy Section 504. Equally effective access to documents is a format that enables equal timeliness, equal quality and a perceptual mode that meets the user's needs. Any lower threshold requires the University to spend extra money on accommodation or risk legal action.
The sufficient techniques from WCAG 2.0 were chosen for two reasons: (1) They are specific, well defined and testable, and (2) they satisfy the needs identified by Section 508 web criteria at a level to provide equally effective access.
These sufficient techniques appear in the W3C document WCAG 2.0 Quick Reference: A customizable list of WCAG 2.0 requirements (Success Criteria) and techniques. The document is not meant for end to end reading, but as a reference for specific criteria. Each Criterion from 508 is mapped into WCAG 2.0 success criteria and the associated sufficient techniques are determined by mapping the related success criteria into their corresponding techniques in the Quick Reference.
As an added benefit any web development that follows this protocol can also claim Level A Conformance to WCAG 2.0 with only four enhancements.
A text equivalent for every non-text element shall be provided (for example via alt or longdesc attributes, or in element content).
Non textual information like pictures, graphs or charts cannot be perceived by many users. Assistive technology cannot identify a non-text element or recognize the meaning of a non-text element without textual content to describe it.
Text must be provided for non-text elements so that the identity and meaning can be convey by assistive technology in a mode that the user can perceive.
Principle: 1 Perceivable
Guideline: 1.1 Text Alternatives, 1.3 Adaptable
Success Criteria: 1.1.1: Non-Text Content, 1.3.3 Sensory Characteristics
Successful removal of the need identified by 11194.22(a) at the level of equally effective access is met by techniques sufficient for WCAG 2.0 Success Criteria 1.1.1 and 1.3.3. See How to Meet 1.1.1 and How to Meet 1.3.3.
Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation.
Multimedia differs from text, pictures or pure audio in two important ways: (1) more than one perceptual mode is used to convey the content and (2) the meaning of the material frequently depends on synchronizing the information presented in different modes. This requires text alternatives for non-text elements and a synchronized time-based delivery of text alternatives for non-text items. The synchronized text for audio is called captioning.
Synchronized captioning is the solution for multi-media sound. If the medium has audio mode then a text equivalent must be present and synchronize with video. If the video portion has content that is essential to understanding the presentation, then there must be audio description or a full text equivalent for this video content. This audio or text description must also be synchronize with the graphical information in the presentation. For completeness, all time based media should be addressed. For Audio Only a full text alternative is provided. For Video only either a text alternative or audio track is provided.
Principle: 1 Perceivable
Guideline: 1.2 Time-based Media
Success Criteria: 1.2.1 Audio-only and Video Only (Prerecorded), 1.2.2 Captions (Prerecorded); 1.2.3 Audio Description or Full Text Alternative.
See, how to meet 1.2.1, 1.2.2 and 1.2.3 depending on the case at hand.
Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup.
Users who cannot perceive differences in color cannot use information that is only conveyed through color.
Provide additional cues that convey the same differences without using color.
Principle: 1 Perceivable
Guideline: 1.4 Distinguishable
Success Criteria: 1.4.1 Use of Color
See How to Meet 1.4.1.
Documents shall be organized so they are readable without requiring an associated style sheet.
The organizational structure of information in a document and its associated meaning may depend on a presentation style that some users cannot perceive.
Create a flexible data format that preserves the organizational structure of the document when the material is presented in an alternative mode required by the user to perceive the document.
Principle: 1 Perceivable
Guideline: 1.3 Adaptable
Success Criteria: 1.3.1 Info and Relationships and 1.3.2 Meaningful Sequence.
Success Criteria 1.3.1 and 1.3.2 cover Section 508 1194.22 (d). The sufficient techniques to satisfy 1194.22 (d) can be found through the link How to Meet 1.3.1 and How to Meet 1.3.2. For 1.3.1 use the techniques 1–4 in Situation A for technologies with semantic structure to meet 1194.22(d). Plain text and HTML preformated text can easily violate 508 (d) as well as 1.3.1 and 1.3.2. For these cases use Situation B, the technology in use does not provide semantic structure, of the sufficient techniques to comply.
Redundant text links shall be provided for each active region of a server-side image map.
Without redundant links there is no URL on the page that can be located and and activated with a keyboard. The server side maps do not provide this.
In any map provide full keyboard access to all functionality - no exceptions.
Principle: 2 Operable
Guideline: 2.1: Keyboard Accessible
Success Criteria: 2.1.1 Keyboard
The inclusion of redundant links on the page just creates a client-side method of activating the links in a keyboard accessible way. If the client side links invoke Scripts to implement functionality then use How to Meet 2.1.1. Even client side image maps should include redundant textual links.
Statement of 1194.22 (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.
Same as (e), server side maps, there must be a keyboard accessible method to activate the hot spots in the map. Client side map elements provide semantic code that contains all the properties needed to support the other criteria (like text for non-text items etc.) and they are navigable by keyboard.
In any map provide full keyboard access to all functionality - no exceptions.
Principle: 2 Operable
Guideline: 2.1: Keyboard Accessible
Success Criteria: 2.1.1 Keyboard
If the client side links invoke Scripts to implement functionality then use How to Meet 2.1.1. Today server side maps are never required. When using maps use client side maps only.
Row and column headers shall be identified for data tables.
A data table is a rectangular configuration of textual data divided into horizontal rows and vertical columns. Each entry within a table has a specific meaning that depends upon its location within the table. Usually the first text item in a row and / or column of the table identifies the meaning of the data in the rest of the row and / or column. These values are called the row and column headers. Unless these items are marked as header elements assistive technology may not recognize their significance to the table, and a user of assistive technology cannot know the meaning of cells within a table.
Create a flexible table format that preserves the organizational structure of the table when the material is presented in an alternative mode required by the user to perceive the table. In particular, the location of data cells must be identifiable in terms of the row and column that hold the data cell. Headers must be used so the assistive technology can inform the user of the row and column headers associated with a given data entry within the interior of the table.
Principle: 1 Perceivable
Guideline:1.3 Adaptable
Success Criteria: 1.3.1 Info and Relationships
Success Criterion 1.3.1 covers Section 508 1194.22 (g). The sufficient techniques to satisfy 1194.22 (g) can be found through the link How to Meet 1.3.1. Look at Situation B, group 4, techniques: H51: Use table markup to present tabular information, H63: Using the scope attribute to associate header cells and data cells in data tables. You may use H43: Using id and header attributes to associate data cells with header cells in data tables, but it is not required for simple data tables.
Markup shall be used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers.
With two or more levels of table headers the connection of a header to a cell may not be determined by physical position as in the case of simple data tables. To understand the meaning of data in a table cell when one cannot perceive the associated header values one must have a way to identify the complete collection of headers associated with a given cell.
All users have full knowledge of the values and relationships of headers associated with all data cells in order to interpret the meaning of each data value.
Principle: 1 Perceivable
Guideline: 1.3 Adaptable
Success Criteria: 1.3.1 Info and Relationships
See How to Meet 1.3.1 . Look specifically at H63: Using the scope attribute to associate header cells and data cells in data tables (HTML) and H43: Using id and headers attributes to associate data cells with header cells in data tables (HTML). You may use H63 without H43 whenever the row and column headers are layered. That means multi levels of headings are nested as you go from outer to inner levels. For example in a layered table describing plants, you might group the table headings "family, genus and specie" under the outer heading "plant name".
Frames shall be titled with text that facilitates frame identification and navigation.
Frames are a technique to group material that is used on multiple pages. Without meaningful titles a user may not perceive the purpose of the grouping that may be apparent from other perceptual cues.
Give all frames in a frame set meaningful titles that identify the function of their content.
Principle: 2 Operable
Guideline: 2.4 Navigable
Success Criteria: 2.4.1 Bypass Blocks
See How to meet 2.4.1. There is controversy concerning the use of frames. In particular, they do not linearize well. If frames are not already deployed, consider using other methods to group repeated items. Note: The Success Criterion 2.4.1 Page Titles should also apply here because framesets are really multi-page pages and the frame titles identify independent pages, but there is no mention of frames in the success criteria for 2.4.2. The specific technique for frame titles is H64: Using the title attribute of the frame and iframe elements.
Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz.
Flicker can cause seizures.
Never cause seizures. Provide a means to avoid flicker, and never flicker within the specified range.
Principle: 2 Operable
Guideline: 2.3 Seizures
Success Criteria: 2.3.1 Three Flash or Below Threshold
See How to meet 2.3.1. Follow these instructions precisely.
A text-only page, with equivalent information or functionality, shall be provided to make a web site comply with the provisions of these standards, when compliance cannot be accomplished in any other way. The content of the text-only page shall be updated whenever the primary page changes.
If a technology exists that cannot be made accessible in any other way, then text may be the only way to convey the content. This situation is almost nonexistent. Ajax, Applets, Objects and Multimedia can all be addressed using techniques given here. There are accessible Flash guidelines. PDF can be made accessible.
It is almost impossible to achieve equally effective access with text-only data except for textual data itself. One thing that can get the text-only document closer is to provide up to date content equivalence and provide text cues that indicate document structure.
Principle: 1 Perceivable
Guideline: 1.3 Adaptable
Success Criteria: 1.3.1 Info and Relationships
See, How to meet 1.3.1. In this case use Situation B (The technology in use does NOT provide the semantic structure) and use the method given here to represent tabular data. It is much easier to create an accessible medium in the first place than it is to create an equally effective text-only substitute. Note 1: The techniques for 1.3.1 Situation B do not describe how to implement text only tables. Here is a technique that is faithful. Linearized Tables: To represent a textual data table use a relational data format in a linear order. That is, use the set of column headers for field names. Each row is a list of ordered pairs field names paired with its data values. If row headers are present then use these names as row titles. One per table row. The list of all such rows is the table. This document is an example of a linearized table in relational form. The<h2> elements are row headers. The <h3> elements are column headers. The data values are the text contents associated with the <h3> elements.
When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology.
Script can change the page environment without notifying the user agent. It can also create functionality for grouping elements like <span> and <div> that duplicates or extends the underlying markup language. In both cases the standard application program interfaces provided by operating system environments can be bypassed and assistive technology cannot interact with what is occurring at a given time. This locks the user with a disability out of the process.
Script must communicate through the standard accessibility application programming interface provided by system so that compliant assistive technology will function as needed.
Principle: 4 Robust
Guideline: 4.1 Compatible
Success Criteria: 4.1.2 Name, Role, Value
See How to use 4.1.2. As of this writing the WAI ARIA documents are still working drafts. However, WAI ARIA techniques provide accessible interfaces to Scripting languages that follow the protocols and several browsers and took kits support them.
When a web page requires that an applet, plug-in, or other application be present on the client system to interpret page content, the page must provide a link to a plug-in or applet that complies with §194.21(a) through (l).
An object or applet is free to use any interface it chooses to display within its user agent. It is generic software running in a browser or media player. To function properly it must satisfy the software paragraph of Section 508.
The interface must be perceivable, operable, understandable and robust. The W3C term for this type of Web technology is accessibility supported
Guideline: As apply to the UI of the specific technology
Success Criteria: As apply to the UI of the specific technology
See in the WCAG 2.0 Guidelines the parts relating to Accessibility Supported: Important Terms in WCAG 2.0 —Accessibility Supported, and Conformance Requirements —4. Accessibility Supported is Required. Also, see Understanding Accessibility Supported.
When electronic forms are designed to be completed on-line, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.
Lack of access to online forms means loss of access to real world services. For example, a person who uses an a human operator to schedule a flight will usually pay more than a person who orders on the web.
Everyone can read and operate a form.
Principle: 1 Perceivable, 2 Operable and 3 Understandable
Guideline: 1.3 Adaptable, 2.1 Keyboard Accessible, 3.2 Predictable, and 3.3 Input Assistance.
Success Criteria: 1.3.1 Info and Relationships, 2.1.1 Keyboard, and 2.1.2 No Keyboard Traps, 3.2.1 On Focus, 3.2.2 On Input, 3.3.1 Error Suggestion and 3.3.2 Labels or Instructions.
See How to meet 1.3.1 , parts relating to Forms: H44: Using label elements to associate text labels with form controls , H65: Using the title attribute to identify form controls when the label element cannot be used , H71: Providing a description for groups of form controls using fieldset and legend elements , H85: Using OPTGROUP to group OPTION elements inside a SELECT, H82: Grouping form controls with FIELDSET and LEGEND. Also see How to meet 2.1.1 and How to meet 2.1.2 as well as How to Meet 3.2.1, How to Meet 3.2.2, and How to Meet 3.3.2. Keyboard control, freedom from keyboard traps, safe behavior on focus and on input are all necessary for effective online form handling. See How to Meet 3.3.1 and How to Meet 3.3.2 for providing a minimum level of help for input.
A method shall be provided that permits users to skip repetitive navigation links.
The ability to skip repeated links saves lots of time stepping through links one by one looking for the piece of information you want.
Links should be grouped in identifiable ways and a method to jump to of from them using assistive technology must exist.
Principle: 2 Operable
Guideline: 2.4 Navigable
Success Criteria: 2.4.1 Bypass Blocks.
See How to meet 2.4.1. The techniques: H69: Providing heading elements at the beginning of each section of content; H50: Using structural elements to group links; H70: Using frame elements to group blocks of repeated material AND H64: Using the title attribute of the frame and iframe elements are garenteed to provide equally effective access. Skip links are less reliable, and often produce a maze of links that obscure page meaning.
When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required
People with disabilities need more time to complete many tasks.
A method to provide sufficient time to complete an on-line task without penalty.
Principle: 2 Operable
Guideline: 2.2 Enough Time,
Success Criteria: 2.2.1 Timing Adjustment, 2.2.2 Pause, Stop, Hide.
See How to meet 2.2.1 and How to Meet 2.2.2. The first techniques address user control over timed events. The second techniques provide user control over intrusive timed events.
Only four level A criteria are missed by Section 508 when we meet 508 at an equally effective access.
Guideline 1.4 Distinguishable, Success Criterion 1.4.2 Audio Control. Users must be able to shut off or control the volume of a sound that lasts more than 3 seconds. See How to Meet 1.4.2. This criterion does has just one sufficient technique, and may have its status demoted to advisory.
Guideline 2.4 Nabigable, Success Criteria 2.4.2 Page Titles. Surprisingly 508 does not require page titles. Frame titles are only implied by their use in grouping repeated links. Use, How to Meet 2.4.2 for techniques.
Guideline 3.1 Readable, 3.1.1 Language of the Page: The default human language of each web page should be programatically determined. Use, How to Meet 3.1.1.
Guideline 4.1 Compativle, 4.1.1 Parsing: In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features. This really says follow standards, and don't use silly shortcuts. See Understanding 4.1.1.