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

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.

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.

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.

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

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.

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

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

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.

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

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.

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.

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.

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