Side by Side WCAG vs. 508

Sponsored by the Association of Tech Act Projects

Contents

 

Overview

The intention here is to compare the Priority 1 Web Content Accessibility checkpoints with the Section 508 Web Accessibility standards. However, some of the 508 standards relate to lower priority checkpoints from the Web Accessibility Initiative. The view of the Web Content Accessibility Guidelines lists only the priority one checkpoints The Section 508 view includes priority 2 and 3 checkpoints in the comparison.

The first table lists the Priority 1 Web Content Accessibility checkpoints followed by a comparison phrase like "the same," and then the relevant Section 508 web accessibility standard or standards. This table is titled "The WCAG View."

The second table is titled, "The 508 View." It lists all the 508 standards, and for each one, the comparison phrase, and the relevant WCAG checkpoint or checkpoints.

The following three short sections introduce the 508 standards, and the WCAG priority 1 checkpoints and some resources.

 

Section 508 Web Accessibility

"Section 508" refers specifically to Section 508 of the Rehabilitation Act of 1973, as amended by the Workforce Investment Act of 1998. The law requires Federal agencies to purchase electronic and information technology that is accessible to employees with disabilities, and to the extent that those agencies provide information technology to the public, it too shall be accessible by persons with disabilities.

Actually Section 508 was included in an amendment to the Rehabilitation Act in 1986, with the requirement that the Federal Government provide accessible technology to employees and to the public. But the 1986 version provided no guidance for determining accessibility of information technology and there were no enforcement procedures.

The 1998 amendment addressed both these issues. The Access Board (the Architectural and Transportation Barriers Compliance Board) was assigned the task of determining standards for accessible electronic and information technology. Although the law applies to the development, procurement, maintenance, or use of all electronic and information technology, it is in the procurement where the enforcement lies.

The result of the effort by the Access Board is a set of standards for accessible electronic and information technology. That document includes an extensive discussion on the development of the standards. The specific standards address:

  • Software applications and operating systems (§1194.21)
  • Web-based intranet and internet information and applications (§1194.22)
  • Telecommunications products (§1194.23)
  • Video or multimedia products (§1194.24)
  • Self-contained closed products such as copiers (§1194.25)
  • Desktop and portable computers (§1194.26)

Our interest here is §1194.22, standards for accessible web-based intranet and internet information and applications.

The accessibility standards of Section 508 apply to Federal agencies purchasing electronic and information technology. It is hoped that the market pressure of Federal procurement will have a much broader effect than just making Federal information technology accessible, though even that is an significant goal.

In particular, the requirements of Section 508 do not extend to recipients of Federal funds or private businesses. There is one notable exception to this exemption. According to the ATAP site, "states which receive Federal funds under the Assistive Technology Act of 1998 are required by that Act to provide an assurance of compliance with Section 508. Currently all 50 states and all territories receive Assistive Technology Act dollars and all have some form of Section 508 assurance."

This comparison of the WCAG Priority 1 checkpoints and the Section 508 web accessibility standards is of interest to states because some have chosen to use the Web Content Accessibility Guidelines as the criterion for web accessibility.

 

The Web Accessibility Initiative Guidelines (WCAG)

The Web Accessibility Initiative (WAI) was formed by the World Wide Web Consortium (W3C) in order to bring accessibility considerations into the technology development of the Web Consortium and to determine guidelines for accessible technology including web authoring and user agents (browsers). As Tim Berners-Lee, the inventor of the Web, and the Director of the W3C put it, "The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect."

The first version of the authoring guidelines, the Web Content Accessibility Guidelines 1.0, became a W3C Recommendation on May 5, 1999.

The guidelines are further organized into a checklist. The checkpoints are categorized as Priority 1, 2 or 3. Here is the characterization of those priorities from the Guidelines:

[Priority 1]

A Web content developer must satisfy this checkpoint. Otherwise, one or more groups will find it impossible to access information in the document. Satisfying this checkpoint is a basic requirement for some groups to be able to use Web documents.

[Priority 2]

A Web content developer should satisfy this checkpoint. Otherwise, one or more groups will find it difficult to access information in the document. Satisfying this checkpoint will remove significant barriers to accessing Web documents.

[Priority 3]

A Web content developer may address this checkpoint. Otherwise, one or more groups will find it somewhat difficult to access information in the document. Satisfying this checkpoint will improve access to Web documents.

This side-by-side comparison looks first at the Priority 1 WCAG checkpoints (The WCAG View) and compares each with with relevant Section 508 web standards. On the other hand, the Section 508 View lists all the 508 web standards and compares these WCAG checkpoints; some checkpoints of Priority 2 and 3 are related to the 508 standards.

 

Implementation Resources

The Web Content Accessibility Guidelines are keyed to a techniques document, Techniques for Web Content Accessibility Guidelines 1.0, which gives techniques for supporting each checkpoint. In addition there are training resources on the WAI site.

The Access Board has released an informative guide to the web standards which is linked to by the Access Board Section 508 site. The individual 508 web standards in the tables below are linked to that document. The Information Technology Technical Assistance and Training Center (ITTATC) was funded to support Section 508. There are many resources available on the ITTATC site. A tutorial on web accessibility for section 508 was written for ITTATC and will soon be available on their site. Until then, see https://jimthatcher.com/webcourse1.htm.

IBM also offers guidelines for web accessibility. The IBM Web Accessibility Guidelines include documentation on rationale, implementation techniques and testing. The IBM site includes links to other resources, as does the Web Accessibility Initiative site.

 

The WCAG View

NOTE: Four WCAG Priority 1 checkpoints, 1.3, 4.1, 6.2 and 14.1, are listed as "not in 508" in the Comparison column of this table. If a web site is 508-compliant and its author wants to be Web Accessibility Initiative A-Compliant as well, these are the only four checkpoints he must address additionally.

Keywords WCAG Priority 1 Comparison Section 508

Text Equivalent

1.1 Provide a text equivalent for every non-text element (e.g., via "alt", "longdesc", or in element content). This includes: images, graphical representations of text (including symbols), image map regions, animations (e.g., animated GIFs), applets and programmatic objects, ascii art, frames, scripts, images used as list bullets, spacers, graphical buttons, sounds (played with or without user interaction), stand-alone audio files, audio tracks of video, and video.

Similar

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

 

The Section 508 standard uses the exact language of WCAG Checkpoint 1.1 without "This includes" of WCAG 1.1. Given the decision of the Access Board to use the WCAG wording, it follows that the examples of "non-text elements" in WCAG 1.1 apply to Section 508 1194.22 (a) as well. This is further confirmed in the discussion that precedes the standards mentioning audio as an example on non-text elements.

The Board also interprets this provision to require that when audio presentations are available on a web page, because audio is a non-textual element, text in the form of captioning must accompany the audio, to allow people who are deaf or hard of hearing to comprehend the content.

It was an error to refer to captioning of audio in the final standards. The guides to the standards clarify this (see §1194.22(b)).

If a website offers audio files with no video, do they have to be captioned?

No, because it is not multimedia. However, since audio is a non-text element, a text equivalent, such as a transcript, must be available. Similarly, a (silent) web slide show presentation does not need to have an audio description accompanying it, but does require text alternatives to be associated with the graphics.

For spacer images, those used for formatting output, the text equivalent is the empty string, alt="", and that is the alternative text that should be associated with those images.

The issue of text equivalents for scripts, applets and programmatic objects is quite a different matter. It is rare that there is such a thing as a "text equivalent" for one of these programmatic objects. Such is often interpreted as a functional description of the object, as in "this applet provides an interface for logging in so as to view your 401K account."

The picture is complicated by the role of such extensions to HTML in WCAG 1.0 compared to that in Section 508. For the former the pages must be usable with scripts and applets turned off or not supported. This makes the importance of the "text equivalent" much greater for WCAG compliance compared with Section 508. For section 508 these extensions must be accessible (see Paragraphs 1194.22 (l) and 1194.22 (m)).

Server-Side Image Maps

1.2 Provide redundant text links for each active region of a server-side image map.

The Same

1194.22 (e) Redundant text links shall be provided for each active region of a server-side image map.

Keywords WCAG Priority 1 Comparison Section 508

Auditory description

1.3 Until user agents can automatically read aloud the text equivalent of a visual track, provide an auditory description of the important information of the visual track of a multimedia presentation.

Not in 508

 

 

By WCAG 1.1 and 1.4 (Section 508 1194.22 (a) and (b)) video must have a synchronized text equivalent. Given the web environment it is natural to assume that the synchronized text equivalent could be displayed in a window next to (or above or below) the video just like captions. The problem addressed by WCAG 1.3 is that blind users, for whom this is important, do not today have access to that text; their screen readers won't read the descriptions of the video. Until they do, WCAG 1.3 requires that the text description of the video be presented in audio.

Video on the web which has text descriptions of important video information will conform to the Section 508 web standards.

However, in the discussion of the standards, the Access Board specifically referred to the multi-media section of the standards:

The Board did not adopt WCAG 1.0 Checkpoint 1.3 which provides that "[u]ntil user agents can automatically read aloud the text equivalent of a visual track, provide an auditory description of the important information of the visual track of a multimedia presentation...." Although the NPRM did not propose addressing this issue in the web section, there was a similar provision in the multi-media section of the NPRM.

Indeed there is a similar provision in the final rule as well. Paragraph 1194.24 (d) of the multi-media section (cited above) requires that training and informational multi-media productions which support the agency's mission shall have audio descriptions.

Synchronized multi-media

1.4 For any time-based multi-media presentation (e.g., a movie or animation), synchronize equivalent alternatives (e.g., captions or auditory descriptions of the visual track) with the presentation.

The Same

1194.22 (b) Equivalent alternatives for any multi-media presentation shall be synchronized with the presentation.

Color

2.1 Ensure that all information conveyed with color is also available without color, for example from context or markup.

The Same

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

Keywords WCAG Priority 1 Comparison Section 508

Natural Language

4.1 Clearly identify changes in the natural language of a document's text and any text equivalents (e.g., captions).

Not in 508

 

 

The Access Board determined that:

  1. The intent of 4.1 is to for web authors to indicate change in natural language with markup (lang="en"), not using in-line text, like "the following is in German."
  2. Not many assistive technologies support language change markup.

Based on that determination, the Access Board decided not to include this checkpoint as a standard for Section 508.

Table Headers

5.1 For data tables, identify row and column headers.

The Same

1194.22 (g) Row and column headers shall be identified for data tables.

Complex Tables

5.2 For data tables that have two or more logical levels of row or column headers, use markup to associate data cells and header cells.

The Same

1194.22 (h) 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.

Style Sheets

6.1 Organize documents so they may be read without style sheets. For example, when an HTML document is rendered without associated style sheets, it must still be possible to read the document.

The Same

1194.22 (d) Documents shall be organized so they are readable without requiring an associated style sheet.

Dynamic Content

6.2 Ensure that equivalents for dynamic content are updated when the dynamic content changes.

Not in 508

 

 

The Access board did not include this checkpoint in the Section 508 standards for web accessibility because it was deemed unclear.

The purpose of Checkpoint 6.2 is to to back up other checkpoints, like 6.3, that require text alternatives for dynamic content. Checkpoint 6.2 says the text alternatives must be kept up-to-date. The techniques document for this checkpoint (http://www.w3.org/TR/WCAG10-HTML-TECHS/#scripts-alt) gives an example of using the NOSCRIPT element displaying sports scores in a definition list while the script would present the scores in a "bill board." This checkpoint requires that these two presentations are displaying the same scores.

Another example of this, my favorite, is a JavaScript function that displays the date the page was last updated at the bottom of a web page by querying the file date. This can ensure that the update information is current without having to change the update information every time the page is modified. But if you use the NOSCRIPT option as a text alternative to that dynamic content, the NOSCRIPT content would have to be updated every time the page was modified by this checkpoint, thereby nullifying the usefulness of the script.

Keywords WCAG Priority 1 Comparison Section 508

Scripting

6.3 Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page.

WCAG more restrictive

1194.22 (l) 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.

1194.22 (m) 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 §1194.21(a) through (l).

 

The WCAG checkpoint is much easier to interpret; your pages have to be usable when scripts, applets and other programmatic objects are turned off. If your page satisfies this checkpoint then it is likely that you also satisfy the corresponding Section 508 standards cited above.

However, the presumption of the Section 508 standards is that scripting, applets and other programmatic objects will be turned on (and supported) and those all must be accessible. So, if your site uses scripting just for visual enhancements, like changing text attributes when the mouse moves over text, then the site satisfies both WCAG 6.3 and Paragraph 1194.22 (l).

If you use "fly-over" menus implemented in JavaScript, and all the submenu items are available as normal text links, then the site satisfies both 6.3 and 1194.22 (l).

However, if you use Document.write to place (important) text on your page while it is loading, then it will be functional text available to assistive technology. Assuming that the text is important, the site fails WCAG 6.3 but passes 1194.22 (l).

Flicker

7.1 Until user agents allow users to control flickering, avoid causing the screen to flicker.

508 More Specific

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

 

The Section 508 standard 1194.22(j) is intended to be consistent with WCAG checkpoint 7.1 adding only a specific range of frequencies to be avoided. In particular, the Access Board stated in the final rule:

Paragraphs (j) and (k) are meant to be consistent with similar provisions in the WCAG 1.0, however, the final rule uses language which is more consistent with enforceable regulatory language.

It can be argued that 1194.22(j) is actually more restrictive because most flickering can be controlled in the major browsers by pressing the Escape key.

Keywords WCAG Priority 1 Comparison Section 508

Client Side Image Maps

9.1 Provide client-side image maps instead of server-side image maps except where the regions cannot be defined with an available geometric shape.

The Same

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.

Text only last resort

11.4 If, after best efforts, you cannot create an accessible page, provide a link to an alternative page that uses W3C technologies, is accessible, has equivalent information (or functionality), and is updated as often as the inaccessible (original) page.

The Same

1194.22 (k) 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.

Frames

12.1 Title each frame to facilitate frame identification and navigation.

The Same

1194.22 (i) Frames shall be titled with text that facilitates frame identification and navigation.

 

For both of these requirements, be sure to include meaningful name and title attributes on frame elements.

Clear Language

14.1 Use the clearest and simplest language appropriate for a site's content.

Not in 508

 

 

The Access Board decided against including this checkpoint as a standard for web accessibility because it was deemed too difficult to enforce. The requirement to use clearest and simplest language can be very subjective.

 

The Section 508 View

NOTE: If a web site is WCAG A-Compliant and its author wants to be Section 508 compliant as well, these are the five standards he must address additionally. These are paragraphs 1194.22 (l), (m), (n), (o), and (p).

Keywords Section 508 Comparison WCAG

Text Equivalent

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

Similar

1.1 Provide a text equivalent for every non-text element (e.g., via "alt", "longdesc", or in element content). This includes: images, graphical representations of text (including symbols), image map regions, animations (e.g., animated GIFs), applets and programmatic objects, ascii art, frames, scripts, images used as list bullets, spacers, graphical buttons, sounds (played with or without user interaction), stand-alone audio files, audio tracks of video, and video.

 

The Section 508 standard uses the exact language of WCAG Checkpoint 1.1 without "This includes" of WCAG 1.1. Given the decision of the Access Board to use the WCAG wording, it follows that the examples of "non-text elements" in WCAG 1.1 apply to Section 508 1194.22 (a) as well. This is further confirmed in the discussion that precedes the standards mentioning audio as an example on non-text elements.

The Board also interprets this provision to require that when audio presentations are available on a web page, because audio is a non-textual element, text in the form of captioning must accompany the audio, to allow people who are deaf or hard of hearing to comprehend the content.

It was an error to refer to captioning of audio in the final standards. The guides to the standards clarify this (see 1194.22 (b))

.

If a website offers audio files with no video, do they have to be captioned?
No, because it is not multimedia. However, since audio is a non-text element, a text equivalent, such as a transcript, must be available. Similarly, a (silent) web slide show presentation does not need to have an audio description accompanying it, but does require text alternatives to be associated with the graphics.

For spacer images, those used for formatting output, the text equivalent is the empty string, alt="", and that is the alternative text that should be associated with those images.

The issue of text equivalents for scripts, applets and programmatic objects is quite a different matter. It is rare that there is such a thing as a "text equivalent" for one of these programmatic objects. Such is often interpreted as a functional description of the object, as in "this applet provides an interface for logging in so as to view your 401K account."

The picture is complicated by the role of such extensions to HTML in WCAG 1.0 compared to that in Section 508. For the former the pages must be usable with scripts and applets turned off or not supported. This makes the importance of the "text equivalent" much greater for WCAG compliance compared with Section 508. For section 508 these extensions must be accessible (see Paragraphs 1194.22 (l) and 1194.22 (m)).

Keywords Section 508 Comparison WCAG

Synchronized multi-media

1194.22 (b) Equivalent alternatives for any multi-media presentation shall be synchronized with the presentation.

The Same

1.4 For any time-based multi-media presentation (e.g., a movie or animation), synchronize equivalent alternatives (e.g., captions or auditory descriptions of the visual track) with the presentation.

Color

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

The Same

2.1 Ensure that all information conveyed with color is also available without color, for example from context or markup.

Style Sheets

1194.22 (d) Documents shall be organized so they are readable without requiring an associated style sheet.

The Same

6.1 Organize documents so they may be read without style sheets. For example, when an HTML document is rendered without associated style sheets, it must still be possible to read the document.

Server-Side Image Maps 1194.22 (e) Redundant text links shall be provided for each active region of a server-side image map. The Same 1.2 Provide redundant text links for each active region of a server-side image map.

Client Side Image Maps

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.

The Same

9.1 Provide client-side image maps instead of server-side image maps except where the regions cannot be defined with an available geometric shape.

Table Headers

1194.22 (g) Row and column headers shall be identified for data tables.

The Same

5.1 For data tables, identify row and column headers.

Complex Tables

1194.22 (h) 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.

The Same

5.2 For data tables that have two or more logical levels of row or column headers, use markup to associate data cells and header cells.

Frames

1194.22 (i) Frames shall be titled with text that facilitates frame identification and navigation.

The Same

12.1 Title each frame to facilitate frame identification and navigation.

Keywords Section 508 Comparison WCAG

Flicker

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

508 More Specific

7.1 Until user agents allow users to control flickering, avoid causing the screen to flicker.

 

The Section 508 standard 1194.22(j) is intended to be consistent with WCAG checkpoint 7.1 adding only a specific range of frequencies to be avoided. In particular, the Access Board stated in the final rule:

Paragraphs (j) and (k) are meant to be consistent with similar provisions in the WCAG 1.0, however, the final rule uses language which is more consistent with enforceable regulatory language.

It can be argued that 1194.22(j) is actually more restrictive because most flickering can be controlled in the major browsers by pressing the Escape key.

Text only last resort

1194.22 (k) 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.

The Same

11.4 If, after best efforts, you cannot create an accessible page, provide a link to an alternative page that uses W3C technologies, is accessible, has equivalent information (or functionality), and is updated as often as the inaccessible (original) page.

Scripting

1194.22 (l) 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.

WCAG more restrictive

6.3 Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page.

6.4 For scripts and applets, ensure that event handlers are input device-independent. (Priority 2)

8.1 Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies [Priority 1 if functionality is important and not presented elsewhere, otherwise Priority 2.]

9.3 For scripts, specify logical event handlers rather than device-dependent event handlers. (Priority 2)

 

As discussed in "The WCAG View" table, if pages satisfy Checkpoint 6.3, it means that scripts are not involved with essential or important content (not conveying information) and thus would not require text that can be accessed by assistive technology. They would pass 1194.22(l).

Two of the WCAG Priority 2 checkpoints (6.4 and 9.3) stress the need for accessibility of event handlers, primarily for keyboard access. This focus is not reflected in the Section 508 Web standards. Note that keyboard access is required in the software standards, 1194.21(a), but that does not apply to web content.

The most important comparison between the Section 508 standard for scripts and the checkpoints of WCAG is the Priority 2/1 Checkpoint 8.1 which requires that scripts be directly accessible or compatible with assistive technology. My interpretation of "compatible with assistive technology," is that it is essentially that which Paragraph 1194.22 (l) requires. If Checkpoint 6.3 were not present, I would say that the requirements on scripts from the Web Accessibility Initiative (including Priority 2) is similar to that from Section 508.

However, there is a puzzling inconsistency in the WCAG checkpoints. Checkpoint 8.1 is listed with the Priority 2 items, yet for important functionality it is supposed to be Priority 1. On the other hand, checkpoint 6.3 (Priority 1) requires that pages be usable with scripts and applets turned off. It seems to me that Checkpoint 6.3 trumps Checkpoint 8.1 and important scripts are not allowed, whereas accessible scripts (those satisfying 8.1) are allowed by 1194.22 (l).

Keywords Section 508 Comparison WCAG

Applets and plug-ins

1194.22 (m) 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 §1194.21(a) through (l).

Similar

6.3 Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page. (Priority 1)

6.4 For scripts and applets, ensure that event handlers are input device-independent. (Priority 2)

8.1 Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies [Priority 1 if functionality is important and not presented elsewhere, otherwise Priority 2.]

 

The intent of the Section 508 software standards ( §1194.21(a) through (l)) is to have specific requirements that will insure that software is directly accessible and/or compatible with assistive technology. Thus, if web sites satisfy 1194.22 (m) then they will comply with WCAG checkpoints 6.4 and 8.1. However, they will not necessarily comply with the Priority 1 WCAG checkpoint 6.3.

Forms

1194.22 (n) 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.

Similar

10.2 Until user agents support explicit associations between labels and form controls, for all form controls with implicitly associated labels, ensure that the label is properly positioned. (Priority 2)

12.4 Associate labels explicitly with their controls. (Priority 2)

9.3 For scripts, specify logical event handlers rather than device-dependent event handlers. (Priority 2)

 

The key to accessible forms is for a person using assistive technology to be able to identify the purpose of any form control element and to be able to manipulate it. Knowing the intent of the input element is the purpose of WCAG Priority 2 checkpoints 10.2 and 12.4. WCAG checkpoint 9.3 would ensure that the form can be manipulated with the keyboard.

Skip Navigation

1194.22 (o) A method shall be provided that permits users to skip repetitive navigation links.

Related to WCAG but Section 508 more specific

13.5 Provide navigation bars to highlight and give access to the navigation mechanism. (Priority 3)

13.6 Group related links, identify the group (for user agents), and, until user agents do so, provide a way to bypass the group. (Priority 3)

 

The "skip navigation" provision of the Section 508 Standards is related to a couple of Priority 3 WCAG checkpoints, but the Section 508 standard is specific and direct. The WCAG checkpoints assume technology not yet supported, like grouping and labeling links.

Timed Responses

1194.22 (p) When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required.

Not in WCAG

 

 

There are not comparable checkpoints in the Web Content Accessibility Guidelines.

 

Skip Sidebar.

Popular Pages

: