Principle 1: Content must be perceivable.
|
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.
|
|
There is a major question for text alternatives now: if the non-text content is accessible, is a text alternative required in the HTML? For instance, if you a multimedia file with captions and descriptions, or an accessible Flash file, do you need a separate text alternative as well? In the past the answer would have been yes because of the possibility the user's AT does not support the accessibility features of technology. Do we still take that stance for HTML, or do we take a broader view that as long as the content is in some way accessible, natively or via text alternatives in the HTML, it passes WCAG? |
Level
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).
|
|
|
Level
1
: 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.
|
|
I tend to think of alt text for submit buttons as being a label issue than a alt text issue, but mapped it here for now. |
Level
3
: A text document (for example, a movie script) is provided that includes all important visual information, dialogue, and other important sounds.
|
|
This mapping is basically saying that long description of anything is a Level 3 issue, hence hardly ever required in practice. |
1.2: Provide synchronized media equivalents for time-dependent presentations.
|
|
|
Level
1
: An audio description of visual events is provided for audio-visual media.
|
|
|
Level
1
: Captions are provided for all significant dialogue and sounds in time-dependent material.
|
|
|
Level
1
: Descriptions and captions are synchronized with the events they represent.
|
|
|
Level
1
: If the Web content is real-time video with audio, real-time captions are provided.
|
|
|
Level
1
: If the Web content is real-time, non-interactive video (for example, a Webcam view of surrounding conditions such as weather information), then one of the following is provided:
|
|
|
Level
1
: 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.
|
|
|
Level
2
: Synchronized captions are provided for all real-time broadcasts.
|
|
|
1.3: Ensure that information, functionality, and structure are separable from presentation.
|
|
|
Level
1
: Structures and relationships within the content can be derived programmatically.
|
|
|
Level
1
: Emphasis can be derived programmatically.
|
|
|
Level
1
: 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
: Information presented using color is also available without color and without having to interpret markup (for example through context or text coding).
|
|
|
1.4: In visual presentations, make it easy to distinguish foreground words and images from the background.
|
|
|
Level
1
: Any text that is presented over a background is electronically available so that it could be re-presented in a form that allows the text to be distinguished from the background.
|
|
Do we want a technique that says use HTML plus CSS instead of images? |
Level
2
: Text that is presented over a background has a contrast greater than ____ between the text and the background as measured by ___ or the resource provides a mechanism to allow the text to meet this criterion.
|
|
Do we need a technique about the "bgcolor" attribute? |
Level
3
: This item should read identically to level 2 item #1, except that it should say "in default presentation mode."
|
|
|
Level
3
: Text is not presented over a background image or pattern, or if a background image or pattern is present, the text is easily readable when the content is viewed in grayscale to determine if the background makes it difficult to identify individual characters.
|
|
We need a technique about the "background" attribute. |
1.5: In auditory presentations, make it easy to distinguish foreground speech and sounds from background sounds.
|
|
|
Level
3
: Audio content does not contain background sounds OR the background sounds are at least 20 decibels lower than the foreground audio content with the exception of occasional short sounds.
|
|
|
Principle 2: Interface elements in the content must be operable.
|
2.1: Make all functionality operable via a keyboard or a keyboard interface.
|
|
|
Level
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.
|
|
I put image map stuff here partly because Chris did. This implies that the reason for using client side image maps is keyboard access. However, I can also think of clear link text being an issue, or simply raw functionality, so I'm not exactly sure where image map techniques go.
I'm especially undertain about redundant text links for client side image maps. If CSIM is to support keyboard operability, are redundant text links to really really support it? Perhaps that should be a deprecated technique. |
Level
2
: Wherever a choice between input device event handlers is available and supported, the more abstract event is used.
|
|
We should create a technique encouraging use of HTML attributes like "onactivate". |
Level
3
: All of the functionality of the content is operable via a keyboard or keyboard interface.
|
|
I mapped this one twice because I'm not fully clear on the difference between the Level 1 and Level 3 success criteria. |
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.
|
|
|
Level
1
: 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:
|
|
|
Level
2
: The user is allowed to turn off content that blinks for more than 3 seconds.
|
|
|
Level
2
: The user is allowed to pause and/or permanently stop moving or time-based content.
|
|
|
Level
3
: 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.
|
|
|
Level
3
: Any non-emergency interruptions, such as the availability of updated content, can be postponed and/or suppressed by the user.
|
|
|
2.3: Allow users to avoid content that could cause photosensitive epileptic seizures.
|
|
|
Level
1
: Content that violates General Flash Threshold or Red Flash Threshold is marked in way that the user can access prior to its appearance.
|
|
|
Level
2
: Content does not violate the General Flash Threshold or Red Flash Threshold.
|
|
|
Level
3
: Content does not violate any of the Spatial Pattern Thresholds.
|
|
|
2.4: Facilitate the ability of users to orient themselves and move within the content.
|
|
|
Level
2
: Different structural elements look or sound different from each other and from body text.
|
|
We want a technique that essentially says "use header elements, and style them if you don't like how they look". But I'm not sure if that's exactly what this success criterion is asking. I couldn't think where else to put it. |
Level
2
: In documents greater than 50,000 words or sites larger than 50 perceived pages, at least one of the following is provided.
|
|
|
Level
2
: 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.
|
|
The technique for link groups is perhaps more general than this success criterion, I don't know if that's a problem.
Also, the technique to hide link groups doesn't seem to relate to any success criterion. I put it here so it could be with its neighbors. |
Level
3
: Information is provided that would indicate at least one logical sequence in which to read a document.
|
|
I think this technique is kind of the opposite of the success criterion. The SC says "provide a way to linearize" while the technique says "in the absence of such a method, the default linearization is ok". I think the SC should be modified to say "Tools can read the document in a logical sequence." or something. |
Level
3
: Diagrams are constructed so that they have structure that users can access.
|
|
I'm not sure if ASCII art really belongs here (it assumes it's for a diagram) but there wasn't any other place to map ASCII art. ASCII art is a general structural problem kind of thing. |
Level
3
: Logical tab order has been created.
|
|
We also need a technique about tab order for links. I think we may have removed that for a specific reason though, and should consider doing so for forms. |
Level
3
: There is a statement associated with the content asserting that items from the following list were considered:
|
|
I don't like the general approach of the guidelines requiring statement that something has been done. They should just require that it be done.
Anyway, the title element clearly maps to this success criterion. But I don't think it should be Level 3 - Level 2 at worst but really Level 1. |
Level
3
: Structural emphasis is evident on at least the following displays: black and white monitor, low resolution screens (160 x 160 pixels), "mono" audio playback devices.
|
|
I'm not sure what this means in terms of HTML. Do we assume if they have used the structural markup they have passed this? Or do we expect them to go out of their way, e.g., via CSS or something, to ensure this is the case? |
2.5: Help users avoid mistakes and make it easy to correct them.
|
|
|
Level
2
: If a user error is detected, the error is identified and provided to the user in text
|
|
|
Level
2
: If a user error is detected, and suggestions for correction are known and can be provided without jeopardizing security or purpose (for example, test validity), they are provided (in an accessible form that meets Level 1 success criteria).
|
|
|
Level
2
: Where consequences are significant and time-response is not important, one of the following is true:
|
|
|
Level
3
: Where the input options are known, there are less than 75 of them, and they can be provided without jeopardizing security, test validity, etc, users are allowed to select from a list of options as well as to enter text directly.
|
|
|
Level
3
: Checks for misspelled words are applied and correct spellings are suggested when text entry is required.
|
|
|
Principle 3: Content and controls must be understandable.
|
3.1: Ensure that the meaning of content can be determined.
|
|
|
Level
1
: The natural language of the document as a whole can be identified by automated tools.
|
|
|
Level
1
: The meaning of abbreviations and acronyms can be programmatically located.
|
|
|
Level
2
: Page titles are informative.
|
|
Note that this is a Level 2 item, but the one even requiring the page title above is a Level 3. |
Level
2
: The meanings and pronunciations of all words in the content can be programmatically located.
|
|
|
Level
2
: The meaning of all idioms in the content can be programmatically determined.
|
|
|
Level
2
: For each foreign language passage or phrase in the body of the content, the language is identified through markup or other means. Foreign passages or phrases are passages or phrases that are in a language other than the primary language of the document.
|
|
|
Level
3
: The meaning of contracted words can be programmatically determined.
|
|
|
Level
3
: Where a word has multiple meanings and the intended meaning is not the first in the associated dictionary(s), then additional markup or another mechanism is provided for determining the correct meaning.
|
|
|
Level
3
: Section headings and link text are understandable when read by themselves as a group (for example, in a screen reader's list of links or a table of contents).
|
|
|
Level
3
: There is a statement associated with the content asserting that the Strategies for Reducing the Complexity of Content (the following list) were considered.
|
|
|
3.2: Organize content consistently from "page to page" and make interactive components behave in predictable ways.
|
|
|
Level
1
: Any extreme change of context is implemented in a manner that can be programmatically identified.
|
|
|
Level
2
: Components that are repeated on multiple "pages" within a resource or a section of a resource occur in the same sequence each time they are repeated, for at least one presentation format.
|
|
|
Level
2
: All user interface components should be able to receive focus without causing activation.
|
|
|
Level
2
: Changing the setting of any input field should not automatically cause an extreme change in context such as leaving the "page."
|
|
New technique for auto-submit combo boxes. |
Level
2
: Interactive elements that appear on multiple "pages," including graphical elements, are associated with the same functionality wherever they appear.
|
|
|
Level
2
: Explicit notice is given in advance of any extreme change of context.
|
|
Our techniques kind of combine this with the "don't use popups" above. Perhaps we should split the techniques. This might be more of a General Techniques issue. |
Level
3
: The target of each link is clearly identified.
|
|
I believe this should be a Level 1 issue.
I put text links for server side image maps here as a clear link text issue, even though client side link text is treated as a keyboard access issue. There's some inconsistency there I'd like to clear up. |
Level
3
: Graphical components that appear on multiple pages, including graphical links, are associated with the same text equivalents wherever they appear.
|
|
|
Level
3
: Components that appear visually on multiple pages, such as navigation bars, search forms, and sections within the main content, are displayed in the same location relative to other content on every page or screen where they appear.
|
|
|
Level
3
: When components such as navigation menus and search forms appear on multiple pages, users can choose to have those elements presented in a different visual position or reading-order.
|
|
|
Level
3
: There are no extreme changes of context.
|
|
|
Principle 4: Content must be robust enough to work with current and future technologies.
|
4.1: Use technologies according to specification.
|
|
|
Level
1
: Except where the site has documented that a specification was violated for backward compatibility or compatibility with assistive technology, the technology has:
|
|
New technique about don't use layout tables. Does this mean that every site with layout tables would be expected to say "we use layout tables for reasons of backward compatibility?"
The technique about what's allowed in (forbidden) layout tables doesn't really belong here, but I can't think of anywhere else. |
Level
3
: Technologies are used according to specification without exception.
|
|
We need to repeat the technique about don't use layout tables, but with no wiggle room for level 3.
Does the ASCII art technique belong here? |
4.2: Ensure that user interfaces are accessible or provide an accessible alternative(s)
|
|
|
Level
1
: At least one plug-in required to access the content conforms to at least the default set of conformance requirements of the User Agent Accessibility Guidelines (UAAG) 1.0 at Level A plus the sets of requirements (a) through (j) (below) that apply. If required plug-ins are not accessible, an alternative solution is provided that conforms to WCAG 2.0. If inaccessible plug-ins are available, then a method for obtaining an accessible plug-in is provided from the content.
|
|
I think the concept of plug-ins is a big hairy issue for technology specific techniques. I would like the guidelines to simply say something like "viewers for content exist that comply with UAAG". Whether those viewers are plugins to other viewers or not is not concern at the guidelines level.
This also relates to the issue I raised above, about whether the fact that a page includes external media needs to have text alternatives in the calling page if the external media itself is accessible (and of course the plugin supports that accessibility). I think that's a very HTML-ish question and would like to see the guidelines provide a non HTML-ish answer. |
Level
1
: Any programmatic user interface components of the content conform to at least the default set of conformance requirements of the UAAG 1.0 at Level A plus the sets of requirements (a) through (j) (below) that apply. If the custom user interfaces cannot be made accessible, an alternative solution is provided that meets WCAG 2.0 (including this provision) to the level claimed.
|
|
|
Level
2
: Accessibility conventions of the markup or programming language (API's or specific markup) are used.
|
|
This really seems to me like saying "follow the WCAG". The HTML techniques define how to use accessibility conventions of HTML; if we were writing Java Techniques (which we're not) we would probably in large part just be documenting the Java Accessibility API. So I'm not sure what value a separate success criterion has. |
Level
3
: The Web resource includes a list of the technologies user agents must support in order for its content to work as intended. The list is documented in metadata if such metadata is supported by the format, otherwise it is documented in a policy statement associated with the content.
|
|
|
Level
3
: Users who do not have one or more of these technologies can still access and use the resource, though the experience may be degraded.
|
|
Perhaps this is where we say "provide text equivalents in the HTML even though the non-text content has been made accessible". |
Level
3
: Technologies and features on the required list are open standards or have a public specification.
|
|
|