The U.S. Access Board is pleased to have this opportunity to submit comments on the latest draft of the Web Accessibility Initiative's Web Content Accessibility Guidelines. The comments are based on the draft document posted on the WAI website on March 11, 2004.
This document is divided into three sections; these general comments, the Board's reactions to the specific WCAG2.0 guidelines, and finally, a mapping of the section 508 requirements and the WCAG2.0 guidelines. It now appears that harmonization between the WAI guidelines and the section 508 requirements is achievable. This harmonization is essential in light of a growing interest in developing international accessibility requirements and guidelines. To promote this concept, it will be of utmost importance for the U.S. to have internal consistency of its enforceable requirements and voluntary guidelines. The latest WAI draft demonstrates that this is a realistic goal.
Because the WAI guidelines are based on voluntary compliance, and the section 508 requirements are enforceable, the WAI guidelines can go beyond enforceable provisions for accessibility. An analogy drawn from the rules of the road for drivers can help explain this better, and also show how requirements and guidelines can successfully coexist. Local, state, and federal laws control such aspects of operating a vehicle as, no passing on a solid line, or the speed limit on a given road is 55 miles per hour. There are, however, many guidelines for safe driving that are taught by defensive driving schools and driver education classes that may not be enforceable but certainly lead to safer highways.
The Board's section 508 requirements for access to web pages represent the basic accessibility level that must be achieved by Federal websites. The WAI guidelines represent a higher level of achieving the ultimate in access. The Board believes that the ideal situation will be reached when the section 508 requirements and the WAI Web content Accessibility Guidelines are both based on a primary set of provisions. Ideally, a webpage that meets the section 508 provisions would also automatically meet a particular level of achievement for the WAI guidelines.
It is with this goal in mind that the Board submits these comments.
Principle 1: Content must be perceivable.
Guideline 1.1 For non-text content, provide text equivalents that serve the same purpose or convey the same information as the non-text content, except when the sole purpose of the non-text content is to create a specific sensory experience (for example, music and visual art) in which case a text label or description is sufficient.
Comment: Excellent, but needs to be a little clearer. What is the difference between a text equivalent and a description or label? It is hoped that this does not mean every border or spacer needs a label saying border or blank space.)
Level 1 Success Criteria for Guideline 1.1
Text-equivalents are explicitly associated with non-text content, except when the non-text content is intended to create a specific sensory experience (for example, music without words and visual art).
The text equivalent fulfills the same function as the author intended for the non-text content (that is, it conveys all of the intended information and achieves the same function as the non-text content).
Exception:
If the purpose is to let users provide the text-equivalent (for example, a spelling test) then the text-equivalent is not required.
Non-text content that is designed to create a specific sensory experience (such as music without words or visual art) has a text label or a text description explicitly associated with it.
Comment: The spelling test is a great example. However, adding label to images used strictly for layout or visual appeal only adds audio litter for anyone using a screen reader. This guideline does not seem to leave any room for a null alt attribute. Therefore, when a person seeing the screen perceives a blank region on the screen, the user of a screen reader has to hear words such as "blank space" or "spacing" meaning that for the screen reader user there really is no blank.
Level 3 Success Criteria for Guideline 1.1
A text document (for example, a movie script) is provided that includes all important visual information, dialogue, and other important sounds.
Comment: this statement could be misinterpreted as saying that it is okay to provide a script rather than captioning. Maybe a different example, such as a script for an audio only web broadcast.
Who Benefits from Guideline 1.1 (Informative)
People who are blind, have low vision, have cognitive disabilities or have trouble reading text for any reason can have the text read aloud to them by assistive technology.
People who are deaf, are hard of hearing, or who are having trouble understanding audio information for any reason can read the text presentation or have it translated and presented as sign language by assistive technology.
People who are deaf-blind can read the text in braille.
Comment: Also what about those who just like to operate with images turned off?
Examples of Guideline 1.1 (Informative)
Example 1: an image used as a button. (short equivalent for function)
A right arrow icon is used to link to the next slide in a slide show. The text equivalent is "Next Slide," so that a screen reader would read the phrase "Next Slide" and automatically identify it as a link by adding the word link or changing the synthesizer's voice.
Comment: Why not change the phrase "screen reader would read the phrase "Next Slide" and automatically identify it as a link by adding the word link or changing the synthesizer's voice." to, "people without access to the graphics can still access the function." Also, just need to make it clear that the author doesn't have to add the word "link" in the text equivalent. Telling authors to control synthesizer output or provide extraneous words is not good advice. There are many hardware and software synthesizers on the market today, Each having its own set of controls. Screenreader users can control how the synthesizer will react to different types of elements. Advising creators of web content to attempt to control a voice synthesizer can likely end up in conflicts and crashes. Also, all in use today allow users to control the verbosity of the speech. This means the user can decide whether to hear the word "link" or not. If the author places this word in the text of the link, control of verbosity is taken away from the user.
Example 2: a data chart. (short label + longer description)
A bar chart compares how many widgets were sold in June, July, and August. The short label says, "Figure one - Sales in June, July and August." The longer description identifies the type of chart or graph, provides a high-level summary of the data comparable to that available from the chart or graph, and provides the data in a table or other accessible format.
Comment: This is an excellent example.
Example 3: an animation. (short label + longer description)
An animation shows how to tie a knot. The short label says, "An animation showing how to tie a square knot." The longer explanation describes the hand movements needed to tie the knot.
Comment: An interesting example, pity the person trying to write the long description.
Example 4: An audio file is embedded in a Web page. The short label says, "Chairman's speech to the assembly." A link to a text transcript is provided immediately after the audio clip.
Comment: A minor point, why not just have a short label and the link to the transcript in one element)
Example 5: an audio file of a symphony. (short label)
An audio file is embedded in a Web page. The short label says, "Beethoven's 5th Symphony performed by the Vienna Philharmonic Orchestra."
Comment: (fine)
Guideline 1.2 Provide synchronized media equivalents for time-dependent presentations.
Comment: Excellent except it might help to say multimedia as that term will help clarify issues of what should be covered as explained below.
Level 1 Success Criteria for Guideline 1.2
An audio description of visual events is provided for audio-visual media.
Captions are provided for all significant dialogue and sounds in time-dependent material.
Descriptions and captions are synchronized with the events they represent.Exception:
A text transcript or other non-audio equivalent does not need to be synchronized with the multimedia presentation if all four of the following statements are true:
the content is real-time and
the content is audio-only and
the content is not time-sensitive and
the content is not interactiveNote:
This exception applies to both success criteria 2 and 3 above.
Comment: It appears that this exception has been made unnecessarily complex. It might be easier to have an exception under a discussion of how to handle audio only webcasts. By definitions, an audio only presentation is a single not multimedia event. So it is simple to say multimedia presentations must be captioned. Audio presentations may be accompanied by a script unless the production is interactive, i.e. expecting the audience to react during the presentation.
If the Web content is real-time video with audio, real-time captions are provided.
Exception:
If the content is a music program that is primarily non-vocal, then captions are not required.
Comment: This could be quite a source for confusion. If a performance is vocal, is it required that all the lyrics be captioned? This seems to be what is indicated.
If the Web content is real-time, non-interactive video (for example, a Web cam view of surrounding conditions such as weather information), then one of the following is provided:
a substitute that conforms to guideline 1.1 (for example, an ongoing text report of weather conditions)
a link to a substitute that conforms to guideline 1.1 (for example, a link to a weather Web site that conforms to Guideline 1.1)
Comment: By changing media to multimedia in the statement associated "guideline 1.2" the web cam issue becomes much simpler to handle as it is not a multimedia presentation. this means that you could move this discussion to the section addressing text equivalents for non-text elements.
If a presentation that contains only audio or only video requires users to respond interactively at specific times during the presentation, then a
synchronized equivalent presentation (audio, visual or text) is provided.
Comment: This statement goes back to the issue of providing non-text equivalents for audio only presentations.
As far as providing audio equivalents for video only creates quite a conundrum as explained below.
First, if the presentation is multimedia, it is reasonable to require audio descriptions of non verbal content.
However, what is a video only presentation. Most web pages are video only presentations. The output from live images is already covered. If you take the requirement, as written, to its logical conclusion, all web pages that don't have imbedded speech must have audio output added to the page. This of course is not practical or desirable.
It seems that there is confusion here between developing guidelines for web pages and guidelines for television broadcasts. The major difference being of course that you generally can't attach a screen reader to a television.
Exception:
If content that is rebroadcast from another medium or resource meets accessibility requirements for that medium, then the rebroadcast satisfies this checkpoint if it complies with other applicable sections of WCAG 2.0
Comment: This is unclear as to what conditions are being addressed.
Guideline 1.3 Ensure that information, functionality, and structure are
separable from presentation.
Comment: This is an excellent concept but as stated could be quite difficult for many to grasp. Can this be phrased differently. For example, isn't this really emphasizing that the layout and display of all functions and elements should be generated by use of markup features provided by the authoring language. In other words, as indicated below, table layouts should be created with appropriate tags rather than simple line breaks and tabs.
Level 1 Success Criteria for Guideline 1.3
The following can be derived programmatically (for example, through a markup or data model) from the content without requiring user interpretation of presentation. [I]
Hierarchical elements and relationships, such as:
paragraphs lists headings associations between table cells and their headers, Non-hierarchical relationships between elements such as:
cross-references and other associations,
associations between labels and controls,
Emphasis or other formatting of specific words, phrases, and quotes.Editorial Note: Other constructs may be added to this list in future drafts.
Any information presented through color is also available without color (for example, through context or markup or coding that does not depend on color).
Level 2 Success Criteria for Guideline 1.3
Information presented using color is also available without color and without having to interpret markup (for example through context or text coding).
Level 3 Success Criteria for Guideline 1.3
No level 3 success criteria for this guideline.
Comment: These are all good examples and emphasize the need to use structure to create the presentation.
Guideline 1.4 In visual presentations, make it easy to distinguish foreground words and images from the background.
Comment: The phrase, "make it easy" is to subjective. It is hard to imagine an author wanting to make the pages difficult to read. Maybe this guideline, along with its explanatory material, belongs in a WAI style guide.
Guideline 1.5 In auditory presentations, make it easy to distinguish foreground speech and sounds from background sounds.
Comment: (see previous comment) Again this is good advice for design whether or not accessibility is the focus. this like its visual twin belongs in a style guide.
Principle 2: Interface elements in the content must be operable.
Comment: This is incomplete. Even though the paragraphs that follow explains how to accomplish this principle, the principle, as stated, sounds like stating the obvious. Why would someone develop elements that were not operable. There needs to be some phrase added that more clearly states the goal of this principle. For example,
"Principle 2: Operation of interface elements in the content must not be dependent on a single input device."
Guideline 2.1 Make all functionality operable via a keyboard or a keyboard interface.
Comment: Not everyone can use a keyboard, maybe the concept of redundancy needs to be placed here.
Level 1 Success Criteria for Guideline 2.1
All of the functionality of the content, where the functionality or its outcome can be described in a sentence, is operable through a keyboard or keyboard interface.
Comment: This is parallel to the 508 1194.21(a) requirement. We would suggest replacing the words, "a sentence" with "text or words. The description of the functionality or outcome does not have to be a complete sentence.
Level 2 Success Criteria for Guideline 2.1
Wherever a choice between input device event handlers is available and supported, the more abstract event is used.
Comment: Please clarify, "the more abstract"
Level 3 Success Criteria for Guideline 2.1
All of the functionality of the content is operable via a keyboard or keyboard interface.
Comment: If the functionality is available through a keyboard interface, by definition isn't’t it available via a keyboard?
Guideline 2.2 Allow users to control time limits on their reading or interaction unless specific real-time events or rules of competition make such control impossible.
Comment: This is excellent, adding the concept of competition is extremely valuable.
Level 1 Success Criteria for Guideline 2.2
Content is designed so that time limits are not an essential part of interaction, or at least one of the following is true for each time limit:
the user is allowed to deactivate the time limit or;
the user is allowed to adjust the time limit over a wide range which is at least ten times the length of the default setting or;
the user is warned before time expires, allowed to extend the time limit with a simple action (for example, "hit any key") and given at least 10 seconds to respond or;
the time limit is an important part of a real-time event (for example, an auction), and no alternative to the time limit is possible or;
the time limit is part of an activity where timing is essential (for example, competitive gaming or time-based testing) and time limits can not be extended further without invalidating the activity.
Comment: The Board examined the concept of a default timeout and found that often there is no real default which means extending the time by a multiple of the default has no real meaning. The concept of allowing the user to request more time when the time is about to expire seems to be the most relevant approach.
Level 2 Success Criteria for Guideline 2.2
The user is allowed to turn off content that blinks for more than 3 seconds.
The user is allowed to pause and/or permanently stop moving or time-based content.
Level 3 Success Criteria for Guideline 2.2
The content has been designed in a way that any time limits in the content would pass level 1, success criteria 1 for this guideline without exceptions.
Comment: In the explanation of this section, reference is made to what can be summed up as dynamic content. It seems that this section is saying a user should be able to freeze dynamic content. And as pointed out by the authors, taken to its extreme, these guidelines would mean that all live presentations could be frozen or resumed by the viewer.
In our opinion, this is a stretch for timed responses. The original concept was aimed at helping those who may not be able to react fast enough before a form or dialog disappeared. Whether the concept of controlling refresh rates etc should be addressed is not the issue here. the problem here is a clouding of the main purpose of this valuable guideline by trying to have it cover to broad a group of events.
Also, we believe that trying to include blinking events as timed events is inappropriate, the concept being addressed is timed responses required of the user.
Level 1 Success Criteria for Guideline 2.3
Content that violates General Flash Threshold or Red Flash Threshold is marked in way that the user can access prior to its appearance.
Comments: It seems that there may be an organizational problem. Providing strong advice on avoiding content that may induce a seizure is essential. Maybe this issue should be addressed under "principle I." The blinking object issue is not an operable control issue except for the control to skip or stop the blinking. Several webpage trainings are now saying that you should not use blinking or scrolling text. Maybe WAI should bite the bullet and advice against the use of blinking objects.
Guideline 2.4 Facilitate the ability of users to orient themselves and move within the content.
Level 1 Success Criteria for Guideline 2.4
No level 1 success criteria for this guideline.
Level 2 Success Criteria for Guideline 2.4
Different structural elements look or sound different from each other and from body text.
In documents greater than 50,000 words or sites larger than 50 perceived
pages, at least one of the following is provided.
Editorial Note: What's a perceived page? What if it's a voice XML application?
How does it apply to Web applications? Why 50 and 50,000?
hierarchical structure,
table of contents (for pages) or site map (for sites),
alternate display order (for pages) or alternate site navigation mechanisms (for sites).
Large blocks of material that are repeated on multiple pages, such as
navigation menus with more than 8 or more links, can be bypassed by people who use screen readers or who navigate via keyboard or keyboard interface.
Comment: It must be noted that this is, for the most part usability not accessibility. Even the reference to skipping navigational links that parallels a similar 508 requirement is more of a usability issue. The board kept that provision in as recommended by its advisory committee because of the ease of implementation.
Level 3 Success Criteria for Guideline 2.4
Information is provided that would indicate at least one logical sequence in which to read a document.
Diagrams are constructed so that they have structure that users can access.
Logical tab order has been created.
Comment: Logical order is purely subjective.
Guideline 2.5 Help users avoid mistakes and make it easy to correct them.
Comment: This is a lofty goal but seems impractical and does not belong in this document.
Principle 3: Content and controls must be understandable.
Comment: The Board has no comments under this principle as it is believed these are highly subjective and may provide the content for an excellent style guide for all webpage authoring regardless of access issues.
Principle 4: Content must be robust enough to work with current and future technologies.
Comment: This seems to be an impossible goal as it is very difficult to predict the future of technology, yet this principle asks all web authors to do just that. Around fifteen years ago, Dr. Lawrence Scadden learned on a trip to Germany that several centers who were training blind workers to use computers were thinking of closing. They felt that with the advent of the GUI, computer usage would soon not be practical for a blind worker. Therefore, to adjust for future technologies they came close to doing their blind population a genuine disservice.
From the Board's perspective this principle is not enforceable or testable except through the use of 20/20 hindsight..
Guideline 4.1 Use technologies according to specification.
Comment: Yes, coding that breaks the rules of the language being used will effect access, but in truth putting accessibility aside nonstandard coding is generally considered poor design.
Guideline 4.2 Ensure that user interfaces are accessible or provide an accessible alternative(s)
Comment: This guideline is very close to 508 web provision 1194.22 (m) which also addresses the need for accessible plug-. Suggests moving this guideline from under this principle to a location under principle 1. The accessible plug-in would be required to make content perceivable.
508 (a) equivalent for every non-text element shall be provided (e.g., via "alt", "longdesc", or in element content).
(e) Redundant text links shall be provided for each active region of a server-side image map.
(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.
508; (c) Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup.
508; (d) Documents shall be organized so they are readable without requiring an associated style sheet.
508; (g) Row and column headers shall be identified for data tables.
508; (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.
508; (i) Frames shall be titled with text that facilitates frame identification and navigation.
508: (b) Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation.
(note, the following two 508 requirements are from the section on multimedia that also apply to multimedia presentations on the web.)
(c) All training and informational video and multimedia productions which support the agency's mission, regardless of format, that contain speech or other audio information necessary for the comprehension of the content, shall be open or closed captioned.
(d) All training and informational video and multimedia productions which support the agency's mission, regardless of format, that contain visual information necessary for the comprehension of the content, shall be audio described.
508 (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.
(note, To meet a publishing time limit, refinements to this provision did not get completed. However, in the Boards technical assistance the issue of keyboard activation for scripts is addressed.)
508 (p) When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required.
508 (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; (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).
508; (o) A method shall be provided that permits users to skip repetitive navigation links.
(note) In the current draft of the WAI guidelines, there is no provision for a text alternative page. However, comments in the document indicate that adding this guideline may be done in the future.
Therefore, the one 508 requirements that has no WCAG2.0 equivalent is:
(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.