Disposition of comments for the Accessibility Guidelines Working Group

This success criterion delivers less in the user experience than UAAG 1.0, checkpoint 3.1. UAAG makes this subject to user profiling.

Single-switch users, for example, rely on context changes that are animated by the system, not triggered one by one by the user.

Low-vision users will come down on different sides of this question depending on how much of the content they can see at once and how much of the session structure they can hold in their head.

Proposed Change:

Best
Make equivalent facilitation (now 4.2) a principle. Include user configuration of the user experience under one of the forms of alternative recognized. State user experience requirements separately; define these by reference to UAAG 1.0. State data-on-the-wire requrements separately. These have two options:

turnkey format -- player meets UAAG requirements directly.
open format -- format populates machinable content model (c.f. rewritten 4.1) with information and actions that let UA manage and provide this capability.

2.3.2: This should be L2 or there should be a L2 equivalent

Proposed Change:

Create L2 equivalent

Images for markup: Seeing as this WCAG1 checkpoint does not map to a particular SC, does this mean that WCAG2 allows images to be used instead of markup, for example, images of text, instead of CSS-manipulated text? Or images for bullets instead of marked up bulleted lists?

Proposed Change:

Clarify the mapping of 3.1.

Properly positioned labels: 10.2 no longer maps to any particular SC. Although this checkpoint was included in WCAG1 to assist people who use screen readers, prior to the uptake of explicit labelling, this is still a very important SC for people who use magnifiers and people with cognitive disabilities.

Proposed Change:

Create a new SC the equivalent of 10.2 (I am happy to write this)

Definition of USER AGENT is "any software that retrieves and renders Web content for users". In several places it is emphasized that this includes assistive technology, but this definition seems to exclude many types of assistive technology such as speech recognition used for command-and-control, which neither retrieves nor renders, but does rely on access to the information being rendered. Also, the word "retrieves" seems to imply fetching from some remote source (e.g. over the Web), which would exclude screen readers; on the other hand, "retrieves" could be taken to mean getting the data from anywhere, including from another user agent, but by that interpretation a display driver would count as assistive technology.

Proposed Change:

Change to read "any software that retrieves and renders Web content for users, or manipulates such content to assist the user in using the Web content or controls"

4.1.2: What is the "name" or the "role"? What does it mean "values can be set by the user"?

Proposed Change:

Rewrite SC 4.1.2

Definition of accessibility - In the Baseline document (under the heading 'If the WCAG does not set the baseline, then how can we be sure that a site will be accessible?) it says "No site or content is ever completely accessible". In the Conformance document it says "Note that even conformance to all three levels will not make web content accessible to all people." I strongly object to these statements. All content can be made accessible. In some cases, content may not be accessible, but if the problems were identified it could be made accessible. As the main body representing accessibility I think it reprehensible that we have these statements.

Proposed Change:

Remove the statements. Merge Level 1 and Level 2 SC into one group called 'Mandatory'. Rename Level 3 to 'Advisory' or 'Optional'

2.4.7: This should be at Level 1. Determining the current location is sometimes very difficult for both people who use screen readers and people with cognitive disabilities

Proposed Change:

Move to Level 1

2.5.4: This should be Level 1. Context sensitive help is very important to people who use screen readers and people with cognitive disabilities.

Proposed Change:

Move to Level 1

3.1.4: If information is provided in an abbreviated form without expansion, then the content is essentially inaccessible to people that cannot interpret the abbreviation. People who use screen readers and people with cognitive disabilities often have difficulties interpreting abbreviations.

Proposed Change:

There should be a Level 1 version of this SC which requires that important abbreviated information is marked up, or expanded the first time it is used in a page

3.2.1 & 2.2.5: From my reading, 3.2.1 outlaws changes of context when a component receives focus, but 2.2 allows changes in content for no reason (only outlawing at L3)

Proposed Change:

Rewrite SC 3.2.1 and 2.2.5

4.1: There should be (preferably at Level 1) a requirement for content to validate

Proposed Change:

Create a Level 1 SC requiring validation

2.2.6: This should be at Level 2. If someone is using an authenticated session and cannot complete the information before automatic logoff, then being able to continue after re-login is imperative in order to use the system. Otherwise the system is inaccessible

Proposed Change:

Move 2.2.6 to Level 1

Navigation is a User Agent function enabled by structure in the content. This is not a content guideline, but a user experience requirement handled in the User Agent.

Proposed Change:

Replace with a narrower provision that says "navigation paths defined in the content encoding correspond to the logical order information which is the subject of 1.3.3"

Term: Programmatically determined - The definition for "programmatically determined" is "determined by software from data provided in a user-agent supported manner such that the user agents can extract and present this information to users in different modalities". What is the definition by "user agent supported manner"? Does this mean that even if only one user agent on only on version of an operating system can extract the information then it complies? What about people with colour blindness? If faced with an image they can't interpret due to colour blindness, they could just use a colour picker tool which will tell them the hex values of each pixel and determine the contents of an image that way.

Proposed Change:

Redefine SC that use the term programmatically determined

Stylesheets: It could be argued that the sequence of content can always be programmatically determined- otherwise it could not be presented to the user in that particular sequence. Because 1.3.3 maps to checkpoint 6.1, it is obvious that what is meant by the WCAG2 SC is that if style sheets are used to manipulate the layout of text, then the layout without style sheets must present a meaningful alternative. However it can be argued that simply because a user agent (ie browser) can interpret the style sheet to present information in a certain way, that it is automatically programmatically determinable.

Proposed Change:

Clarify the SC 1.3.3

Baseline CSS: This mapping essentially says that if CSS is in the baseline then information can be put into the style sheet and not in the HTML. This appears to allow formatting (ie headings) via CSS and not HTML, important images included in CSS and not HTML, etc. How is someone who uses a screen reader going to interpret this? How are they going to be able to access the information they require?

Proposed Change:

Clarify baseline requirements

1.4.2 requires a mechanism to turn off "background audio that plays automatically, without requiring the user to turn off all audio". This is good except that "background audio" is not defined. Is it audio that is played at the same time as other audio, but is considered to be less important (i.e. background behind other audio)? Or Is it audio that is purely decorative and/or atmospheric, but not required for understanding or use of the web unit (regardless of whether other audio is playing)?

Proposed Change:

Define "background audio", or change "background audio" to either "audio" or "purely decorative audio".

2.2.3. requires that content can be paused by the user (barring certain exceptions). Pausing, as opposed to Stopping, implies there is UI to un-pause the content. Would it be acceptable to allow decorative content to be stopped, but not provide UI to resume it? The current wording would preclude that.

4.1.1 requires that Web content to be parsed unambiguously. Does this require the formal specifications be open, so that new user agents can parse the content? For example, suppose the baseline specifies just one Web browser, that implements rules for applying defaults to resolve any potential ambiguities in HTML that might be interpreted differently if another browser were used; is the HTML parsable unambiguously within the scope of the baseline? As another example, suppose a Web uses a proprietary data format that only a single plug-in can render; does it matter if it's parsable unambiguously if there is only one renderer?

Proposed Change:

Insert the phrase ", using publicly available specifications", to read "Web units or authored components can be parsed unambiguously, using publicly available specifications, and the relationships in the resulting data structure are also unambiguous.

Definition of CONTENT currently reads ""information to be communicated to the user by means of a user agent"" and has a Note which reads ""This includes the code and markup that define the structure, presentation, and interaction, as well as text, images, and sounds that convey information to the end-user."".

Content is defined as being limited to ""information"", but the definition of ""information"" seems to exclude purely decorative elements and elements who purpose is to create a specific sensory experience; both of those are distinguished from informational content in the document, but seem to clearly be part of the content. That should be acknowledged here.

(Content also include controls whose purpose is to gather input from the user, but I guess we don't need to call those out since they must also have some presentation.)

Similarly, the Note seemt to say that scripts included in a Web page are part of the content, but these don't fit into the definition of ""information"" as they might respond to user input or other triggers, without having any presentation of their own. Thus, the Note seems to contradict the definitions themselves.

It is unfortunate that the document defines ""information"", ""purely decorative elements"", and content ""designed to create a specific sensory experience"" as mutually exclusive, with no term that currently includes them all. I believe that ""content"" should be that term, but it would require broadening the definition of ""content"" beyond just ""information"" or broadening the definition of ""information"".

Proposed Change:

Change to "information and decorative or sensory elements to be communicated to the user by means of a user agent, as well as code or markup that define the stucture, presentation, and interactions associated with those elements".

Definitions of TEXT and NON-TEXT CONTENT is ambiguous about whether an image of text is text or non-text content. Please add clarification. This is a problem because most success criteria are written assuming that "text" is parsable by assistive technology (i.e. not just a picture of characters) (e.g. "text alternatives"), but others seem to only require that "text" be readable by humans (i.e. it can be just an image of characters) (e.g. captions on DVDs).

Proposed Change:

Add to the definition of non-text content, "Note: This includes images of words and characters that may look like text when viewed with human sight but are not programmatically accessible."

Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):

This Criterion states that \"Context-sensitive help is available for text input\". The accompanying advice on how to meet this criterion seems to suggest that such help must be available for ALL text input fields.
If it is sufficient, to meet this criterion, to have clear labels for all text input fields, then you can ignore my comments here. However, if the guidelines are suggesting that there needs to be specific help text for every text-entry field, AS WELL AS a clear label, then please read on!
As a professional and experienced questionnaire designer, I feel this is unreasonable and may in fact hinder usability for all users, not just those with a disability, and reduce data quality.
It is well documented that providing examples for a question can, in fact, reduce the accuracy of the response because users tend to limit their thinking to just those provided examples. Moreover, good form design notes that the information required to provide a response should ideally be located with the label for that response field (ie don\'t separate instructions from the relevant questions). As such, authors should be incorporating all the information that is needed into the label/question, rather than providing some information in a separate area.

Add to this the fact that there isn\'t much useful help that can be added to many text fields. For example, what help would you give for your own text field \"Proposed Change\" below? Adding text along the lines of \"Please type here a description of the change that you think we should make\" is superfluous, patronising and degrades the user experience. Please let us not return to the bad old days where even fields such as \"Family Name\" had an instruction that consequently made users feel like idiots, and contributed to the instruction blindness that is prevalent today.

Proposed Change:

Reword the criterion or its associated documentation to make it clear that:
- in all cases, the label for the text entry field must clearly communicate what sort of information should be provided in the field
- additional context-sensitive help need only be provided where it is reasonably required to explain what is to be entered, or to minimise the burden on the user.

Part of Item:
Comment Type: substantive
Comment (including rationale for proposed change):

The definition for assistive technology is difficult to understand because it gives the restrictive before the general meaning; also, it may be too restrictive, in describing legacy assistive technologies (for instance, some screen readers now are creating their own DOM separate from the mainstream browser).


Proposed Change:

EOWG recommends eliminating part (1) of the definition. (Note: We think that this would work *because* your definition of user agent is broad enough to already cover some of the functions of some assistive technologies.)

Response: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0405.html

This is a placeholder issue, used to support a feature that allows us to edit multiple issues at once. Please do not delete.

2.4.4 & 2.4.8: 2.4.8 should move to Level 1 and replace 2.4.4. People who use screen readers often navigate through a page by tabbing from link to link and therefore can determine the content on the page. Allowing for link text to not describe the target of the link means that these users will find it difficult to navigate.

Proposed Change:

Move to Level 1 and delete 2.4.4

2.5: There should be a Level 1 SC which requires error prevention techniques, such as providing instructions at the beginning of a form

Proposed Change:

Create a new SC. I am happy to help with this

4.1.1: How is this to be tested?

Proposed Change:

Provide information

Definition of API is defined as "definitions of how communication may take place between applications", but that should be "between application or software components", as most API are used between components that are not applications, and we don't want to limit our discussion to only those API that are between one application and another.

Proposed Change:

Change to "definitions of how communication may take place between applications or software components".

Definition of ASSISTIVE TECHNOLOGY is defined as "a user agent that: 1... 2 ..."; in all cases where a list of criteria is presented, it should be made explicit whether the relationship between the elements in the list is AND or OR.

Proposed Change:

Change "a user agent that:" to "a user agent that both:".
Change "monitoring APIs." to "monitoring APIs, and".

The non-text content must be implemented such that it can be ignored anyway, even if the text equivalent provides full equivalent
facilitation. You can't have the video frame-change events capturing the AT's attention, etc. The requirement stated here applies all the time, not only for pure decoration.

Proposed Change:

Break out into separate requirement on the "as communicated" representation of the content, a.k.a. the "data on the wire."

This requirement is mis-filed in the current outline. This is a control issue, a matter of keeping actions under the user's command. If it were an orientation issue (principle 3) one could repair by announcing context changes. That is not enough. In the current outline it belongs with Principle 2.

Proposed Change:

re-flow this requirement under what the user can do, not what they can understand.

Having the HTML spec say that @alt was to contain a short description of the image caused years of dysfunctional ALT texts to be written. Haven't we had enough of this? "Descriptive" is narrow in a misleading way; need something that is more evocative of the breadth of information covered by these various compoents and their short labels.

Proposed Change:

Use "are explanatory" or "are fitting."

If there is a mechanism that satisfies one of these, there is a mechanism that satisfies the other, because the UA can infer meaning from pronunciation and vice versa.

Proposed Change:

merge these two clauses

Principle is "First, Do no Harm." Compare with Hippocratic Oath. This is a safety requirement, it comes before access requirements, and is not an access requirement.

Proposed Change:

Introduce separate principle for safety and move this guideline to it. Make it the first, before others. Remove all obstacles to implementing this provision severable from the rest.

On the face of this, the requirement is unenforceably vague. Need to spell out what you mean by "the purpose of the link" and limit the requirement to concepts the user is likely to recognize.

Proposed Change:

Re-state as (roughly) "When the result of activating a link falls within the general meaning of a widely used and understood term or notion such as 'help' or 'home,' and there is a widely-reognized name or URI for this concept, the association of this link with that concept is machine-recoverable from the encoding of the content (Note 'encoding').

This is a general usability practice.

Proposed Change:

Reorganize to address overlap with general usability in a positive way.
See other comments on organization and explanation.

Clause is trivially vague. It will either be satisfied or be inapplicable, because there is no objective standard for when the "and..." condition is met.

This provision is general good usability practice.

The suggestions usually come from the browser's memory of user's response to similar questions in other content. Hence is not a content requirement, but a user experience desideratum which may be satisfied by user's automation or the data received from the author's automation.

Proposed Change:

move to informative annex noting good usability practices that are especially appreciated in the PWD Web experience.

Distinguish requirements that apply at the User Interface, i.e. in the Rendered Content, from requirements that apply at the network interface, i.e. in the Communicated Content.

The latter is defined by how the content is represented as it passes from the author and server's automation to the user's automation.

We may be able to resurrect the notion of a [generic] document object model as a slightly stronger statement of the 4.1 'clean parse' language and tie "programmatically determined" clauses there.

Proposed Change:

Distinguish requirements that apply at the User Interface, i.e. in the Rendered Content, from requirements that apply at the network interface, i.e. in the Communicated Content.

1.3.2 is an example of the former.
1.3.2 is an example of the latter.

Requiring that the other way of showing the color-signaled information is visual is a UI requirement. It is not a content requirement.

This requirement is inappropriate for a claim that includes SALT in its baseline such that the default presentation would speak the information as well as show it with color.

Compare with UAAG 2.3. Sometimes you should not try to replicate the richness of the color coding in other, more limited property spaces, but rather signal that there is further information and expand on the further information on user interactive request.

Compare also to the 'minimized' treatment of notes in a DAISY player. Here the presence of a note is evident, the content of the note is available but on an 'ask for' basis.

24 bits per pixel of color-coded information is just too much information to assume that other visual effects can capture it all.

Proposed Change:

User Interface requirement:

strike the word 'visually' to leave "is also evident, or is available and the availability of more information is evident"

Content requirement:
The default prsentation afforded without user intervention satisfies the above requirement.

[alternate language: .. is visually evident ... in the author-designed visual presentation of the content]

Content requirement:
The connotations of color and other presentation-properties constitute non-text information and must (per 1.1.1) be afforded text explanations that are associated with the items bearing these presentation effects (and connotations), associated by an association that can be programmatically determined.

The principle is that "what one can do, others can do."

Interactive objects are an instrumentality, an intermediate level of representation. The content can succeed by affording equivalent facilitation for widgets through menus or other widgets or voice command.

Proposed Change:

There are two principles here:

1) What one can do, others (PWDs) can do. [This is more likely the section head for device-independent interaction etc.]

2) Afford remediation [restore a usable look-and-feel] with as little deformation of the look-and-feel as possible. [This is probably a separate, cross-cutting section explaining why color coding should be _visually evident_ where readily achieved, etc.]

Date-qualified claims are introduced in the discussion of migration from WCAG1 to WCAG2. They are also of interest to sites and appropriate to be used in staged adoption plans more generally.

Proposed Change:

Introduce and define terms for date-qualified claims earlier in the general discussion of a cliam.

Don't wait until talking about WCAG1.

The wide-open nature of the baseline means that the obvious interpretation of the W3C Candidate Recommendation phase could never be completed because there would be other baseline profiles that remained un-demonstrated.

Proposed Change:

Minimum:
Spell out an explicit experiment plan for Candidate Recommendation. Define the baselines to be used to demonstrate the effectiveness of these guidelines.

Better:
Make PR [a.k.a. CR exit] contingent on demonstrating the joint statistical distribution of the proposed testable hypotheses and user success in using live contemporary web content.

Some wiggle room is attempted in the statement of the individual success criteria, but the general process for arriving at a conformance claim satisfaction is still, as in WCAG, a "one strike and you're out" rule.

Another way to describe it is that there is an "AND" combination of single point test results to get the overall score.

This is a serious problem.

This kind of rollup or score-keeping is seriously out of alignment with the general reduntant quality of natural communication including web content.

In natural communication there is often more than one way to learn what there is to learn from an utterance.

And in GUIs there is often more than one way to effect any given outcome.

So long as there is a go-path and the user can find it, a noGo-path should not force a failing grade for the [subject of conformance claim]

There is prior art in Mean Time Between Failures computations in reliability engineering, in the handling of redundant fallback capability.

Proposed Change:

An approach to consider:

Make the assessment of overall score or rating incorporate the recognition of alternatives at all levels of aggregation and not just at the leaf level. In other words, take systematic account of equivalent facilitation.

If there is an accessible way to learn or do what there is to learn or do, and an accessible way to find this when other paths prove problematic, that content should not fail as a result of the problems with the alternate path. It is not enough to address this in 1.1.1 and 4.2. It needs to be global.

Item Number: Conformance claims
Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):

While many accessibility criteria can hardly be formalised to be automatically checked by a validator, some of them can.

Previous attempts have been made to formalise some of WCAG 1.0, such as the W3C "Web Content Accessibility Checking Service" [http://www.w3.org/2000/07/eval43/] using Schematron [http://www.w3.org/2000/07/eval43/wai.xml] or the more advanced Petr Nalevka's "Relaxed validator" [http://badame.vse.cz/validator/] using Relax NG with embedded Schematron [http://cvs.sourceforge.net/viewcvs.py/relaxed/relaxed/conf/schema/rng/modules/wcag.rng?view=markup].

Proposed Change:

Propose some schemas for checking some of the accessibility rules in (at least) HTML documents (using e.g. XML Schema, Relax NG, Schematron) checking for the criteria that can be formalised. Relax NG + Schematron is imho a good candidate.

"Interoperability" is a better term than "compatibility". Also see comment on principle 4 about "future user agents".

Proposed Change:

Change 4.1 to "Support interoperability with user agents (including assistive technologies)."

Comment: para 3 - "even conformance to all three levels will not make web content accessible to all people". Some guidance needs to be provided as to what else is required to make the content accessible to all - OR who is not included in WCAG 2.0

Proposed Change:

additional references/pointers are required

Comment: It is too easy to fail SC at Level 1 - most organisations I have worked with will not go to this length in most cases, hence will never be able to claim even "A" conformance. In fact, on most Government and corporate sites I have worked with, the provision of a transcript and/or a script gives all the information needed to substitute for the multimedia


Proposed Change:

Level 1 should have SC along the lines of "provide a transcript if spoken words only and no action" and "provide a script including the dialogue if video wit activity"

SC 1.2.1 & 1.2.2 should be moved up a level, and all other SC reconsidered as to the appropriate level.

Comment: After playing with the luminosity algorithm for some time now, selected colour combinations are still almost unreadable - eg the algorithm allows blue-on-blue and orange-on-red, both combinations are very difficult to read by anyone. For an example see http://www.recsport.sa.gov.au/. IMHO, the colour-difference aspect of the old draft colour contrast algorithm needs to be reintroduced. For colours schemes that pass luminosity, but fail colour difference, see some of the combinations on http://juicystudio.com/services/coloursaferatio.php?background=003 and related pages.

Proposed Change:

add a colour difference aspect into the colour contrast SC

Comment: 20 seconds may well not be long enough to 'hit any key' for some people with severe physical or motor disabilities. Also, what form does the warning take? It needs to be accessible to all as well!

Proposed Change:

drop this bullet

Comment: This should be a level 2 SC - for many people with reading difficulties, or using AT, reading a page is a time consuming exersize, and page refreshes may not allow them to read to the end.

Proposed Change:

move this SC up a level & consider strengthening it WRT content refreshing automatically

Comment: What is the point of having 3.1.1 at Level 1, but 3.1.2 at Level 2? My screen reader will then just read the entire page in the web unit language!

Proposed Change:

Move 3.1.2 to Level 1

Comment: Why is a word different from a phrase?

Proposed Change:

Drop the Note!

Comment (including rationale for any proposed change):

It is unclear if and how WCAG 2.0 applies to sites
accessed in off-line mode (e.g. local, synchronized
Web sites)

Proposed Change:

Should be covered by adding at least a sentence in
the introductory chapters or, if possible, more
details.

Technical/substantive issue

The section currently provides no guidance to actually choosing a baseline
that can in fact be used accessibly.

I propose that the availability of a user agent which meets level-A
conformance to User Agent Accessibility Guidelines 1.0 for the relevant
technology and language be a minimum criterion for the selection of a
baseline.

In this way, selection of a baseline that is not actually accessible
automatically makes it impossible to claim conformance to the
accessibility guidelines. This avoids the situation where it is possible
to construct content that can meet the requirements, but that is not
actually accessible due to the absence of any means for using the baseline
set. Otherwise there is a risk that the value of conformance will be
significantly reduced, since it makes no reliable statement about whether
the content is in fact accessible to real people.

This seems a reasonable requirement given that UAAG is a W3C
recommendation, and does not seem onerous for common web technologies.

cheers

Chaals

Part of Item:
Comment Type: substantive
Comment (including rationale for proposed change):

There needs to be a SC for color contrast at level 1. Documents with very poor contrast between text and background do not provide even a minimum level of accesibility.
The guideline text starts with \"Make it easy...\" which means the user should not have to work to get color contrast. Highlighting text within the document to change the contrast is not easy for many people with disabilities and should not be taken as a method of meeting the SC.
This has been discussed recently on the WCAG list but there was no resolution so I\'m submitting this comment.

Proposed Change:

Create a SC for color contrast at level 1. The luminosity ratio should be similar to what is currently at level 2 (5:1).

Part of Item:
Comment Type: substantive
Comment (including rationale for proposed change):

Item 2 of optional components of a conformance claim appears to add little useful information to a conformance claim because it is a subset of the baseline information (item 5 of required components of a conformance claim). It seems more useful to me to state which technologies in the baseline are not used or relied upon.

Proposed Change:

Remove item 2 of optional components of a conformance claim or replace it with a list of technologies that are in the baseline but not relied upon.

2. Metadata

We recommend that WCAG 2.0 address the issue of locating good or useable resources by requiring that every resource carry or refer to a description of its accessibility characteristics. Without this the best resources may not be found and a resource that is not universally accessible may not be made available to
a user that could use it even if it is not useable to others.

This comment has also been made in http://lists.w3.org/Archives/Public/public comments wcag20/2006Jun/0091.html with which we agree.

Part of Item:
Comment Type: substantive
Comment (including rationale for proposed change):

The National Confederation of Deaf Persons of Spain (CNSE)have requested to us that we support to obtain an improvement in the accessibility for the deaf people.
Being conscious of the differences between the languages of signs worldwide and the lack of equivalence with the languages spoken in each country, we considered that some reasonable advances by means of the following changes could be included.

Proposed Change:

1.1.2 For prerecorded sound of spoken language provide sign language interpretation equivalent.

advisory[????] – [I believe the that the word is used. If so, needs definition.]

audio [Add this] What is the difference between audio and audio-only, or live audio-only

information that is conveyed by color [alone?????!]

Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):

1.3.2 Any information that is conveyed by color is also visually evident without color.

Presumably it could be evident by shape, size, location, etc…… This seems problematic, since what is visually evident depends so heavily on the person. For some, nothing is visually evident….!

Proposed Change:

Part of Item:
Comment Type: ED
Comment (including rationale for proposed change):

Recommends deleting \"does not preclude\" from :

Note: This does not preclude and should not discourage the support of other input methods (such as a mouse) in addition to keyboard operation.

Proposed Change:

Note: This should not discourage the support of other input methods (such as a mouse) in addition to keyboard operation.

Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):

Level 1 SC for Guideline 1.2 should also include live captioning. By assigning live captions to Level 2, the working group is designating this as less important than pre-produced captions. In fact, live captions are arguably more important than pre-produced captions-- consider the case of an emergency alert.

Proposed Change:

Move live captioning to Level 1.

Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):

A full multimedia transcript is not an alternative to audio description. (In fact, I doubt its usefulness in general.) Audio descriptions should be required at Level 1, period.

Proposed Change:

Delete the reference to a full multimedia transcript. Move 1.2.3 up to 1.2.2.

Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):

Live audio descriptions must also be included in Level 1 SC for Guideline 1.2.

Proposed Change:

Insert a requirement for live audio descriptions into Level 1 SC for Guideline 1.2.

Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):

It is unrealistic to ask authors to provide an alternative version of a Web site, or any other material, using language written at a lower reading level than the original material.

Proposed Change:

Delete requirement 3.1.5.

Spawned windows: As mentioned in a previous comment, the SC this maps to outlaws change in context when a user does something, but doesn't outlaw change in context without user initiation.

Proposed Change:

Create a new SC outlawing changes in context without user initiation at Level 1 (I am happy to write this)

add the word “unambiguously�

Item Number: Success Criterion 1.2.2
Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):

Guideline 1.2

Guidelines 1.2.2 and 1.2.3 are not mutually exclusive. Perhaps it should be, if an audio description is provided, compliance is at level 2. If a transcript is provided instead, compliance is at level 1.

1.2.2 "Audio descriptions of video, or... are provided for prerecorded multimedia."

1.2.3 "Audio descriptions of video are provided for prerecorded multimedia.

Proposed Change:

Drop "Audio descriptions of video" from 1.2.2. Audio description are relatively difficult to implement, while text transcripts are quite easy. Leave the transcript at level 1, which is attainable by everyone, and keep audio descriptions to level 2.

Item Number: Success Criterion 1.2.7
Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):

Guidelines 1.2.2 and 1.2.7 are not mutually exclusive.

1.2.2 "... a full multimedia text alternative including any interaction, are provided for prerecorded multimedia."

1.2.7 "For prerecorded multimedia, a full multimedia text alternative including any interaction is provided

Proposed Change:

Drop 1.2.7 in favour 1.2.1 at level 1, with Audio descriptions removed in favor of keeping them with 1.2.3 at level 2.

Item Number: Success Criterion 1.4.1
Part of Item:
Comment Type: GE
Comment (Including rationale for any proposed change):

Guideline 1.4

Luminosity Contrast Ratio in its current form appears to be a less than perfect measure of contrast. For example black text on a white background is more readable than white text on a black background, yet both have the same ratio. In the future as the algorithms for measuring contrast become better, the suggested 5:1 ratio in 1.4.1, may no longer be valid.

Proposed Change:

A general statement should be made in the guideline, something like ...use foreground and background colours that provide sufficient contrast...", and move LCR and the suggested ratio to the techniques document, where it can be adjusted as measure of contrast become better defined.

Item Number: Success Criterion 1.4.3
Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):

As suggested for 1.4.1, Luminosity Contrast Ratio in its current form appears to be a less than perfect measure of contrast. For example black text on a white background is more readable than white text on a black background, yet both have the same ratio. In the future as the algorithms for measuring contrast become better, the suggested 10:1 ratio in 1.4.1, may no longer be valid.

Proposed Change:

A general statement should be made in the guideline, something like ...use foreground and background colours that provide *high* contrast...", and move LCR and the suggested ratio to the techniques document, where it can be adjusted as measure of contrast become better defined.

Item Number: Success Criterion 3.1.5
Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):

Though for public content, guideline 3.1.5 would apply, for non-public content, such as an online course aimed at a professional audience, there should be no requirement that it be "lower secondary" .

How will evaluators measure language level. Perhaps using a FOG index for English. How would they assess across languages, where a FOG index is not valid? Would lower secondary be too high when an audience is from a third word country, where reading levels tend to be much lower? There has to be some acknowledgement of the audience reading the content. I thought I had suggested in a previous review of a WCAG 2 draft, that audience be worked into the baseline, though I can't find the specific reference at the moment. I understand that would complicate things significantly. If not included in the baseline, there does need to be some way to define the acceptable level of language for the intended audience.

With regard to including the audience in a measure of readability, see:

http://en.wikipedia.org/wiki/Readability

Proposed Change:

It might read something like "Where information is aimed at a non specific audience, for which reading level is unknown....use lower secondary..."

Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):

I am doing a thesis study on electronic banking accessibility, and have found that the link texts should be clearly descriptive alone. The links are practically the most important element of most pages, and this criterion should therefore be given priority level 1. In electronic banking applications the same applies especially to (submit) buttons.

Proposed Change:

The Success Criterion 2.4.5 should have priority level 1.

Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):

There is no requirement at any level for documents to be valid. I understand the need to make things technologically neutral but these are not mutually exclusive.
If there is no requirement for validity, what is to stop different browsers adding new elements and supporting them? We\'ll have an equivalent situation to the layer and ilayer elements as new browsers will add new elements they like, irrespective of the specification. As well as that, we\'ll see the return of previously deprecated elements such as font. The WAI has advocated good development standards for a long time. Now is not the time to change.

Proposed Change:

Add a new success criterion (probably a level 2 success criterion as it is a strengthening of the level 1), requiring that web units or authored components are produced according to the formal specification for the technology used.

Affiliation: None
Document: W2
Item Number: ensure-compat-parses
Part of Item:
Comment Type: technical
Comment (Including rationale for any proposed change):
Just a note that you asked for comments and from my own personal trawl of the archives, I found 19 separate comments related to validity/unambigous parsing. Of these, 18 of the comments desired returning to the \'validates\' criteria as used in WCAG 1 at either Level 1 or 2. That\'s almost 95% of the people making a comment wanting validity back.

(also see public posting on same:

http://www.thepickards.co.uk/index.php/200606/validity-those-taking-up-arms/

)

Proposed Change:
Re-include validity at level 2 as a strenghtening of SC 4.1.1.

Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):

Sc 1.1.1: "If non-text content is pure decoration, or used only for visual formatting, or if it is not presented to users, is the above meant to apply to auditory content, e.g., sound efects or background sounds used only for aesthetic purposes and which is incidental to the meaning and functionality of the Web unit? In other words, can a sound be "pure decoration", or is the provision restricted to visual material? My own view is that it should apply irrespective of the modality of the "decoration", namely to auditory content as well as visual.

Proposed Change:

Perhaps add a parenthetical such as "pure decoration (whether auditory or visual)".

Part of Item:
Comment Type: GE
Comment (Including rationale for any proposed change):

Terminology used in related technical specifications should be consistent, unless there are compelling reasons to the contrary. There are no strong reasons why basic terminology in WCAG 2.0 should differ from ATAG, UAAG and indeed WCAG 1.0.

Proposed Change:

Change "principles", "guidelines" and "success criteria", respectively, to "guidelines", "checkpoints" and "provisions" throughout WCAG 2.0 and supporting documentation.

Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):

This criterion is specific to aspects of visual presentation. Suppose however that the content is written in VoiceXML or a comparable format designed to control auditory presentation. Surely the same requirement should apply, for the benefit for example of users who are deaf.

Proposed Change:

Generalize this criterion so that it is not modality-specific, i.e., not limited to visual presentation.

Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):

Blinking is not a "time limit" on reading or interaction. Therefore, sc 2.2.2 does not belong under this guideline.

Proposed Change:

Move 2.2.2 to guideline 2.3, generalizing the wording of guideline 2.3 if necessary. Alternatively, move this criterion to its own guideline if photosensitivity is not the main rationale and if you don't want to expand guideline 2.3 to cover the issues addressed by this criterion.

Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):

As proposed by Charles McCathieNevile in commenting on the November 2005 working draft, the term "textual interface" should be used instead of "keyboard interface". Some software interfaces do not accept keystroke input directly, but instead receive character input; they are not "keyboard interfaces" as defined in the glossary.

Proposed Change:

Substitute "textual interface" for "keyboard interface", and define "textual interface" as an interface used by software to receive characters or keystroke input. Under this definition, keystroke input is included; thus compatibility with a keyboard interface would satisfy the success criterion, as would compatibility with any software mechanism capable of receiving character input, whether from a keyboard or any other kind of input device.

Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):

This guideline doesn't require the use of technologies, for example markup languages, in accordance with the semantics defined in specifications. Assistive technologies such as braille translators, as well as content transformation tools, rely upon the assumption that elements and attributes of markup languages are used to convey the meanings prescribed in specifications. To the extent that content departs from this requirement, programmatic determination of structural and other aspects of content is precluded, being reduced instead to a probabilistic matter requiring heuristics to be introduced by the software developer. Although the definition of "programmatically determined" refers to support by user agents, it doesn't explicitly refer to standards governing the technologies used in the content.

Proposed Change:

Add a requirement under this guideline to the effect that, for each technology in the baseline that is defined in a specification, every feature of the technology is used in conformity with the meaning and purpose prescribed in the specification. Even better, require it to be used in accordance with the meaning, purpose and syntax prescribed in the specification. Alternatively, if the above is too strong a requirement, restrict it at level 1 to every feature used to enable the structure, purpose or meaning of the content to be programmatically determined. That is, if the feature is used to enable programmatic determination for purposes of meeting the guidelines, then it must be used in accordance with the syntax and semantics defined in the specification governing the technology. This falls short of a requirement of full syntactic and semantic correctness, but the stronger requirement could be added at level 2 or level 3.

Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):

Some people use the word \"diagram\" to refer only to charts, schematics and
other drawn illustrations, excluding such graphics as photographs.

If this criterion is not meant to be so restricted, it would be better to use
\"graphics\". If a restriction is meant, \"diagram\" should be defined in the
glossary.

Proposed Change:

\"text or graphics\", or add a definition of \"diagram\" (see above).

Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):

Same as 1.4.1 re \"diagrams\".

Proposed Change:

Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):

This criterion states that \"when text requires reading ability more advanced than the lower secondary education level, supplemental content is available that does not require reading ability more advanced than the lower secondary education level.\" I don\'t see why this need apply when the content uses a controlled vocabulary and has a very specific target audience. For example, on a medical website used only by surgeons and describing new surgical research, why does there need to be a version of this text that someone at the lower secondary education level can understand? Certainly have diagrams etc to aid comprehension is important, for all users, but this may not be possible in many cases.

Proposed Change:

Modified criterion to allow specific exception for web content with specific target audiences utilising a widely accepted controlled vocabulary.

Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):

I am doing final copy editing of a book chapter on forms.

I had talked about how clear the January version of WCAG20 was about forms:

SC 4.1.3 The label of each user interface control in the Web content that accepts input from the user can be programmatically determined and is explicitly associated with the control.

But now that has apparently been replaced by:

SC 4.1.2 For all user interface components, the name and role can be programmatically determined, values that can be set by the user can be programmatically set, and notification of changes to these items is available to user agents, including assistive technologies.

The problem is that 4.1.2 is absolutely inadequate. The \"Role\" of text input field is \"text input\"; the name could be \"keyinput\". 4.1.2 is basic software accessibility - leaving to the AT the process of figuring out what the prompt (label) is.

I just talked with John (who sounds terrific) and he pointed out that -

1.3.1 Information and relationships conveyed through presentation can be programmatically determined, and notification of changes to these is available to user agents, including assistive technologies.

Served the same purpose as 4.1.3 - I agree. But it is abstract. It requires interpretation.

With the Last Call version of WCAG 2.0 there is no success criterion that specifically addresses labeling forms and I think that is a very serious mistake.



Proposed Change:

Please reinstate 4.1.3.

From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0119.html

text alternative
programmatically-determined text that is used in place of non-text content, or text that is used in addition to non-text content and referred to from the programmatically-determined text

Hence a title attribute absolutely is a text equivalent. An image with empty alt plus a title containing what would otherwise be the alt text will pass WCAG 2. (There is some overlap here with UAAG, which can be interpreted to allow presentation of title text instead of regular or alt text.)

From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0119.html

variations in presentations of text
changes in the visual appearance or sound of the text, such as changing to a different font or a different voice

Web authors now have to worry about sound of text? How, exactly? We don't control people's screen readers. (Does this mean we have to find a way to mark up intonation and prosody in our podcasts? How, exactly?)

From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0119.html

WCAG 2 violates WCAG 1 by listing an equation (for brightness as used in the [9]general flash threshold) as plain text. In so doing it pointlessly explains that ""the ^ character is the exponentiation operator."" I thought this kind of thing is what we had MathML for.

From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0119.html

Again after many unheeded warnings, the Working Group published the following guideline for multimedia (at the highest level):

Sign-language interpretation is provided for multimedia.

First of all, which sign language? For an English-language source, no fewer than five distinct, if not always mutually unintelligible, sign languages can be identified (American, British, Irish, Australian, New Zealand).

More importantly, WCAG now requires translating a document (a multimedia file) into another language as a claimed accessibility provision. To restate the same question I have been posing for years, what prevents a Ukrainian-speaker from demanding that a Web site be translated into Ukrainian? After all, in both cases the issue is the incomprehensibility of the language of the original, not the disability. (A deaf person is not necessarily unable to read. Deaf people can and do understand and communicate in written language. A reliance on sign language, or even a preference for it, does not logically follow from being deaf.)

From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0119.html

WCAG 2 is nearly consistent in pretending that Web standards do not exist (with one curious exception that I'll get to shortly). Some teenagers have greater understanding of valid, semantic markup than the Working Group does, as evinced in passages like these:

Information that is conveyed by variations in presentation of text is also conveyed in text, or the variations in presentation of text can be programmatically determined.

Now, what does ""presentation"" mean? Really?

Doesn't the requirement to convey the information in text make it possible to write instructions for an online form as follows?

* Fields marked in red are required.
* Fields marked in green are optional but recommended.

I have just ""conveyed"" the colour differences. (It so happens that the colours are exactly the rare ones that are confusable to colourblind people.)

If I am using markup to vary presentation of text, as one typically will (how else do you do it if you aren't using a picture of text?), how is that markup ever not programmatically determinable? The browser had to read it to vary the presentation in the first place. All the usual elements, like em, strong, b, i, and u, are understandable by a machine. So is CSS, even at the simple level used in this document as a demonstration (span class=""red"" or =""green""). More complex CSS selectors, like :last-child, are also programmatically determinable.

In essence, for any author using markup, even lousy presentational markup, how is it possible to flunk this criterion?

From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0119.html

Some parts of Web accessibility are not under the control of the author. The user agent, like a browser or screen reader (the latter of which is definitely included in WCAG 2's definition of ""user agent""), has a significant role to play. Nonetheless, WCAG lists these requirements:

More than one way is available to locate content within a set of Web units where content is not the result of, or a step in, a process or task.

Why can't people be expected to simpy use the Find command in their browsers, or the back button?

The same issue reappears in that classic bugbear of Web-accessibility pedants, hyperlinks:

Each link is programmatically associated with text from which its purpose can be determined. [...] The purpose of each link can be programmatically determined from the link.

""Purpose""? Doesn't Slashdot have an enormous mass of code in its system to prevent people from linking to notorious vulgar images in the guise of a real hyperlink? (There the ""purpose"" is to deceive.) The ""purpose"" of a link is to provide a link, obviously.

Did they not mean the ""destination"" of a link? If so, how is it not obvious from the semantics of the link? Isn't it embedded right in the a href=""""? How is it impossible to ""determine"" the destination of a link? That's the user agent's job, is it not?

Incidentally, there have been a few experimental all-sign-language sites in which many links and their targets are given completely in sign language. There is no link text per se. What's between <a> and </a> is a video file or image of a person using sign language, and where you end up is another such video file or image (or a page full of those). Given the semantics of all markup systems in use on today's Web, the hyperlink has to contain text characters in order to function. A still image has to contain an alt text (though alt="""" is plausible in some cases).

Nonetheless, there are a few scenarios in which a page intended to be accessible to sign-language speakers uses no text at all. How is such usage accommodated in WCAG 2? (And must authors, by implication, use an interpreter to voice the sign language for blind visitors, which must then of course be captioned or transcribed? Where does it end?)

I argued with the Working Group for months over the concept of semantics in markup, that is, the use of the correct element for the content. This argument betrayed the Group's arrogance and its thorough incomptence at standards-compliant Web authoring. It also proved they've been asleep at the wheel for the last eight years, in which people like me have been labouring to improve Web standards. This nonsense alone is enough to generate suspicion and distrust among competent and up-to-date Web developers.

Nonetheless, now the word ""semantics"" is included, without elaboration or definition, in the Understanding and Techniques documents (whose examples I am condensing into one excerpt below). Occasionally, the term is recast as ""structure.""

From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0119.html

1. A simple text document is formatted with double blank lines before titles, asterisks to indicate list items and other standard formatting conventions so that its structure can be programmatically determined.
2. HTML Techniques for Marking Text [...] [11]Using semantic markup to mark emphasized or special text
3. Making information and relationships conveyed through presentation programmatically determinable USING the technology-specific techniques below (for a technology in your baseline) [...] [12]Using semantic elements to mark up structure [...] The semantics of some elements define whether or not their content is a meaningful sequence. For instance, in HTML, text is always a meaningful sequence. Tables and ordered lists are meaningful sequences, but unordered lists are not.
4. CSS Techniques [...] [13]Positioning content based on structural markup

The WCAG main document does a drive-by and just barely avoids mentioning semantics by name:

[INS: [Content] :INS] includes the code and markup that define the structure, presentation, and interaction, as well as text, images, and sounds that convey information to the end-user.

This means your markup is also your content, which will come as a surprise to those who are interested in separation of content, structure, presentation, and behaviour. Here, ""markup that define the structure, presentation, and interaction"" clearly refers to semantics.

Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):

This should be success criteria 1 like in the Priority 1 WCAG 1.0 requirement. It is impossible for people using speech to guess at language changes. We have a lot of web based foriegn language courses at UIUC and we have identified that speech users cannot determine when to manually switch their synthesizer languages, even when they know that there are more than one language on the resource. If changes in language are available modern screen readers will automatically switch the lanaguge of the synthesizer.

Proposed Change:

Move this requirement to Success Criteria 1

Part of Item:
Comment Type: substantive
Comment (including rationale for proposed change):

I know this has been brought up before. I am in agreement that validity needs to be a requirement at level 2.

Proposed Change:

Put \"Create documents that validate to published formal grammars\" in as a level 2 requirement.

Part of Item:
Comment Type: substantive
Comment (including rationale for proposed change):

Conformance claims are complicated definitions. They are human understandable however user will not make good use of them. And they are not machine understandable because their definition and format are not provided strictly.

Proposed Change:

Describing format of Conformance claims should be
determined strictly. If Conformance claims are understandable for a User Agent
(whether achieve a baseline or not), it is possible to cope with
that contents.

Comment: The term, "parsed unambiguously," or "parsed into only one data structure" is not good enough to comply with the principle 4. The principle states that "content should be robust enough to work with current and future user agents." Then, if web units or authored components are well-formed but include information not based on chosen technologies, can we guarantee that this information is conveyed? Therefore, I believe if forward compatibility is important, "conforming to specifications" would be better than "parsed unambiguously."

Proposed Change:

Using the phrase "conforming to specifications" instead of the phrase "parsed unambiguously."

Part of Item:
Comment Type: GE
Comment (including rationale for proposed change):

I do not have a specific change but am very concerned that it is understood and part of WCAG 2.0 that all resources should carry or refer to a description of their accessibility characteristics. Without such a description, the best resources will not be found and useful in some cases and in others, a resource that is not universally accessible will not be made available to someone who could use it even if others cannot.

Proposed Change:

I propose that the description of the resource be included as a requirement for the \'accessibility\' of the resource in order to make it accessible to those who can use it.

http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform_ch_1html.html

Comment (including rationale for any proposed change):

With new technology such as roles within the WAI, you can assign the role of the object in a programmatically understandable way. So if assistive technology knows the role of a picture is as a bullet, or to say that a star means it is required, or that spacer.gif is for spacing - why do you have to also fill in the alt tag?

Proposed Change:

Add to the list of options: The role and behavior of non-text content can be programmatically determined

http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform_ch_1html.html

Comment (including rationale for proposed change):

With new technology such as roles within the WAI, you can assign the role of the object in a programmatically understandable way. Also you can use RDF, xfroms etc to similar affect.

Proposed Change:

1.3.2 Any information that is conveyed by color can be programmatically determined or is also visually evident without color

http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform_ch_1html.html

Comment (including rationale for proposed change):

1.3.1 Information and relationships conveyed through presentation can be programmatically determined, and notification of changes to these is available to user agents, including assistive technologies...and

Missing hear is you need to encapsulation of the functions and behavours of each element is essential

Proposed Change:

Add at level one
The functions and behavours of each element that can be visual Perceived can be programmatically identified thought its life cycle.

http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform_ch_1html.html

Comment (including rationale for proposed change):

With RDF, XHTML roles etc, time outs can now be programmatically determined

Proposed Change:

add to the bulleted list in 2.2.1 Success criteria
The role of time outs and updated regions can be programmatically determined

http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform_ch_1html.html

Comment (including rationale for proposed change):

With RDF, XHTML roles etc, time outs can now be programmatically determined

Proposed Change:

does the wording cover this, if not add to the wording of 2.2.3 and 2.2.2 Success criteria

...Unless the role of time outs and updated regions can be programmatically determined

http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform_ch2_.html

Comment (including rationale for proposed change):

Interfaces become inoperable when one of the following brake:

1. Each element or widget is marked with full and corrected semantics that fully describes it's behavior Note this is more then information and structure can be separated from presentation .This includes creating enabled javascripted widgets that the Assistive Technology does not know what it is, what states are supported and how it maps to the operating system API. If non exists (like a tree item that can expand to a sub tree when you click on it) Then you may need to add a technology, such as xforms, XHTML 2 Roles

2. The relationships between elements and groups are known. Again, this is more then I see supported by navigation Success criteria. What form element controls what AJAX operated section is a good example of a relationship

3. States, properties, and relationships are valid for each elements behavior and are accessible via the DOM. For example if clicking on a tree item makes it expand or collapses, then it's state (such as expanded) needs to be accessible via the Document Object module Via an attribute that can be understood by assistive technology..

4. There is an element having the correct input focus. This is different to just being keyboard navigatable

Proposed Change:

Add success criteria at level 1 along the lines of:

1, The supported behavior of each element and widget can be programaticaly determined.

2, The relationships between elements and groups of elements can be programaticaly determined.

3, States, properties, and relationships are valid for each elements behavior can be programaticaly determined.

4, There is consistently an element having the correct input focus.

http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform_ch2_.html

Comment (including rationale for any proposed change):

In the roles specification we now have a range widget, which means you can state, in a programaticaly determined way what the max and min values are.

That means that AT can give users the message any way they want - including text, if they want. Surly this is better then requiring text

we also have in the adaptable states and properties module a required attribute, (for situation B in the "how to understand this checkpoint)

Note this is all part of the WAI, and screen readers are working to support it today...

Proposed Change:

change 2.5.1 to: If an input error is detected, the nature of the error can be programaticaly determined or identified and described to the user in text.

http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform_ch2_.html

Comment (including rationale for any proposed change):

With things like role attribute you can assign a functional role to an element, and other important information such as allowable range. That means that the assistive technology can themselves perform validation. We should also work on identifying critical tasks.

Hence one of the list should be (for future proofing) the role of all information and it's critical nature can be progmaticly determined

Proposed Change:

1. Actions are reversible.
2. Actions are checked for input errors before going on to the next step in the process.
3. The user is able to review and confirm or correct information before submitting it.
4. The role of each control and it's critical nature can be progmaticly determined.

http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform3ch.html

Comment (including rationale for any proposed change):

I am concerned that level 1 SC will act against automatic help and combined with information hiding. For example when information is hidden unless you focus on the element in question, and then all the sub information about it is given.

If you do not hide the information then the page becomes busy and you can not see what the main points are. If the user has a two strep process to access the information, then they may never receive it.

As with many SC, they are OK if you read the definition, but if you just read the text it is misleading.

Proposed Change:

change the term "change of context" to "confusing change in context"
the definition can remain the same

http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform3ch.html

Comment (including rationale for any proposed change):

Terms in the document often seem to mean something a bit different, until you read the definitions. As WCAG is often quoted the terms themselves should be as close to clear language as the can be without viewing the definitions.

Proposed Change:

change the term "programticly determined", to "supported by Assistive technology".

http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform4ch.html

Comment (including rationale for proposed change):

The primary natural language is identified.
Why is this level 1? I have not seen an assistive technology and user not work at all because the language attribute is missing. this seems to be level 3

Proposed Change:

move to level 3

http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform4ch.html

Comment (including rationale for proposed change):

changes in natural language is identified:
Is WCAG awere that this is huge amount of work? for lots of content this would be more work then the rest of WCAG put together (all the has English in for web site names and odd words..). On the other hand it seems typically understandable by the user as is, and not so important for the user..

Proposed Change:

move SC 3.2 to level 3

http://lists.w3.org/Archives/Public/public-comments-wcag20/2006Jun/0130.html

Part of Item:
Comment Type: substantive
Comment (including rationale for proposed change):

text equivalents for struggling students and people with LD are often of a very different natures to the SC described.
They would typically not have all included text, point out the key detail that someone is needs to understand
Alt tags are often verbose, such as explaining or giving a sentence of context to a diagram. We often have multiple prodnotes (using HTMl with Daisy XML as a base) for a single picture often linked to different regions

descriptive alt tags would be omitted – the would just confuse the user who we are trying to help identify key content and concepts.

Would such a page be conformant?

note there are many more people with these needs then who are blind. And blind users are getting all the key information anyway.
Also note:
Alt tags and prodnotes are a great way to put info in a page for LD without changing the genral use

Proposed Change:

creat an alternive SC set for pages for people with LD.

The purpose of each link can be programmatically determined from the link. "Meaningful" link text is no longer a high priority: it should be. Navigating via links benefits a large number of users including those using keyboard access, voice rec, alternate input and screen reading technology. It remains in many cases the only means that many users can navigate content in an efficient and useful manner.

Proposed Change:

Should be a level 2 criteria

It is felt that this is a very weak part of the guidelines.

Proposed Change:

A level 2 item should stress that the initial or primary "presentation of the content" is accessible, not just some version.

Part of Item:
Comment Type: GE
Comment (including rationale for proposed change):

The exclusion of validity is a huge step backwards for web accessibility. A valid document ensures consistent rendering, regardless of user agent.

Proposed Change:

That validity be added as a requirement for conformance to success criteria.

Part of Item:
Comment Type: substantive
Comment (including rationale for proposed change):

For deaf web users, there are two basic demands to be met to achieve full accessibility.
- Sign Language is the native language for the deaf, the first language on which thinking and communication is based. Danish is a foreign language learnt by reading and writing. Therefore information provided in sign language will always be preferable to information provided in Danish text. (A new survey states that half of the deaf population has no School leaving exams in Danish, since they were not able to meet the language demands. Døves uddannelses- og arbejdsmarkedsforhold. Castberggaard 2006)
- all information provided by sound, should also be provided visually.

Sign language interpretation is mentioned in Level 3 Success Criteria for Guideline 1.2. in the WCAG 2.0 Guidelines. This placing does not ensure full accessibility to the deaf community, since EU documents only have to meet the demands on Level 2.

Proposed Change:

Broadband Network (ADSL) gives new opportunities to send multimedia, and the guidelines should therefore see that these new opportunities is utilized to achieve full accessibility. Sign language interpretation should at least be a Level 2 Success Criteria.

Part of Item:
Comment Type: substantive
Comment (including rationale for proposed change):

Success Criteria 3.1.5: “When text requires reading ability more that the lower secondary education level, supplemental content is available…� should be placed at level 2 instead of level 3. EU and many national governments meet WCAG conformance at level 2, which means that people with cognitive disabilities will not be granted full accessibility if 3.1.5 remains on Level 3. In WCAG 1.O checkpoint 14.1 was a level 1 criteria: “Use the clearest and simplest language appropriate for a site\'s content�.

Proposed Change:

Success Criteria 3.1.5: “When text requires reading ability more that the lower secondary education level, supplemental content is available…� should be placed at level 2 instead of level 3. EU and many national governments meet WCAG conformance at level 2, which means that people with cognitive disabilities will not be granted full accessibility if 3.1.5 remains on Level 3. In WCAG 1.O checkpoint 14.1 was a level 1 criteria: “Use the clearest and simplest language appropriate for a site\'s content�.

Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):

If the given situation is true and the user is given 20 seconds to react…it will become difficult for people using Assistive Technology, such as screen readers to read the message and react within 20 seconds. Even if the user is needed to only press a key, with a screen reader listening to the warning alone might require more then 20 seconds. This time should be extended and not fixed based on the message.

Proposed Change:

Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):

(See LC 681 for complete submission)

The guidelines do not address the following:

§ For error handling, there must be a way for users to know where errors are in a form and be able to navigate directly to the input in error.


Proposed Change:

Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):

(See LC 681 for complete submission)

The guidelines do not address the following:

§Guidelines for creating HTML documentation and Help must be stated and Help using navigational techniques must also be documented for accessibility.


Proposed Change:

Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):

(See LC 681 for complete submission)

The guidelines do not address the following:

§Informational text and instructions within web applications must have a focal point achieved by using tab indices of zero or some equivalent technique.

Proposed Change:

Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):

(See LC 681 for complete submission)

The guidelines do not address the following:

§Standardized keyboard navigation through frames.

Proposed Change:

Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):

(See LC 681 for complete submission)

The guidelines do not address the following:

§Search facility guidelines for navigation and focus.

Proposed Change:

Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):

(See LC 681 for complete submission)

In addition, we recommend the W3C address the following items at a later date:

§ Guidelines should address table navigation for magnification users.

Proposed Change:

Item Number: Success Criterion 1.4.3
Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):

The spread of the requirement to have sufficient difference between foreground and background colours over two Success Criterion is an effective way of recognising the fact that the higher the contrast ratio the more likely the information will be accessible to a greater number of people with impaired colour vision.

However, I believe both the SC relating to this issue should be increased.

Proposed Change:

Make SC 1.4.3 a Level 2 Success Criteria

Item Number: Success Criterion 1.4.1
Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):

Many people have difficulties differentiating between the foreground (text) and background colours used on websites. Also, as people get older their ability to perceive colours and differentiate between colours seems to diminish.

I believe that this is a significant accessibility issue and so should be required if a site is to achieve a minimum level of accessibility.

Proposed Change:

Make 1.4.1 a Level 1 Success Criteria

Item Number: Success Criterion 1.3.1
Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):

It appears that SC 1.3.1 encompasses many separate guidelines that were specified in WCAG 1.0, including the requirement to associate data table cells with the appropriate row and column headings and requirements relating to the labelling and grouping of form controls. I presume part of the reason for combining such a diverse range of accessibility needs in single success criteria is the desire to have criteria that are "technology-independent".

In my experience, a lage proportion of the problems assistive technology users now experience when using web sites result from the sites failing comply with the WCAG 1.0 guidelines that are now nominally covered by SC 1.3.1. Nearly all web content is currently presented using (x)html and this is likely to continue to be the case for the foreseeable future. However WCAG 2.0, which is the normative document, provides web developers with no practical guidance or clues in how to avoid these problems.

The link "How to meet 1.3.1" leads to information in the "Understanding WCAG 2.0" document, which describes techniques for addressing the criterion. The "Understanding" document contains links to eleven HTML techniques, which are presented in yet another document, "Techniques for WCAG 2.0".

Frankly, I don't imagine many developers when faced with the prospect of preparing a data table will bother to troll through three documents in order to see why it is important to associate data cells with row and column headers in a non-visual way. On a related point, why don’t the "Understanding WCAG 2.0" HTML Techniques include the need to use TH for tables with single levels of row and column headers?

I am concerned that the failure to provide guidance in relation to crucial html issues in the WCAG 2.0 document will lead to a decline in awareness on the part of developers regarding their importance and this will contribute to a fall in the overall accessibility of websites and the web as a whole.

I believe the Working Group should get over their hang up with developing some sort of technology neutral standard and recognise that the way to bring the greatest accessibility gains to the greatest proportion of web users is by providing practical advice in how to improve the accessibility of (x)html sites.

Proposed Change:

In my view, WCAG 2.0 Guideline 1.3 should include success criteria for the specific issues that are addressed in the following WCAG 1.0 Checkpoints: 3.1, 3.5, 3.6, 5.1, 5.2, 5.5 and 12.4.

Since this is unlikely to happen, I would like to urge the Working Group to consider providing HTML example for each of the issues covered by the checkpoints above in the core WCAG 2.0 document so that SC 1.3.1 is able to provide the majority of web developers with a clear indication of how to meet this criterion.

Item Number: Conformance levels and the baseline
Part of Item:
Comment Type: GE
Comment (Including rationale for any proposed change):

I feel the proposed system of Success Criteria is potentially confusing and misleading. The document states the proposed grouping of success criteria differs in important ways to the approach taken with WCAG 1.0 since in WCAG 1.0 each checkpoint was assigned a "priority"Â? according to its impact on accessibility. While I had some concerns of the allocation of specific levels of priority to checkpoints in WCAG 1.0, I felt the overall priority approach was effective since it was easy to understand and provided clear guidance to website owners and developers

To me the use of phrases like "achieve a minimum level of accessibility" for Level 1 SC and "achieve an enhanced level of accessibility"Â? for Level 2 SC do in effect communicate levels of impact on accessibility. As such they do not seem to be much different to the old "priority" approach.

In practice, web developers and regulatory organizations used the WCAG 1.0 Priority levels as a measure for determining levels of accessibility, and they are likely to continue to do so with WCAG 2.0.

On a related point, the Note, "For each success criterion, ..."Â? is clumsily written. I am not sure what this note is intended to communicate, but I presume it is not supposed to suggest the Working Group will be the body that will determine whether a success criterion has been met. Also, if it is possible to meet a success criterion without passing the tests for all the suggested techniques, or for that matter any of the suggested techniques, then surely some people will wonder why they should consider the suggested techniques at all.

Proposed Change:

Following the principle of "when it is not broke don't fix it"Â?, I suggest the Working Group consider retaining the "priority"Â? approach, while of course making any necessary adjustments to the priority levels of some criteria.

The note referred to earlier should be either re-written or removed.

Part of Item:
Comment Type: GE
Comment (including rationale for proposed change):

Guideline 4.2 relates to the need to ensure content is accessible or provide an accessible alternative. I am concerned that overall, WCAG 2.0 does not sufficiently recognise the needs of people with cognitive disabilities or limitations and this guideline in particular does not appear to specifically address these needs.

In my country (and I imagine in most others) people with cognitive disabilities and learning disorders represent the largest proportion of the population with disabilities. In its current state, WCAG 2.0 could leave a site developer, who is keen to improve the accessibility of a site for people with cognitive disabilities, with the incorrect impression that all they need to do is ensure the content is at an appropriate reading level.

WCAG 2.0 should not avoid addressing the needs of people with cognitive disabilities with the vague excuse that it is not immediately possible because today\'s technologies and user agents do not adequately support content negotiation.


Proposed Change:

I strongly urge the Working Group to provide more comprehensive guidance in how to improve the accessibility of web sites for people with cognitive disabilities and learning disorders in WCAG 2.0.

I suggest Guideline 4.2 (and the associated documents) should specify different ways of improving the accessibility of content for people with cognitive disabilities and learning disorders. Also, the Guideline should clearly indicate appropriate ways of providing accessible alternative content.

Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):

The definition really does not add much else and one less term will reduce the length and perceived complexity of the docs.

Proposed Change:

The term ‘pure decoration’ need not be defined. Instead word it to say:
… is purely for decoration or
Is solely for decoration
wherever the term \'pure decoration\' is used as in 1.1.1

Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):

The term ‘live multimedia’ has not been defined while live audio and live video are defined. Although the term ‘live’ is generally understood to mean real-time, I believe the WCAG2 doc should use the word ‘real-time’ in place of ‘live’ as more technically correct.

Proposed Change:

Use \'real-time\' in place of \'live\'
Consider defining real-time multimedia as well.

Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):

SC 1.2.2 and 1.2.3 do not distinguish between ‘standard’ and ‘extended’ audio descriptions. This is quite understandable. The distinction is done in the glossary.
In one situation ‘standard’ ones may be adequate and in another ‘extended’ ones may be needed. This depends on the context and whether adequate pauses are available in multimedia to incorporate audio descriptions. In one case there may be no scope to add even 2 words without creating extended pauses; and in another one may be able to add 50 words without creating extended pauses.

Therefore extended audio descriptions at level 3 (1.2.6) is an unnecessary requirement. They do not ‘enhance’ accessibility but are required when pauses invideo need to be created to incorporate appropriate audio descriptions.
It is understandable that audio descriptions are required to provide minimum accessibility (level 1) or enhance accessibility at level 2 but at level 3 it is repetitive.

Proposed Change:

Drop 1.2.6 completely

Part of Item:
Comment Type: ED
Comment (including rationale for proposed change):

The term \'user agent\' has been defined to include assistive technologies in the UAG as well as in the WCAG glossary. So why use the term \'user agents including assistive technologies\' throughout the document? It occurs several times throughout all the WCAG docs. Restrict it to \'user agents\' and it will reduce length of the docs and verbosity that a screen reader has to endure.

Proposed Change:

Restrict it to \'user agents\' and delete \'including assistive technologies\'.

Comment: Scope of SC 2.5.3 is limited and narrow. It deals with specific forms. Thus, it should be moved to L3.

Proposed Change:

Level 3 Success Criteria for Guideline 2.5
2.5.3 For forms that cause legal or financial transactions to occur, that modify or delete data in data storage systems, or that submit test responses, at least one of the following is true:
1. Actions are reversible.
2. Actions are checked for input errors before going on to the next step in the process.
3. The user is able to review and confirm or correct information before submitting it.

Item number: 1.1.1

Comment (Including rationale for any proposed change)

The fourth bullet in 1.1.1 says "If non-text content is pure decoration, or used only for visual formatting, or if it is not presented to users, it is implemented such that it can be ignored by assistive technology."

The strong implication is that this provision is there to make for less "babble" of unwanted descriptions of items with little/no non-visual intent. This is typically done by using "" (null alt-text) in place of "alt", "longdesc", whatever and does make for a less-cluttered audio environment in the case of a screen reader.

Of greater significance is that it erects an exclusionary wall around a blind user who might be working in a Web Shop and in order to properly deal with the elements in question would be shut out from meaningful communication with co-workers.

This should be re-examined from that point of view.

Proposed Change:

"pure decoration" should not be exempt from descriptive mandates via
text. It is OK to make it easy for some blanket filtering, perhaps by
putting "decor" at the
beginning of the alt-text and having the screen reader know therefrom to
not voice that one.

Good; but there are a few things mis-filed

Proposed Change:

move 3.2.5 to a "what user can do" section containing most of the Principle 2 material.

Move Guideline 2.4 to a "what the user needs to be able to understand" section containing most of what is presently Principle 3 material.

equivalent facilitation does not only apply to future technologies, or only to technologies outside your baseline.
This is a principle that applies across the board.

Compare with comments on "one strike and you're out" roll-up in the comments on the conformance scheme.

Proposed Change:

re-write the document and conformance scheme so that it is obvious that the remedy for a potential problem may come at a different level of aggregation from where the potential problem was noticed.

For example, a CAPTCHA in the login process may be worked around by a totally different login process. In other words the failure of access is local to the image but the affordance of accommodation or relief is through equivalence at the task, not the image, level.

For another example, a diagram in SVG may afford the user a navigable structure of focusable elements. If these represent the notional objects in the scene, and they are suitably titled and otherwise annotated with properties and relationships, the text equvalent for the image may be provided at a lower level of aggregation by providing text associated with the parts of the image.

So the relief may be at a higher or lower level of aggregation from the perception of a possible problem (recognition of a match to the selector or applicability-condition I would call the "left-hand-side" of a rule e.g. success criterion).

the concepts of 'content' and 'presentation' as used here are indadequate to explain the needs of users with disabilities even with today's technology.

Content v. Presentation

Since this is one of the holy cows of accessibility, and I at least feel that this explanation is fundamentally problematical, I think this is a fertile area for discussion.

Hypothetical dialog:

Joe:

"rendering" refers to the rendered content, like an "artist's rendering" of a planned building. This includes everything, the glyphs for making writing evident (perceivable or recognizable) and all the CSS-added effects such as font face, size, bold, and color that the authors mean to imply by 'presentation.'

Moe:

No, the use of 'rendering' here doesn't mean the as-rendered result, it refers to the process of generating that result.

What's wrong with this story?

Preliminaries in terms of terminology
Both "presentation" and "rendering" are used in plain English to refer to either the activity that transforms the content or the resulting representation of the content at the User Interface. This ambiguity could be resolved by more surgical word-smithing.

more serious

The transformation is entirely determined by the technology choices of the author. So if we say 'presentation' is defined by the function of this transformation, we are at the whim of the encoding used between server and User Agent, and we haven't really isolated a genuine rhetorical or semantic distinction.

If we go with "the process that generates the final representation at the User Interface" we find that the division between content and presentation is determined by the author's choice of file format and the implied client-side transformation to the pixel plane or audio out channel.

To make this clear, consider that if we define the difference between presentation and content by the rendering transform, the text-in-images is image content. At least the way PF has been approaching things, this is an erroneous model. Because the text in the image will be _recognized_ by the general user as being a sample of written language, or some sort of code using the writing system of a written language, that language or symbology defines a re-purposable baseline for adapting the look and feel of the user experience to get within the capture regime of the user's sensation, perception, and conception.

* most serious:

The distinction is not only not defined by this language in the document, it is not definable in any stable and fair way.

Starting at the sensible user interface, we can articulate different deconstructions, or "content hypotheses" for what is presented to the user. In the case of textual content, that's not a big problem, the Unicode character set provides a good level of abstraction that

a) supports client-side personalization of the rendered form of the writing, and b) is readily verifiable by the author as "yes, that's what I said."

The problem is that a lot of the connotations that are communicated by arrangement and other articulable features in the scene presented to the user are much less readily articulated or validated by the author. And depending on the media-critical skill and habitual vocabulary of the knowledge engineer doing the deconstruction, you will get rather different information graphs as an articulation of the 'content' of the scene.

Contemporary web page design is more poster design that essay composition. And it is more interactive than what was supported in HTML1 or HTML2. It is the design of a richly decorated and annotated button-board -- a collection of clickables which the site and author think would appeal to the visitor based on what they know from the dialog so far. But that doesn't guarantee a lot of relationship between the different fragments mashed together into the page. If the page does focus on one coherent story, the page will list higher in search results. But that hasn't taken over practice in the field yet.

So the information that is implicit in the [complete, including glyphs, etc.] rendered form of the content is a mix of that which is readily articulable, and the author will readily recognize as articulable, and other information that at first seems ineffable until a skilled media critic analyzes it and presents an analysis to the author or designer; only then can they recognize that there are articulable properties about their stuff. If the analyst is working from an information model of properties and relationships that are known to survive re-purposing and re-enforce usability in the re-purposed rendering, then this process of backing up appearances (including sonic appearances if included) with an articulable model will in fact enable better access, better usability in the adapted experience. And it will also improve usability on the whole in the un-adapted user experience, but more weakly. There will be fewer task failures for the nominal user if the model underpinnings are not provided than for the user who has to depend on an adapted user experience, an off-nominal look and feel.

** so where do we go? how to do it right?

My latest attempt at a summary is the presentation I did at the Plenary Day on 1 March.

<quote
cite="http://www.w3.org/2006/03/01-Gilman/tree2.xhtml">

afford functional and usable adapted views
function: orientation --
Where am I?
What is there?
What can I do?
function: actuation --
from keyboard and from API
navigation: move "Where am I?
performance: usable --
low task failure rate confirms access to action, orientation
reasonable task-completion time confirms structure,
orientation, navigation

</quote>

What gets into our 'content' model, where we ask authors to encode and share the answers to selected questions, is a modeling decision driven by what we *know* about the functional differences between PWD and nominal use of the User Interface.

In other words, we know that the "current context" -- the user's gut understanding of the extent of the answer to "where am I?" -- that you can reliably keep in foreground memory on the fly in a Text-To-Speech readout of a page is a smaller neighborhood than what the visual user perceives as the context that they are operating in. This is why there has to be information that supports the system prompting the user about where they are and where they can go -- navigation assitance -- *inside* the page, more consistently and at a finer grain than the full-vision user needs.

The screen reader user without Braille has more local neighborhoods that have to be explainable in terms of "where am I?" and hence more levels of "where am I?" answers in the decomposition of the page. Most of those levels or groupings are evident in the visual presentation, but we have to coach the author in articulating, labeling, and encoding the industrial-strength explanation of page structure beyond what is enforced by better/worse differences in user experience under nominal use conditions.

This effect is readily understood in the area of orienting for "what can I do?" This requires good labeling for hyperlinks, form controls, and other presented objects that invite user action. This is pretty well set out in

Both WCAG1 and WCAG2.

The model of what information to ask for as regards intra-page structure is less well resolved in the community (there is less endemic agreement on what this information is). We have hopes for the "time to reach" metric analysis used in ADesigner (from IBM Japan) as a way to communicate when and where they need to improve the markup of intrapage structure.

The bottom line is that we should stop trying to generate disability-blind specifics at a level as low as the Success Criteria without getting more specific about known disability-specific adaptations in the look and feel of the web browse experience. Analyze the usability drivers in the adapted look-and-feel situations, and then harmonize the content model across multiple adaptations of look and feel including the null adaptation.

[one principle I missed in the Tech Plenary presentation:]
-- the first principle, that I did brief, is to:

- enable enough personalization so that the user can achieve a functional user experience (function and performance as described at Plenary)

-- the second principle that we have talked about with DI but did not discuss in the brief pitch at Plenary is to:

- enable the user to achieve this with a little perturbation in the look and feel as possible; in other words the equivalence between the adapted and unadapted user experiences should be recognizable at as low a level as possible. Using adaptations (equivalent facilitation) which require a high level of abstraction (task level) to recognize their equivalence is both necessary and OK if there is no less invasive way to afford a functional user experience. But most of the time there's an easier way, and while what is hard should be possible, what is easy should indeed be easy.

Proposed Change:

Apply the suggestions under "two interfaces" comments, to wit:
Articulate requirements a) against the rendered content as it contributes directly to the user experience b) against the content as communicated between the server and the user agent -- the formal model created by the format and exposed by the document object that results from the "clean parse (see IBM suggestions there).

Enumerate information requirements that have to be satisfied by the formal model in terms of questions that the content object must be able to answer in response to a predictable query (programmatically determined requirement). Most of these are context-adapted versions of "Where am I? What is _there_? and What can I do?"

Part of Item:
Comment Type: GE
Comment (Including rationale for any proposed change):

This is related to user-entered or contributed content. It was brought to discussion on May 4th WCAG con call already with no conclusion. Due to the fact that you can violate WCAG with an ASCII smily face (1.1.1) or change of language without proper tag, or use of jargon, any user input can potentially violate WCAG. If the user input resurface, even as input confirmation, the web unit would automatically fail WCAG. All seach engines would fail because it cannot stop users from typing in an ASCII smily in the search box. The subsequent search result screen of finding x number, even if it is 0, of hits with the smily would fail. This is the same with foreign languages and jargon. All websites containing logon screen would fail because user can type in a smily face into the user id box, whether such user id exist or not. The system returns to confirm the id. The web unit of the confirmation just failed WCAG. All webmails would fail because incoming mails could come from a plain text mail client or contain inaccessible mail content of all sorts. Webmail cannot alter the content of incoming email without violation of privacy, at the minimum. No webmail can claim conformity. All photosites would fail because user can always put in empty or inproper alt tag of photos that they submit. All blogs would fail because user input is essential. Product user reviews, such as those in Amazon or Cnet, would fail.

The list can go on and extend to all web applications. As soon as a user agent accepts user input that are not restricted (anything other than dropdown list or radio button), they cannot conform. In fact, comment area of WCAG 2.0 last call fails because you cannot stop me from typing in jargon, foreign language, or ascii art. I'm making this violation at the botton of the mail just to make a point. Scoping out user-entered content is extremely difficult for many sites, especially when user-entered content is pervasive. How would a blog, web mail, evite, business application scope out user-entered content? Such information is essentially on every web unit.

怎么过关
wie Sie den Test führen können
:)

Proposed Change:

Add a paragraph in the comformance area that user-contributed content is automatically scoped out.

Part of Item:
Comment Type: general comment
Comment (including rationale for proposed change):

Requiring alternative version from the same URI would not be logical if the content in question is part of the process. In other words, you normally would not switch to alternative version or text-only version in the middle of a check-out process. You normally do it at the beginning of the process that lead to throught the original or alternative version.

Proposed Change:

Add \"except if the content is part of a process and that alternative version selection can be made by the user at the beginning of the process.\" to 4.2.1. Yes, I know this is longwinded. It is not a live or die problem. But it would make logical sense.

The WCAG 1.0 priority scheme is used consistently in all WAI specs but WCAG 2.0 is defining a new priority scheme with Levels 1, 2, and 3.

Proposed Change:

Use a consistent prioritization scheme in all WAI specs

Comment: the current wording is hard to comprehend - why not use the simpler wording from WCAG 1.0 Checkpoint 13.1?

Proposed Change:

Simplify the language.

Comment: Everyones I speak to has trouble with the UN definition approach

Proposed Change:

Why not just say 'X years of schooling'? Or something else equally understandable drawn from the UN definition.

Part of Item:
Comment Type: general comment
Comment (including rationale for proposed change):

Whilst WAI has been a political success, the WAI model (reliant of WCAG, ATAG and UUAG) is fundamentally flawed and has quite clearly failed. The individual guidelines themselves are flawed, as we are seeing with the move to WCAG 1.0.

In addition, the WAI guidelines, which seek to address *Web* accessibility can act to the detriment of wider accessibility, which may be addressed at an operating system level, for example, or by other approaches, such as that taken by the IMS AccessForAlll approach.

It should also be noted that IMS has a different definition of disability to WAI, which is based on a social model, rather thab WAI\'s medical model. It is unfortunate that the WAI approach is based on a model which is not universally applicable.

However rather than seeking to develop a more open and user-focussed approach, WCAG 2 takes a very technical approach which is difficult to understand. It also fails to allow for a diversity of approaches to accessibility.

This is very worrying, as WAI should be seeking to develop a broad model which will provide a solid foundation for building accessibility. Attempting to build a standard on the flawed approach of WCAG 2.0 will be counter-productive for accessibility and undermine the work of W3C.

It should also be noted that an over-prescriptive appoach can (is) leading to continued use of provietary solutions (e.g. on Intranets) as there is less of a legal reliance to make non-Web applications accessible.

For further information see:

Contextual Web Accessibility - Maximizing the Benefit of Accessibility Guidelines, <http://www.ukoln.ac.uk/web-focus/papers/w4a-2006/>

Forcing Standardization or Accommodating Diversity? A Framework for Applying the WCAG in the Real World, <http://www.ukoln.ac.uk/web-focus/papers/w4a-2005/>

Proposed Change:

My proposals:

o Withdraw WCAG 2.0
o Produce an errata for WCAG 1.0
o Develop an open approach/model for accessibility
o Be explicit in \'difficult\' examples of applications of WAI guidelines (e.g. Podcasting)

Comment (including rationale for any proposed change):

We would like to see WCAG 2.0 applied to as many
non-public (or "commercial") sites as possible

Proposed Change:

A starter package should be developed,
addressing basic accessibility issues

Part of Item:
Comment Type: general comment
Comment (including rationale for proposed change):

The National Confederation of Deaf Persons of Spain (CNSE)have requested to us that we support to obtain an improvement in the accessibility for the deaf people.
Being conscious of the differences between the languages of signs worldwide and the lack of equivalence with the languages spoken in each country, we considered that some reasonable advances by means of the following changes could be included.

Proposed Change:

Include the 1.2.5 in the Level 2 Success Criteria for Guideline 1.2

Based on the definitions, are not all acronyms also initialisms? If so, indicate. I am not an expert.

initialism
shortened form of a name or phrase made from the initial letters of words or syllables contained in that name or phrase. [Are acronyms a type of initialism?]

Proposed Change:

Note: Includes initialisms including acronyms.

Issues with commenting - It is difficult to accurately comment on WCAG2 when the documents that are needed to understand WCAG2 are not normative and are not complete. For example, one cannot interpret a SC without referring to techniques, yet these are not normative. There has been a lot of people saying WCAG2 is difficult to understand, yet they cannot rely on the UW or TD documents as these are neither normative or complete. The WG could vote to significantly change these documents, thereby significantly changing the meaning of particular success criteria, without ever allowing comments from the public. In a perfect world neither the UW or TD documents would be required in order to understand WCAG2 but taking into account the difficulty most people are having with interpreting WCAG2, these documents are becoming mandatory reading.

Proposed Change:

Allow for a subsequent 'Last Call' when all documents are complete, and specify that WCAG2 must be read and interpreted in conjunction with UW and TD documents

Cognitive disabilities - People with cognitive disabilities are unfairly discriminated against within WCAG2. I believe this is due to the usability and testability requirements. It is generally accepted (and one chair has said so explicitly) that requirements that assist people with cognitive disabilities are often general usability techniques. Criteria that assist people with cognitive disabilities is more likely to fall foul of the requirement for testability than other criteria, simply because these criteria recommend changes to the way content is written, not how a site is coded. For example, in WCAG1 Checkpoint 14.1 - Use the clearest and simplest language appropriate for a site's content - still has no clear equivalent in WCAG2 and partiallymaps to Level 3success criteria.

Proposed Change:

Set up a specific taskforce within WCAG WG to identify success criteria that should be added to ensure WCAG2 addresses the needs of people with cognitive disabilities (I volunteer to be a part of, or to head up, this taskforce), or comply with Lisa Seeman's suggestions in her formal objection (which I have cosigned)

Testability - The decision to comply with the testability requirement has outlawed some very important success criteria. This requirement has also not been applied fairly to all success criteria. Some current success criteria do not comply with the 8 out of 10 rule - for example 1.1.1. This SC requires that alternatives to non-text content "serve the same purpose and present the same information". One basic example of this is to require equivalent ALT attributes for images, but I do not believe that 8 out of 10 people would agree on the same ALT attribute for an image. For instance, in the Live in Victoria site (www.liveinvictoria.vic.gov.au) there is an image under the heading "Business Migrants". When I worked on this site, several people said this image should have a null ALT attribute as it conveyed no information. Several other people suggested ALT attributes of "A couple of business migrants chatting at work" or "Guys chatting at work". Whereas the ALT attribute that I recommended was "There is a wealth of opportunities for Business Migrants in Victoria."

Proposed Change:

Remove the requirement for testability and set up a taskforce (I volunteer to work on or head up this taskforce) to identify criteria that should be included in WCAG2. Alternatively, develop a set of supplementary guidelines that are non-testable to be used in conjunction with WCAG2.

Conformance schema - The decision to remove the design requirement from Level 1 has meant there is no appreciable difference between Level 1 and Level 2. I recall many instances where SC were moved to L2 because of this design requirement, yet I have not seen any indication that these SC are being moved back in to L1.

Proposed Change:

Merge Level 1 and Level 2 SC into one group called "Mandatory". Rename Level 3 to "Advisory" or "Optional" Alternatively set up a taskforce (which I volunteer to be a part of, or head) to review L2 and L3 SC to see if they can be moved to L1.

Conformance schema - The documents say that all success criteria are essential to people with disabilities (see WCAG 2.0 under 'Conformance' - "The WCAG WG believes that all SC ..."), however by using the WCAG1 labelling system this change is not obvious. In addition to this, the Conformance section specifically states a hierarchical nature to the to the SC in WCAG2 by defining Level 1 as "achiev(ing) a minimum level of accessibility", Level 2 as "achiev(ing) an enhanced level of accessibility" and Level 3 as "achiev(ing) additional accessibility enhancements". The Conformance section is contradictory, because in the subsequent paragraph it says "Each checkpoint in WCAG 1.0 was assigned a "priority" according to its impact on accessibility... the system of checkpoints and priorities used in WCAG 1 has been replaced...". By using the subjective terms Priority 1 / A in WCAG2, the WG is implying that there is a hierarchical nature to the SC. People are used to the WCAG1 labelling system and will assume that by following all Level A SC that they are creating an accessible web site.

Proposed Change:

Merge Level 1 and Level 2 SC into one group called "Mandatory". Rename Level 3 to "Advisory" or "Optional"

Baseline - Under "Examples of People and Places setting baselines" it says baseline includes only technologies supported by "accessible and affordable user agent(s)". What is the definition of "affordable"? I believe this is advocating technology preference. For instance, if Microsoft created a proprietary technology that only worked only on IE, which came bundled with new versions of Windows, then it could be argued that that proprietary technology could be included in a baseline. The W3C should not be in the advocating anything that supports large corporations taking over the web

Proposed Change:

Remove the baseline theory, or allow only UAAG compliant programs in baseline.

Baseline - All the reasons why the WG left the definition of baseline up to the developers (or governing bodies) could also be used as reasons why the WG have developed an updatable document on technologies with enough accessibility features to be in baseline. The fact that there are no user agents that comply with UAAG is an obvious indication that there are no technologies (yet) that are as accessible as HTML and CSS. I believe it is reckless to leave this decision up to developers or managers whose focus is on the bottom line, not on providing accessible web sites.

Proposed Change:

Develop a document, for use with WCAG2, that list suitable technologies for baseline. This document can be updated by the WG or the W3C every year.

Baseline - Has the WG given any thought to people who decide to turn off technologies that could be in a baseline (eg. Javascript, Flash etc) because that is their preferred way of browsing - due to their disability? Has the WG given any thought to people who use assistive technologies that cannot interpret the output of certain technologies (eg. some screen readers cannot use javascript)?

Proposed Change:

Remove the baseline theory, or allow only UAAG compliant programs in baseline.

Baseline - The theory of baseline will not stop a developer choosing an inappropriate and inaccessible baseline.

Proposed Change:

Remove the baseline theory, or allow only UAAG compliant programs in baseline.

2.5.4: This should be a Level 1 SC. Providing assistance when filling out information is very important to people with disabilities

Proposed Change:

Move 2.5.4 to Level 1

3.2.5 should be at Level 1. It is unclear to me why outlawing changes of context on user initiation is at Level 1(3.2.1) whereas this allows changes of context only on user initiation (3.2.5). They appear contradictory

Proposed Change:

Clarify the SC

Item Number: Success Criterion 2.2.1 <-- this appears to be a typo
Part of Item:
Comment Type: GE
Comment (Including rationale for any proposed change):

I'm not sure about the distinction between 2.1.1 and 2.1.2. Does it mean if there is required time dependant content, such as a reaction time test, the web unit can not comply at level 3. This could potentially be an issues, albeit unlikely, if a site were pursuing Level 2 or 3 conformance, but had a time dependant test, for example.

Proposed Change:

In such a case I would expect an accessibility statement or statement of scope to exclude the timed test, thus rendering the guideline irrelevant to a claim of Level 2 or 3 compliance. 2.1.2 sounds like it may not be enforcable. Perhaps remove it.

4.1.2 includes the phrase "available to user agents, including assistive technologies", but other criteria say "available to user agents" without the "including assistive technologies". The phrase is not strictly required since we define user agents as including assistive technologies; you may feel it's useful to re-emphasize that here, but if that's the case, wouldn't it also be warranted in those criteria that say "programmatically..." by adding "including assistive technology" to the definitions of programmatically set and programmatically determined?

Proposed Change:

Delete the phrase ", including assistive technologies", to read "For all user interface components, the name and role can be programmatically determined, values that can be set by the user can be programmatically set, and notification of changes to these items is available to user agents."

Comment: It feels as if this is a get out clause for a site owner to make all but the most complex area of a site accessible. For example a supermarket can make everything but the online shopping accessible and stop there. It potentially allows to the site owner to get complacent once all but the most complex parts of the site have been made accessible. You can argue that laws enforcing accessibility in a country will bridge this gap of possible apathy but not all countries a) have laws, b) have the will to enforce them. Take for example China in 2008. They could build a site using technologies amount to allowing content based on Ajax i.e. to update timetables etc and leave those sections out of the conformance claims. A basic baseline has to be recommended in WCAG 2, it can't be left to legal, market and other forces from country to country. It can't claim to be a standard if there is not a minimum foundation.

Proposed Change:

This needs to be more water tight. If that section CAN be made accessible (i.e. the techniques exist to make it accessible) then it must be. If it is problematic to make accessible then a clear indication that it is being worked on placed in the conformance claim.

Comment: WCAG1, checkpoint is not reflected in WCAG 2. The WCAG 2 checklist states that this is because it is reflected in the techniques rather than the Success Criteria which are normative. Can be argued that 14.2 is as important to people with cognitive problems as 1.1 and alt text are to VI users. In WCAG one the former was a P3 that later a P1. It may be that because it is not testable that 14.2 hasn't carried over into WCAG 2 but it shouldn't be excluded because it is not testable as it is still a fundamental guideline for this user group. In the Introduction it states that WCAG2 is for people with cognitive and learning problems so therefore this checkpoint should be in WCAG 2.

Comment: References to secondary school in this are at best difficult and confusing for a developer to understand. This type of understanding, i.e. as defined by UNESCO, can be argued to be out of scope of the remit of the web designer to understand and as a result of it being to difficult the checkpoint perceived as woolly and therefore ignored.

Part of Item:
Comment Type: ED
Comment (Including rationale for any proposed change):

Whereas guideline 2.2 is framed in terms of "time limits" on reading and interaction. criterion 2.2.1 instead uses the term "time-out". Neither "time limit" nor "time-out" is defined. This difference in terminology raises the question of whether there is meant to be a distinction between the two concepts. I don't think there is, or ought to be, such a distinction.

Proposed Change:

Use the term "time limits" in 2.2.1, in the same sense as in the text of guideline 2.2 itself. More generally, use "time limit" wherever "time-out" appears in WCAG 2.0. If appropriate, add a glossary entry to clarify the meaning of the term - I think the text of guideline 2.2 is a clear and precise formulation of what is meant.

Part of Item:
Comment Type: ED
Comment (Including rationale for any proposed change):

Should the sentence begin with "Content" or with "The content" (i.e., the content subject to WCAG 2.0 conformance)?

Proposed Change:

Change "Content" to "The content" if appropriate, making sure that it is consistent with wording used elsewhere (i.e., make the change consistently).

Part of Item:
Comment Type: ED
Comment (Including rationale for any proposed change):

Under item 2, consider using "task" rather than "process", especially if my comment on "tasks and processes" is accepted. It is important to use the same word for the same purpose consistently throughout the document.

Proposed Change:

"next step in the task" rather than "in the process".

Part of Item:
Comment Type: QU
Comment (Including rationale for any proposed change):

Should "context-sensitive help" be defined in terms of "the task, or the step in the task, currently being performed"? This would require it to be specific to the over-all task while allowing individual steps in a task to have their own help items.

If it is better to think in terms of tasks, maybe context-sensitive help should be defined accordingly.

Proposed Change:

Part of Item:
Comment Type: GE
Comment (Including rationale for any proposed change):

The mention of "tab order" is somewhat technology-specific and should be generalized in terms of changes of focus.

Proposed Change:

Rewrite the exception about tab order in terms of a change of focus to the next component in a sequence, or in other language that is suitably general.

Part of Item:
Comment Type: editorial
Comment (including rationale for proposed change):

It is difficult to understand the logical relationship in success criteria 1.1.1, because of the \"one of the following\" phrasing.


Proposed Change:

Use the \"at least one of the following\" phrasing from 2.2.1 and 2.5.3; and check for clarity and consistency of logical relationships throughout the rest of the success criteria.

http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform3ch.html

Comment (including rationale for any proposed change):

To my mind the most important aspect if predictability is exposing to the user agent what each thing is. That way the interface can be tailored to the user's access strategy. If XHTML 2 roles are known - what is main and what is secondary navigation, then the order becomes less important.

Proposed Change:

add success criteria

Unfortunately, the selection form requires (or presupposes) a firmer grasp of the baseline concept than many of us have yet been able to achieve. The resulting view if a technology is used but in or not it the baseline is not as clear as we think it ought to be.

Proposed Change:

If feasible, it would be nice if any set of selections also generated a corresponding example of a conformance statement (metadata ready) and a verbal example of what that baseline means and how to interpret it (similar to the examples in "About Baselines and WCAG 2.0").

Comment (including rationale for any proposed change):

The concept of baselines is misleading. One could define "AVI, TXT" as a valid baseline to tell his/her video collection "conform to WCAG 2.0" and can communicate the site as "accessible". To me this is senseless.

Proposed Change:

If there is a baseline, there should be a minimal requirement, at least for "HTML".

Will these examples conform to WCAG? 1. A perfectly conforming blogsite, with comment form, and comments posted by someone breaks the conformance; 2. The page is perfectly conforming, except for a fragment of code which was provided by affiliate program of a shopping site, and the user is not allowed to modify the code either for technical reasons or for legal reasons. From the current wording of WCAG, these examples look to be not conforming to WCAG. This can limit the creativity and variety in ideas for Web content if authors are keen to meet the WCAG, or else, let many authors decide not to care too much about the conformance.

Proposed Change:

Limit the responsibility of the content creator to those Web units that are authored by the creators themselves.

This seems to consist of 1.2.3 and 1.2.7. This structure, where meeting one success criterion automatically means meeting another, is rather confusing.

Proposed Change:

Add a clear explanation of relationship among related SCs, either in the WCAG or in the UW.

This structure, where meeting 1.4.3 automatically means meeting 1.4.1 is rather confusing.

Proposed Change:

Add a clear explanation of relationship among related SCs, either in the WCAG or in the UW.

Today, there are two levels of "being keyboard operable." One is simply being able to operated without using a mouse, with simple keystrokes such as the tab and the enter keys. The other, higher level is where author uses extensive client-side scripting to provide keyboard shortcuts. (The user interface of the Gail is an example.) In the latter case, many of the keystrokes provided by the author may conflict with keyboard commands provided by the UA (including the assistive technology.) Thus, in this case, it would not make much accessibility improvement especially for those using screen readers and other AT that make extensive use of keyboard. Explanation in the WCAG and the Subdocument should be clearer about this point.

Part of Item:
Comment Type: ED
Comment (including rationale for proposed change):

Editorial

Proposed Change:

On Glossary page for ‘role’:
Refer to \'Example: A number that indicates whether an image functions as a hyperlink, command button, or check box.\'
Editorial comment : replace ‘as’ with ‘is’

Part of Item:
Comment Type: GE
Comment (including rationale for proposed change):

Confusing: repetition of requirements for SC at different levels
Question: Does complying with an SC at L1 automatically leads to compliance of an SC at L2?
Example: When audio descriptions for a video are provided (SC1.2.2) then SC 1.2.3 is also being complied with simultaneously, is it not?
In this context what is the difference between ‘minimum level’ and ‘enhanced level’ of accessibility? In what context ? Who decides if it is minimum or enhanced?
In the understanding WCAG 2.0 doc there are no distinctions highlighted between 1.2.2 and 1.2.3 as far as audio descriptions and level of accessibility are concerned.
Conversely, why is not the SC at L1 for GL 1.1 also listed at L2?



Proposed Change:

Do not repeat requirements at L2 if they are already listed at L1 for a guideline; and do not repeat at L3 what is already stated at L1 or L2 for a guideline.
Signed language interpretation is required only at L3 for 1.2 and this is not repeated at L1 or L2. This is how it should be.

Part of Item:
Comment Type: general comment
Comment (including rationale for proposed change):

Consider dropping the top numbering level. Going from three numbering levels (1.1.1.) down to two (1.1.) would make the guidelines feel less complex and less “daunting�? (quote from usability testing participant :).
Add the Principles in the supporting documents, as they do provide nice framing and grouping for the guidelines.


Proposed Change:

* Leave the Principles as they are in /TR/WCAG20. Remove the first numbering from all guidelines and success criteria, e.g.:
- Guideline 1 Provide text alternatives for all non-text content
- Success Criteria 1.1 For all non-text content, one of the following is true
* Add the Principles into “Understanding�?
* Consider including the Principles in the Quick Ref and Checklist.

Congratulations on your Last Call.

One comment that you may have received from others: If the
principles [1] were maintained outside the guidelines [2], then
the guidelines might be easier to find and comprehend. The
guidelines would then have thirteen whole numbers.

Maybe [1] could say which guidelines developed from which
principle. Below is just a text outline. I wonder if the spec
adheres to its subject -- the guidelines -- if implementers may
find the guidelines easier to follow over time.

Hope this helps.

For [1]:
========

* Principle 1: Content must be perceivable (Guidelines 1-4).

* Principle 2: Interface components in the content must be
operable (Guidelines 5-9).

* Principle 3: Content and controls must be understandable
(Guidelines 10-11).

* Principle 4: Content should be robust enough to work with
current and future user agents (including
assistive technologies) (Guidelines 12-13).

For [2]:
========

* Guideline 1: Provide text alternatives for all non-text content.

* Guideline 2: Provide synchronized alternatives for multimedia.

* Guideline 3: Ensure that information and structure can be
separated from presentation.

* Guideline 4: Make it easy to distinguish foreground information
from its background.

* Guideline 5: Make all functionality operable via a keyboard
interface.

* Guideline 6: Allow users to control time limits on their reading
or interaction.

* Guideline 7: Allow users to avoid content that could cause
seizures due to photosensitivity.

* Guideline 8: Provide mechanisms to help users find content, orient
themselves within it, and navigate through it.

* Guideline 9: Help users avoid mistakes and make it easy to correct
mistakes that do occur.

* Guideline 10: Make text content readable and understandable.

* Guideline 11: Make the placement and functionality of content
predictable.

* Guideline 12: Support compatibility with current and future user
agents (including assistive technologies).

* Guideline 13: Ensure that content is accessible or provide an
accessible alternative.

[1]
http://www.w3.org/TR/2006/WD-WCAG20-20060427/intro.html#overview-design-principles
[2] http://www.w3.org/TR/2006/WD-WCAG20-20060427/guidelines.html

Best wishes for your project.

Comment: JIS X 8341-3 also addresses the importance of volume control. It allows the users who are hard of hearing to adjust the volume of the audio. Is it unnecessary for WCAG 2.0 to require the mechanism of the audio volume control?

JIS 5.7 b) says:
<quote>
b) Sound should be controllable by users.

Information:
Hearing impaired users cannot detect that sound is being played. Also, there are cases where louder volume is preferred.

Example:
To enable users to adjust volume, play, and stop, provides controls for play, stop, and volume adjustment. When using plugins, they can be used for this purpose
</quote>

Comment: Validity check is important process to increase accessibility. "Guidelines for Different Components" (http://www.w3.org/WAI/intro/components.php#guidelines) says "WAI guidelines are based on the fundamental technical specifications of the Web, and are developed in coordination with:" If WCAG does not mention to validity, readers of WCAG think WCAG WG thinks little of Web standards.

Proposed Change:

We propose to add Level 2 Success Criteria that requires validity.

Part of Item:
Comment Type: general comment
Comment (including rationale for proposed change):

　The degree of the spread of audio description is different country to country.
I doubt that our situation in audio description is Level1 slightly, because the word “audio description� itself is not penetrated in my country. In Japan some volunteer groups add audio description to movies.
But it is not spread at the movie theater. It is desirable that all Web image content has audio description. But we don’t know what audio description is and how to produce it-this is our present situation. So I feel fear that image content is left out of the Web units intentionally, by we are detected Level1.It is sure that people who lost the sense of sight can’t get any information which is appeared by only animations. Images lacking in text alternatives don’t have information at all, while multimedia　lacking in audio description has much information―lines, sounds and so on. When we hear the sound of train, we can guess the place is a station. We can understand people are angry or laughing by their tone.
It is fact that many blind men enjoy listening TV. Lacking in audio description is not a situation in which there is no information. But producing audio description takes time and money.Level1 is an obstacle for us. So I feel fear that image content is left out of the Scoping of conformance claims.


Proposed Change:

I hope that audio description is prescribed from Level2 and aimed at LevelAA as a following aim.
It will surely improve accessibility of image contents. I think.　

Item number: 1.3.1
Comment type: Editorial

Comment: Problem of language: 'Information and relationships conveyed
through presentation can be programmatically determined, and notification
of changes to these...' To these what?

Proposed change: Clarification needed.

Item number: 3.1.6
Comment type: Editorial

Comment: What is the overlap here to UAAG?

Proposed change: What does the website developer have to do here, and what
does the UA developer have to do?

A sympathetic reading suggests what you want to mean, but this text does not say it.

As rendered, text is represented by glyphs, not Unicode characters. Unicode characters are integer index values into the catalog of characters.

And the critical property is the independence of any structure beyond the stream arrangment of the characters, as demonstrated by the fact that the character sequence is effective in conveying the intended understanding. The sequence of characters in the encoded form is not suffucient. This has been recognized and expressed by the "as rendered" language. But you need to make the cognitive effectiveness aspect of the test more overt.

When natural language is written down, it is often encoded in alphabetical writing systems or scripts. Other forms of communication such as mathematical notations and symbolic identifiers have re-used the characters, or bits and pieces of these writing systems, which have been atomized into recombinant elements by the invention of movable type.

This issue clearly illustrates the superiority of stating separate requirements on the as-rendered representation of the content and on the as-communicated representation thereof.

Proposed Change:

Try:

"Text content is content which conveys its intended meaning when rendered in a sequence of glyphs recognizable as representing the characters from some writing system.

"Content where character sequences are used to form a symbolic code to reconsrtruct media or action scripts, such as the Base64 encoding of a GIF format image, or an ECMASCRIPT imperative instruction set, are to be considered non-text content. Likewise, character sets where the glyphs must be presented in a particular two-dimensional arrangment such as ASCII art are to be considered non-text content."

Add separate encoding requirement:

Text content is to be conveyed from the author's automation to the user's automation [in accordance with | in a mannter interoperable with] the Character Model for the World Wide Web (CharMod).

Consider lifting language from the IMS accessibility metadata documents. IIRC that is where I got this concept.

It is hard to see how the case handled by the second sentence under the first bullet doesn't include the case stated in the second bullet.

The only difference is that in the second bullet the information is asked for in a label, and in the first case in a "text equivalent." In either case the actual requirement is that this minimal information about the non-text context item is required to be available in a way that the user knows it is about the non-text item.

The fact that information in a label need not be replicated in a substitutable text object is true here and is a vest-pocket example of equivalent facilitiation.

Proposed Change:

merge two items under the pattern of "human-understandable text explanation associated with the non-text object by a programmatically determined (i.e. machine recognizable) association."

There is too great a leap, here. One either has to both present the same information and fulfil the same purpose or one only has to provide a nominative description of the purpose in text.

There is an important middle ground.

Proposed Change:

Make it more like the priorities in WCAG1:

The strongest requirement is that the text alternative accomplish the purpose of the non-text content it is an alternative for. The desired way to do this is to present the same information, but that lower-level agreement betweeen the alternatives is at a lower level of criticality.

Even this is not the right requirement because there needs to be recognition that the content can succeed by affording equivalent facilitation i.e. a go-path that succeeds for this user at a higher level of aggregation.

CAPTCHAs, displays that match the "if" clause of the third bullet, can claim conformance under the first bullet by simply saying in the ALT text "image to test if you are a human." It is not just nor do I believe it is the authors' intent to open up this loophole.

Proposed Change:

Close loophole by repairing the first bullet along the lines of the previous comment.

The 'if' clauses don't belong in this construction.
I suspect what you had in mind was a cascade of elseIf clauses.

Proposed Change:

Change from OR (a.k.a. one of the following is true) of
* if A1 then B1
* if A2 then B2
* if A3 then B3
* etc.

to
OR of

* A1 and B1
* A2 and B2
* A3 and B3
* etc.

Exception for moving to next in tab order is not in agreement with customary GUI behavior that the user is accustomed to and will expect.

Proposed Change:

The baseline should be customary GUI behavior, not next in TAB order.

Requiring the explanation to be inline before the control is overly restrictive. If and where the explanation gets rendered is appropriately in the domain of the user's view and verbosity controls. Also "authored unit contains" is too narrow. What matters is that the server delivers the material to the browser.

Proposed Change:

Replace "authored unit contains instructions before the control that describe the behavior" with "the delivered information about the control includes a human-understandable explanation of the behavior that is machine-understandable to be explanatory regarding this control."

Align with requirements in 2.4.4 for links that there be human-understandable stuff bearing required information that is associated with the link or other object by an association that is understandable by the user's automation.

unenforceably vague

Proposed Change:

"item which system feels to be in error is identified."

Identifying the bad entry is enough so long as the entry is prompted/labeled adequately. In other words affordance of help recovering from data entry errors is good advice, but too demanding at a Level 1 success criterion standard.

Also, authors just get this wrong too easily. How many times does the text explanation say "bad password" when the error was in the username?

Error explantions should follow the culture of the desktop. If there is a screen reader in use, this is the screen reader's habits for expressing error messages. The content should define the error as formally as they can. Let the UA and AT worry the friendly message.

If the UA knows it is a type error and the type is identified, then that is enough to synthesize an error explanation in diction the user will understand in the culture of their desktop formed by their AT.

System codes would not make that error. The point is that the server refused the authentication information pair of username *and* password.

Proposed Change:

Separate identification of the bad data from explanation of how it is bad. Move explanation of nature of error to lower level. Allow satisfaction by either text message or metadata understandable by user's automation.

Navigating to another frame or page is "when an element receives focus" and is at the same time a change of context. There is an anticipated change of context in navigation acts which cause an element to receive focus. [AT can track the focus.] What you want to eliminate is surprises -- context changes that could not be predicted from the prior context in which the focus change was precipitated. So you need language that distinguishes the surprises to be avoided from the context changes that the user will anticipate.

Proposed Change:

Re-state as (roughly) "When and element receives focus, it does not have any side effects in the form of a further change of context."

The definition in the Glossary makes the similarity test for things that are to be identified alike too narrow. It says identical result; that is much too narrow. This equivalence class should be made as broad as possible until it starts to degrade the user's ability to predict the system response from the prompt material. For example, context-sensitive help will be identified in the context menu simply as 'help' although the precise results are different for each context. This minimizes the vocabulary the user has to learn. The class of like-identified action opportunities defines the actual concept; the question is how the user's interpretation of the prompt material -- the concept identification -- matches this.

Proposed Change:

Move to section under the education and usability principle "repetition builds recall". In other words, address usability explicitly in the development of the set of provisons, don't just make a vague disclaimer that doesn't admit how what we do say is straight from usability, but applied to mitigating PWD risks of funtion failure, task failure or interminable task times.

Without some restriction on what set is meant, this success criterion is meaningless. But for what you want to say, it can be fixed.

Proposed Change:

"the Web units comprising the scope of a conformance claim"

This clause is unenforceably vague. NLP looks at the term in context and can always produce a vector of meanings weighted with probabilities. This language gives no standard as to how well one has to have isolated one meaning before considering "meaning can be determined without [further help e.g.] pronunciation." Are you OK if the right meaning is the maximum-likelihood estimate? If it is more than 80% likely? If no other meaning is as close as half as likely? What?

Proposed Change:

merge into 3.1.3, as the relevant mechanisms are interchangeable.

Clause is trivially vague. It will either be satisfied or inapplicable, because there is no standard for what set of Web units is pertinent.

Proposed Change:

Introduce concepts of breadcrumb trail as vertical thread through topic categories from here to home and task-phase bar as steps in a sequential process. If one is in a sequential process, need latter to get credit; else former. Because of former, never 'not applicable.' Location within site is always applicable and desirable.

These provisions belong under principle 3. Their domain is the understanding of action opportunities, not whether or not the user can activate them.

Proposed Change:

Reorganize. See comments elsewhere on organization.

Sub-case 1 is by definition not applicable. If the action is reversable, then the user action does not cause i.e. commit to the transaction.

Sub-case 2 is insufficient. Having the system check for a subset of the system's concerns is in no way an indication of the user's informed consent to commit the transaction.

Sub-case 3 is the requirement.

Proposed Change:

Eliminate OR and leave the "opportunity to review" provision only.

Make a note that if the transaction is reversible then the review is required before the subsequent commit transaction, but that this test is not required at the interim step.

is too narrow

Proposed Change:

"for any input where the possible inputs are more varied than five to nine well-known choices"

The role of User Agents is underdeveloped in this document, and the effectiveness of the document suffers.

There is a whole missing principle of "different strokes for different folks."

It is not enough to say "people have to perceive the presentation of information." The encoding or representation of the information in that rendered view must be recognizable. The success criterion is in terms of cognition, not perception.

Further, there is no "one size fits all" presentation that affords a functional user experience for all people. So the fundamental requirement is one of personalization: that the same information can be presented and accepted in diversified look-and-feel variants to reach all the people.

The User Agent doesn't just render the display and process user input events. It also affords the user view-management funtions such as navigation within the document and presentation property profiling. These are managed between the user and the user agent. Sometimes it is not easy to make the rendering transform plastic enough to enable use by all users, and the server has to offer content choices to achieve the full range of under which the web content and/or service is available.

Proposed Change:

Clearly represent that the guidelines set out in this document apply to the data passing through the network interface, not the signals passing through the user interface.

Explain the requirements here (in this document, not a companion note) starting with User Interface requirement, but transformed by the capabilities and needs of User Agents.

"content is perceivable" is an oxymoron. The two are not comparable. The rendering is perceivable. In the rendering, the content must be recognizable.

It doesn't work until the content is re-united with an adapted presentation.

Proposed Change:

change to:
Ensure that presentation can be adapted while preserving content.

Alternate language:
Enable personalization of presentation.

"content is perceiveable" is an oxymoron; the content may be unrecognizable if the features of the rendered presentation are not perceivable, but perceivable features are not an independent principle, they are just a possible failure mode for the success which is understanding what was being represented in the rendered content.

Understanding is an independent requirement, perception is an instrumentality. Compare with how people can frequently read text where all but the first and last letters of each word are obscured beyond recognition. This rendered content would flunk a 'perceivable' test but pass a 'recognizable' test thanks to the inherent redundancy of natural language.

The whitespace between glyphs is either perceivable or not perceivable. The functional requirement if the glyphs are spelling some natural langugage is that the user be able to recognize the natural language represented by the glyphs in the rendered content. The term 'recognizable' is a significantly better fit to the requirement, here, as opposed to 'perceivable.

Proposed Change:

Change to [words to the effect that]

"information is recognizable in the rendered content at the user interface -- a) [best] as configured to be presented by the author and server b) [good] as presented in a delivery context where the user employs readily-achievable adjustments to the look and feel or c) [OK when that's all that works] c) as available in a readily discovered and followed alternate path through the content."

What is this language trying to say? Do you mean MUST NOT? Editorial: CANNOT would be appropriate for an observation as to what is feasible in the medium. This is a remark as to what the author believes is appropriate in this genre.

It is also neither an accessibility issue nor is it always a good idea.

Compare this with the language in Success Criterion 1.1.1 where there are specific provisions for a case where the whole purpose of the site is some sort of sensory or perceptual effect or test. In that case the content is allowed to be explained but not accorded universally accessible equivalent facilitation. In the case of such content, such as the tester for Daltonism, it would be both appropriate and polite to mention that this web presence is intended for those with substantial visual acuity to evaluate their color perception.

Proposed Change:

Strike the remark.

This is not adequate reproducibility to be the basis of W3C-recommended interoperability. If the test points don't repeatably produce the desired outcome with lay testers, the statement of the criteria is too arcane for the Web with its millions of authors.

Proposed Change:

(1) Define,
(2) take through the W3C Recommendation process, and
(3) make conformance rely on: more-concrete testable assertions.

What is a process in terms of WCAG conformance is unenforceably vague, and at least in terms of the first example given, unfairly narrow.

Shopping generally progresses through browse, select, and checkout phases. Only the checkout is a rigidly serialized process. And on some sites you can get live assistance by which you could place your order by chat. So using a whole shopping site as an example of a 'process' which is subject to an "all or none" accessibility rule is unduly severe.

Proposed Change:

Include an accounting for equivalent facilitation separate from the individual testable hypotheses and integrated into the rollup of conformance assessment. (see next)

You might want to remark that it's not cool for a shopping site to claim conformance for a subset of the site that doesn't let people complete a purchase. But don't try to fold that policy value judgement into a W3C technical report. Let the latter be technical.

This clause is overly restrictive. The authors appear to be fixated on people writing public policy for the public web. There are other use cases which support cherry-picking requirements with full selectivity.

One of these use cases is where a web development organization is subcontracting for media fragments -- icons and background images or the like -- from a subcontractor and writes a standard for acceptable data packages which requires metadata to go with each including provenance, sample ALT text, etc. In this case there is no reason that the customer organization should have to require all of Level A on the piece parts purchased from the subcontractor -- the purchasor will take care of the other aspects before putting the assembled web content out on the web. This requirement as now stated would make that a violation of the Recommendation.

Proposed Change:

Soften the language from an imperative to a Recommendation.

Don't say "you mustn't cite arbitrary subsets," but rather say "if you cite only a subset of the Level 1 Success Criteria, don't represent this as WCAG 2.0 Conformance."

-- alternate wording...

W3C does not regard satisfying a profile of success criteria that does not contain all the Level One success criteria to merit the term "conformance to WCAG 2.0"

Unless a specification or policy requires at least conformance to all Level 1 Success Criteria, do not represent that policy or specification as implementing WCAG 2.0 conformance.

Part of Item:
Comment Type: GE
Comment (including rationale for proposed change):

I am greatly disturbed my the disparaging comments i have read here:http://www.sitepoint.com/blogs/2006/05/26/wcag-20-is-broken-leave-your-comments-now/
A quick scan of the document or quotes from it certainly adds evidence to the idea that there is really a corporate law suit protection agenda going on. In the UK we have a campaign body called plain english who award government and organisations for their clear use of language. My quick scan shows a woefully unclear use of language compared to version 1.0.

Please listen up to the more considered opinions you will be hearing / have heard.

Proposed Change:

revert to 1.0!

W2
1.5 (missing)
Intent,
Description,
Examples

I cannot find anything on relative sizing of fonts or layout, at all. (Also noted in other comments.) I believe these are important aspects for accessible computers in general as well as the Internet, for anyone with a mild to moderate visual impairment.

* The most common user agent Internet Explorer (installed on many corporate networks) does not allow the resizing of pixel sized fonts. Nor does the version 7(b3) update. (It does include 'zoom', but this causes horizontal scrolling on any currently accessible site).
* Proper 'zooming' is not generally available yet (although some are working on it.)
* Fixed width/height layouts suffer from a similar problem, partly because they often do not react well to increases in font size. There are some basic layout guidelines for HTML/CSS websites.
* It is applicable to all screen technologies. For example, Flash scales well, but is often trapped in a fixed size window. Acrobat has re-flow & scaling. Other new technologies should be required to scale well.

Relative fonts or layout may be covered in the techniques (although not when I last searched), but I believe it should be part of the normative document (level 2 success criteria).

Proposed Change:

Include a revised version of WCAG 1.0's checkpoint 3.4, example included below. The font aspects could be added to 1.3, but it does not seem a natural fit.

Guideline 1.5 Use scalable fonts and layout
Level 1 Success Criteria for Guideline 1.5

(No level 1 success criteria for this guideline.)
Level 2 Success Criteria for Guideline 1.5

1.5.1 text sizing should be specified in a unit that is user re-sizable. The interface should be perceivable and operable with text increased to a 200% size.

1.5.2 the layout of the page should allow for a variety of screen resolutions and sizes by using relative units for the primary layout areas, such as overall layout, and content area.

-------------------------------
Somewhat short, rough and ready, but I can expand on this if the concept is agreeable. This article on basic layout guidelines (http://alastairc.ac/2006/05/accessible-layouts/) could provide inspiration for the CSS techniques.

Definition of "programmatically determined" is confusing.

Proposed Change:

Proposal for definition of ""programmatically determined"":

""available through content markup (element name, attributes, or properties) or style sheet properties in the case of markup languages or through accessibility APIs in the case of GUI applications.

Note: User agents can extract this information from content markup and style sheet properties and make it available to an assistive technology through programmatic means such as through the DOM or accessibility API. Accessibility APIs may be defined by the technology owner or in a publicly documented alternative recognized as explicitly supporting accessibility.

The term "parsed unambiguously" is difficult to understand.

Proposed Change:

Change 4.1.1 to ""The structure of and relationships within web units and authored components can be determined without the need for user agents or assistive technologies to perform error correction.""

Eliminate the term ""parsed unambiguously"".

This does not address advertisements which can also be an issue for people with disabilities. There should be a method to skip content that is not relevant to the page or site content.

Proposed Change:

Change 2.4.1 to ""A mechanism is available to bypass blocks of content that are repeated on multiple Web units or that are not relevant to the page or site content.""

Alternative proposal: Add an advisory technique to How to meet GL 2.4 or How to meet SC 2.4.1.

Dynamic Web Accessibility allows for an object to have multiple relationships (group, flowto, controlledby). This introduces a situation where the author has more than one possible path to follow. Simple tabbing will not be enough.

Proposed Change:

Change 2.4.6 to ""Components in a Web unit or authored component receive focus in an order that follows relationships and sequences in the content.""

Add an XHTML technique that demonstrates using Dynamic Web Content Accessibility ""group"", ""flowto"" and ""controlledby"" states to How to meet 2.4.6

"Form control" is too technology specific. With DHTML, authors can create interactive controls that are not "form controls". Also, tabbing is too specific. Keyboard navigation is not limited to tabbing. Arrow keys can also be used.

Proposed Change:

Change 3.2.2 to "Changing the setting of any interactive control or field does not automatically cause a change of context (beyond moving to the next field in the navigation sequence), unless the authored unit contains instructions before the control that describe the behavior."

The title for principle 4 does not fit the requirements. Also, future user agents may not render the old content. The principle just does not make sense.

Proposed Change:

Change principle 4 to "Content must be interoperable with assistive technologies."

Repurposed widgets require the user to have state information as well. For example, if a <div> is used to make a checkbox you would need to know if it were checked or not. States, properties, and values need to be programmatically determinable.

Proposed Change:

Change 4.1.2 to "For all user interface components, the name and role can be programmatically determined, states, properties, and values that can be set by the user can programmatically determined and set, and notification of changes to these items is available to user agents, including assistive technologies."

Comment: Why do we need to say that Triple-A only requires conformance to a portion of the level 3 SC? This was the case in WCAG 1 at all levels and we just used to say NA (not applicable) for a checkpoint if there was no multimedia or no frames etc. This particularly relates to the later section suggesting that only 50% of level 3 SC need to be met to claim Triple-A

Proposed Change:

rephrase this Note to specify that not all level 3 SC might apply, and a web unit only needs to conform to the applicable ones to claim triple-A conformance

Comment: para 3 - "... all SC are essential for some people". However, the previous para indicates that Level 1 is sufficient to provide a minimum level of accessibility. This is contradictory.

Proposed Change:

address the contradiction

Comment: para 4 - "When people who understand WCAG 2.0 test the same content using the same success criteria, the same results should be obtained with high inter-rater reliability". More than just an understanding of WCAG 2.0 is required - these people also need an understaning of how PWD interact with the web, with or without assistive technologies.

Proposed Change:

add something extra to the qualifications that WCAG 2.0 testers are required to have to obtain the same results.

Also suggest changing "high inter-rater reliability" to "high inter-tester reliability"

Comment: para 2 - User agents not only "help in retrieving and rendering Web content", but also in interacting with web content

Proposed Change:

change sentence to "help in retrieving, rendering and interacting with Web content"

Comment: para 1 - "assume" is dangerous - they need to "know" the technologies "are" supported.

Proposed Change:

change sentence from "authors need to know what technologies they can assume will be supported by" to "authors need to know what technologies are supported by"

Comment: Examples of scenarios do not seem realistic - what happened to Banks, News sites, Supermarkets, etc providing private services online or selling goods online?

Proposed Change:

more examples are needed - or relegate the examples to the "About Baseline" accompanying document

Comment: In the discussion of baseline and conformance, it seems that there is potential for misuse of baseline [e.g.
authors might be able to just declare their own level of technology, for instance: "requires CSS2 and JavaScript 1.2." The actual/potential audience, not just perceived/target audience or what developers wish they could reply on, should define baseline.

W3C/WAI should consider setting realistic excample baslines for 'everyday' websites in developed/LD countries.

Proposed Change:

Some possible strategies include:

a) to give guidance on what is a realistic baseline for most Internet sites
today, W3C should publish a 'reasonable/realistic' baseline recommended for a general audience;
b) update this 'recommended' baseline annually;
c) place the 'recommended' baseline outside of the WCAG 2.0 normative document;
d) provide an explanation about why the particular baseline is recommended

Comment: I disagree with allowing 50% conformance as sufficient for a AAA pass - we should take the same approach as WCAG 1.0 and require all checkpoints to be passed unless they are 'not applicable'. This approach still works with the concept that not all level 3 SC will apply to all web content.

Proposed Change:

change from 50% to "100% unless not applicable"

Comment: para 1 says thaty WCAG 2.0 makes web content available to a wide range of disabilities, including "blindness and low vision, deafness and hearing loss, learning difficulties, cognitive limitations, limited movement, speech difficulties, and others". It seems that learning difficulties and cognitive limitations are not addressed to any significant extent, in fact even less than WCAG 1.0. It seems the emphasis is even more on 'blindness and low vision' and 'limited movement'. THis may be becasue the strong move to testability, but given that this is the case, then lets not kid everyone (or no-one) that WCAG 2.0 address all disabilities.

Proposed Change:

change wording to leave these out at this stage. Seriously consider the next task for the working group to be to properly address the needs of these groups with suplement or addenda to WCAG 2.0 (or release as a WCAG 2.1)

Comment: Many SC seem out of place at their specified levels. It seems many SC Levels have not been reconsidered since the November 2005 release whe the levels related to 'coding', 'design/appearance' and 'additional'. As this is no longer the basis for the Levels, then the SC need to be more closely re-examined as to the appropriate level they should fall under.

Proposed Change:

re-examine all SC in the light of the April 2006 Conformance Level definitions (cf Nov 2005 Levels definitions)

Comment: "variations in presentation of text can be programmatically determined." - yes, a graphical browser can display italicised text, but not much, if any, AT can determine its existance.

Proposed Change:

reconsider/clarify/strengthen this SC, or drop the last part.

Comment: Under the new Conformance level definitions, I strongly suggest that 2.4.3 should be a Level 1 SC & that 2.4.5 should be a Level 2 SC

Proposed Change:

adjust the levels of 2.4.3 & 2.4.5

Comment: title alone will not make a page understandable - they need to be clear and understandable, and unique (within the site or subsite)

Proposed Change:

reword 2.4.3, e.g. "Web units have understandable/clear and unique titles."

Comment: currently just "Providing skip links to enhance page navigation" - this needs to be specified as a visible means of being able to identify and utilise the ability to skip links

Proposed Change:

Strengthen this technique so that sighted, but physically disabled, people can utilise the link

Comment: The Guideline says "Help users avoid mistakes ..." - none of the SC appear to address this aspect. THey all seem to relate to the second part "... make it easy to correct mistakes that do occur". Surely recommendations such as linear form design, clear and understanable labels, placing examples before the form control, providing instructions, etc, would address the first part.

Proposed Change:

add some SC to address "Help users avoid mistakes"

Comment: 3.2.2 says no change of context "beyond moving to the next field in tab order" - for non-visual browsers, thes may mean they miss out on important aspects of the content without even knowing about them. Very dnagerous!

Proposed Change:

Drop the words that are in the brackets.

Comment: Several WCAG 1.0 checkpoints that are still very important for some people with disabilities are missing from WCAG 2.0:-

1.5 (text equivalents for image map links) - important for people with some learning difficulties (some people are text oriented, others are graphics oriented)

3.4 (relative units) - important for visually impaired people (and others) with varying display resolutions

5.5 (data table summaries - describing the table structure) - important for screen-reader users

10.5 (separating links visually) - acknowledged as important for some people with cognitative disabilities

13.8 (front loading) - important for many people with reading difficulties

14.1 (clear language) - important for many people with reading difficulties; also the related SC are now Level 3 (cf P1 in WCAG 1.0)

14.3 (consistent presentation) - important for many people with reading difficulties, visual impairments, and cognitative disabilities

I acknowledge that some of these may not be machine testable, but they are human (consensus) testable.

Proposed Change:

Add these Checkpoints back in as WCAG 2.0 SC.

Part of Item:
Comment Type: GE
Comment (including rationale for proposed change):

Thoroughly disappointed and disillusioned with WCAG 2.

I had hoped all the \'problems\' would be ironed out by this stage, but it seems that they have just become more ingrained.

To be fair, I can see where you\'re heading - that being specific about things like current technologies runs the risk of being outdated in the near future. I can see why you are using abstracted terms like \'Baseline\' and not further emphasising Validation, but in practice it is not going to work.

Why?

One of the biggest problems I had with WCAG 1 was the non-measurable stuff. You could run your page through a software checker and it would return some results, but others you had to \'interpret\'. It took a lot of training and practice to get people to understand what these guidelines meant. Most found it too hard. Consequently, the vast majority of people/companies think accessibility is simply \'alt\' text for images.

What the accessibility world is really crying out for is a measurable, detectable, practical standard. One that can be used in day to day work without a great deal of knowledge or training.

WCAG 2 seems to have gone in the other direction. Introducing more jargon, less certainty, more difficulty... it is not going to work.

Baseline

As an example, the idea of a Baseline has merit. In a perfect world, it would probably work, technologies would be designed up to acceptable standards and companies would work to improve those standards. In reality, this is rubbish. Without a hurdle, no-one will spend money to achieve a reasonable level of accessibility unless they are forced to do it. You cannot leave the \'stating of baselines\' totally in the hands of the provider, or there will be no incentive to improve. Quite apart from that, setting a baseline will require a level of expertise that most providers simply do not have and probably do not wish to acquire.

If you are wedded to the idea of baselines, then the only way it will work in the \'real\' world is if you set \'minimum baselines\' in those media and channels for which there are w3 or other accessible standards. This would ensure that there is always a point of reference to turn to. These \'minimums\' might be documents separate from WCAG, so needn\'t compromise its longevity, but could be easier to update as technologies change - in fact, improving the relevance of WCAG 2 over time.

Validity

As a trainer and advocate in my workplace for webstandards and accessibility, one of the most effective tools in aiding understanding is the online validator. The W3 HTML validator or accessibility \'checkers\' like Bobby or \"Cynthia Says\"... it doesn\'t matter, the user checks their page and gets some feedback about obvious problems. Of course if a page is not valid code, it often can\'t be checked, so one of the most valuable and visible checks on a page is rendered useless.

As I understand it, Valid Code is not recieving the emphasis I believe it should. There are provisions for validating \'Web Units\', but some uncertainty about whether these will be regarded as \'essential\' to any overall level of success.

I always tell people that a valid page is a big first step towards an accessible page, in fact, I think it is essential and should definitely be right up there as a priority 1 checkpoint - or whatever they\'re called now ;-) Validity is measurable, and helps create semantic, well structured data. Make it a minimum!

Proposed Change:

1) Consider publishing accompanying baseline documents to ensure there is a clear, measureable expectation for levels of conformance.

2) Increase the emphasis of validation to published/accepted/measurable standards

Part of Item:
Comment Type: GE
Comment (including rationale for proposed change):

Prompted, I admit, by http://www.alistapart.com/articles/tohellwithwcag2
I\'m writing to express my disappointment with the WCAG 2.0 draft. The
content is uninspiring and I find the process to be little more than
railroading any public comment. Five years for the draft and a month to
comment? That\'s a rubber-stamp, not an opportunity.

As to the draft itself, then I find it almost worthless. It\'s as
worthless and irrelevant as WCAG 1 was.

I care deeply about web accessibility. As an \"accessibility geek\", I
also find myself in the frustrating position of knowing what to do, but
having repeated management pressure to do just the opposite.
Accessibility still isn\'t a real issue for commercial development and
it\'s leadership from the major bodies that\'s needed most, not developer
education. The information is already out there (Joe Clark, for
starters) and anyone who cares can easily be pointed towards it.

As this draft is though, it presents accessibility as an impossibility
complex matter that\'s about as dry as SGML parsing. There is no way I
can show this WCAG guideline to any sort of manager or commissioning
editor. It falls immediately into deathly dull technical issues couched
in impenetrable language and makes no real case to justify accessibility
as a worthy goal. Even as a technical description for implementors it\'s
almost worthless.

These have always been the failings of the WCAG guidelines. The 1 -> 2
process though has been little more than an updating and tidying
exercise when the document itself required a ground-up re-write. Or more
usefully, throwing away and simply replacing wuith Joe Clark\'s
well-known boook that does a much better job of all of it!

I\'m disappointed that the W3C has lent its name to this document. As a
counter-example I\'m continually surprised by the quality of the HTML
Recommendation and the subtlety of some design choices I\'m only just
realising the value of, even after using the DTD for years. It\'s a
paragon of _why_ a standards process driven by experts is such a great
thing, when it works. The WCAG guidelines though are everything that\'s
bad about the output of standards bodies. Obscure, over-complex,
partial, irrelevant, and basically inaccessible.


I would like to see this draft abandoned and the process re-started --
then a new draft developed, from scratch (or possibly lifted wholesale
from the canonical ref I\'ve already mentioned). This is a massive
change, but I see no possibility of turning the existing draft into
anything useful.

Proposed Change:

Part of Item:
Comment Type: GE
Comment (including rationale for proposed change):

I hope you will publish a list of things to do when designing a website.

Whatever I have read on your site (over time) never seems to get to the point. I would like to know exactly what to do.

thank you,

Betty McLaughlin



Proposed Change:

1. Addressing Cognitive and Learning Disability

WCAG 2.0 claims to define and address the requirements for making Web content accessible to those with learning difficulties, cognitive limitations and others. We do not accept that claim.

Specifically, the success criteria requirements for making content understandable largely ignore the needs of people with learning difficulties and cognitive limitations. Please note that there are guidelines published by other groups that will make content much more accessible to these users. However, with the WCAG claim to address learning difficulties and cognitive limitations, people will not know that they need to look further.

We would like to see continued work in this field and a statement in the WCAG 2.0 abstract and introduction modifying the claim that they currently address accessibility for learning disabilities. Specifically, we recommend removing learning difficulties and cognitive limitations from the list of supported disabilities. A sentence may be added later in the abstract that \"these guidelines may also provide some benefits for people with learning difficulties and cognitive limitations\". We would then like to see a statement of intent such as: \"the working group intends to build additional success criteria to address accessibility for learning disabilities and cognitive limitations.\"

Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):

1.3.2 (color alone) is not sufficiently disambiguated from 1.3.4 (variations in presentations in text). Two of four examples, and only Common Failure, in UNDERSTANDING should be associated with 1.3.4. The implication is that 1.3.4 should be Level 1.

Proposed Change:

Promote 1.3.4 to Level 1. It may then be possible to demote 1.3.2 to Level 2 or 3.

I am also commenting on UNDERSTANDING and TECHNIQUES but with the assumption that 1.3.2 and 1.3.4 are correct as-is.

Comment (including rationale for any proposed change):

Triple-A conformance requires only conformance to a
“portion of level 3 success criteria�?. In practice, this is
set to 50%.

Proposed Change:

This may be more than OK for Web sites developed
for commercial purposes (e.g. by small companies)
but should require more from e.g. public sites, where
competence and resources are less of an issue

Comment (including rationale for any proposed change):

All conformance criteria are based on technical
terms. Is this usable by e.g public procurers?
Testable conformance criteria should be added.

Proposed Change:

A testing methodology should be developed by W3C
with strict requirements and interpretations, in order
to allow for trustworthy and transparent conformance
declarations. Non compliance with conformance
claims trigger a loss of consumer confidence.

Hello,

I don't think there is any point in addressing specific issues with the WCAG 2.0 since there are so many and I have problems with the overall concept of the WCAG 2.0.

I will limit myself to agreeing with Brian Kelly's suggestions (http://lists.w3.org/Archives/Public/public-comments-wcag20/2006Jun/0143.html) to:
o Withdraw WCAG 2.0
o Produce an errata for WCAG 1.0

WCAG 1.0 is outdated and needs some corrections but overall it is a useful document. WCAG 2.0 could not be further removed from what web developers/authors need.
It would have been nice to have a different approach than the one used in WCAG 1.0 - e.g. a truly easy-to-use and accessible web site rather than a set of hyperlinked documents. However, WCAG 2.0 has not addressed the issues web developers had with WCAG 1.0, nor has it built upon the strengths of WCAG 1.0.

During the drafting of WCAG 2.0 many routes have been explored but the result is so far off the track (vague, difficult to understand, hard to navigate) that I think it will be impossible for web developers to apply the guidelines. Many web developers will give up on web accessibility or be confused and as a result, fewer web sites will be accessible.
I hope the WCAG WG can take into account the concerns so many of us have been expressing.

Best regards,

Catherine

Disclaimer: The comments above represent the personal opinion of the sender; they do not necessarily represent the University's viewpoint.

Structural/substantive issue

The current levels system for success criteria seems insufficiently
described, and inappropriate to the needs of developers.

WCAG 20 acknowledges that most criteria are essential in order for some people to be able to use some types of web content. It then attempts to describe the amount of benefit to usersin general (the difference between level 1 and level 2) and the apparent applicability of a technique to the web. It appears that the goal is to provide a "reasonable" implementation planning tool.

Both of these things are in fact situation-dependent. In some cases, it will be easy, in others critical, to apply approaches whose level suggests that they are not so important or easy in the general case.

Thus, while providing a signed equivalent of content is extremely
important in a number of cases, and is occasionally trivially easy (in
others it is quite expensive), it is perfectly possible that all web
content claiming triple-A conformance is without signed content.

Similarly, there is no clear technical justification for different
requirement levels for captioning depending on whether content is
"live"/"real-time", or pre-recorded. The accesibility result for users who rely on captions is exactly the same in both cases. Again, this may be easy to implement in some cases, and is very expensive in others, and its relative importance will be variable.

In order to assist developers, and policy makers, WCAG should describe the imact on users of a particular success criterion being met or not. This enables prioritisation based on the actual situation, rather than a generalised model situation which will often be an inaccurate
representation of the case at hand.

I propose that either:
1. the levels be removed, and the information in the currently informative "Understanding WCAG" about who benefits be moved to the normtive recommendation. Or, as an alternative

2. the specification revert to the WCAG 1.0 priority scheme, rather than with the "apparent ease of implementation" clouding the question of their relevance to users.

cheers

Chaals

Structural/substantive issue

The specification seems to take no account of situations where in fact all
user agents relevant to a given baseline offer functionality that the
guidelines are requiring of authors.

Where this is the case (for example, SVG user agents generally provide a
mechanism to pause any animation independently of the content, and in SVG
tiny it is not possible to provide the functionality in content anyway)
the guidelines should take it into account.

I propose that the baseline section be reworked, to incorporate this type
of situation. Perhaps the most robust way of specifying this would be to
explicitly relate UAAG requirements to WCAG requirements, and note that
where there are (some expression for most or all) user agents for the
baseline which meet a given UAAG requirement the corresponding WCAG
requirement need not be met. Note that the proportion of user agents for
which this needs to be true should be at least as high, and probably
higher than that which is reasonable to justify the use of a particular
baseline in the first place.

The guidelines place in level 3 very many of the requirements necessary to
help people with cognitive and reading disabilities access the web. Since
only 50% of level 3 requirements (as chosen by content authors) need to be
met in order to claim confomance to the guidelines, it is quite possible
to conform to the guidelines at triple-A level while doing very little
(and clearly not enough) to address the needs of these user groups.

I propose either that this be explicitly and clearly explained in the
introductory and conformance sections, or that the levels system be
reworked as per my lat call comment on them.

cheers

Chaals

Technical/substantive issue?

The current requirement fo unambiguous parsing is impossible to meet -
there are always multiple ways of parsing any data.

Instead I suggest the old wording of "conforms to formal published
grammars".

This makes it feasible for User Agents to recognise the content and parse
it either according to the rules for such grammars, or in cases where it
is necessary (such as HTML) to use specifically adapted parsing techniques.

cheers

Chaals

Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):

The term "luminosity" is incorrect here (it applies only to certain Broadcast video signals). Relative luninance is the correct term. When used as a ratio, the difference between absolute and relative Luminance can be dropped, but the term luminance rather than luminosity should be used.

http://www.w3.org/TR/2006/WD-WCAG20-20060427/appendixA.html#luminosity-contrastdef
defines the coefficients for calculating luminance, and its good to see that the Rec.709 chromaticities are used (rather than, for example, the NTSC ones which do not apply to modern computer monitors at all). (the coeeficients are correct, see the "luminanceToAlpha" section of http://www.w3.org/TR/SVG11/filters.html#feColorMatrix but the specification does not explain why this is so.

However the text as it stands implies that the formula given is universally applicable. it is not. This is particularly importnt when printing Web materials.

Proposed Change:

change "luminosity" to luminance throughout.

change "The luminosity of a color is defined as" to "the luminance of an sRGB color is defined as".

change "blue RGB values" to "blue sRGB values" (the equation does not apply to other color spaces).

Remove the exponentiation operator and the 2.2 gamma approximation. Instead, use the correct sRGB transfer curve.

Reference the sRGB specification. See the SVG 1.2Tiny specification for an example of how to reference it.

You may want to note that the equation given is only correct for typicalcolor vision (the ISO standard observer). For atypical color vision, often incorrectly termed color blindness, different equations apply depending on the type of atypical color vision and the degree of severity.
For more information, please see
http://www.w3.org/Graphics/atypical-color-response

Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):

"3.2.2 Changing the setting of any form control or field does not automatically cause a change of context (beyond moving to the next field in tab order), unless the authored unit contains instructions before the control that describe the behavior"

Consider a user interface for a map, where form fields such as panning controls, layer selections or search boxes are used to zoom,pan, or alter a map. This common use seems to be precluded by the text above.

Proposed Change:

I regret not being able to suggest suitable text at this time. I can see the benefit of what you are trying to do, and I can see that it makes non-confomant some interfaces that are currently used. I think the text needs to be more precise, and look forward to discussing this further with you.

Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):

The term "parsed unambiguously" is ambiguous. Parsing requires a set of rules and without those rules the parsing result may be meaningless. For example, an HTML file may be parsed using the rule "by line". It may also be parsed using the rule "by sentence and word". This parsing will produce an unambiguous tree structure but has no effect on accessibility. I believe the intent of the SC is to include the set of rules (e.g. DTD or schema) that has an effect on accessibility.

Proposed Change:

Include text that specifies the set of rules needed to parse the document. Example: "Web units or authored components can be parsed unambiguously using the specification that affects accessibility...". In the techniques document you can specify the appropriate rules such as in HTML use one of the standard DTDs.

Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):

The text \"modify or delete data in data storage systems\" is very broad. Even submitting a search to Google will do this - Google will store info about your request.


Proposed Change:

Add text that describes data as important or non trivial to enter again.

Part of Item:
Comment Type: substantive
Comment (including rationale for proposed change):

The Success Criterion (1.3.1 level 1) that calls for the presence of labels is at a different level from the Success Criterion (2.4.5 level 3) that requires the labels actually describe the item. This applies to such items as form labels, headings, titles and table captions. This is an inducement for placeholder text and will functionally decrease accessibility. Examples: web pages with the title \"title goes here\", table captions of \"table caption\" and form control labels \"control name goes here\" are perfectly acceptable. If the requirements for the presence of the label are lower than the requirement than the label actually be descriptive it will be an incentive for authoring programs to put in placeholder text. Requiring that a label be present without a requirement that the label be useful does not make sense.

Proposed Change:

Change the level of SC 2.4.5 to level 1 (same level as SC 1.3.1).
Or remove SC 2.4.5 and modify SC 1.3.1, SC 2.4.3 and any SC that requires text so they include the text from SC 2.4.5. Example: change SC 2.4.3 so it reads \"Web units have titles that describe the web unit\".

Part of Item:
Comment Type: substantive
Comment (including rationale for proposed change):

Success Criterion 2.4.4 should be at level 1 and is currently at level 2. Good link text is very important for people with visual impairments as well as people with cognitive impairments. Poor link text was identified as a key problem in the DRC report (http://www.drc-gb.org/PDF/2.pdf). Good link text is at least as important as skip-navigation links which is at level 1.

Proposed Change:

Move SC 2.4.4 to level 1.

Part of Item:
Comment Type: substantive
Comment (including rationale for proposed change):

It\'s still unclear what \"parsed unambiguously\" means when applied to CSS documents. Even a loose interpretation is still a heavy burden for authors as this SC is level 1 and may not improve accessibility.
(This was discussed on list but no resolution.)

Proposed Change:

Clearly define what \"parsed unambiguously\" means when applied to CSS documents. Move SC to level 2 for CSS documents.

Part of Item:
Comment Type: substantive
Comment (including rationale for proposed change):

The technique H71 (fieldset and legend) under SC 1.3.1 is helpful but not necessary for all groups of controls. This is now at level 1 and should be moved to level 2. An example file was posted to the list (http://checker.atrc.utoronto.ca/docs/file2.html) that is very accessible and commonly used but fails the SC. Authors should not be forced to use fieldset and legend for all groups of controls.

Proposed Change:

Move H71 to level 2.

Part of Item:
Comment Type: GE
Comment (including rationale for proposed change):

To set the scene, I am your average garden-variety web developer. I am a simple soul, with college education, good English skills and above all, good HTML skills. I spend all day, every day, producing sites - for everything from the local dentist to the multi-million pound nation-wide high street chains.

WCAG 2 has disappointed me.

For a start, I just don\'t understand it. I am not stupid, but I just don\'t understand how it applies to what I build. How can I bear all that in mind when going through the stages of planning/building/testing a site?

It\'s going to take months to combine that into my daily routine and to be honest I cannot see the commercial benefit. Most of the sites I build, I make them WCAG 1 level 2 accessible out of good practice and for good karma. I like it; I enjoy the sense of responsibility I get from it. It sets me apart from the monkeys knocking sites out in the back bedroom.

WCAG 2 is so difficult, why would I bother? My customers do not care! If they do, then they will have to pay me a lot to have a compliant site, as the extra amount of time involved does not come for free.

If WCAG 2 was actually simple - a simple to understand a plain-English check list (i.e. - do you use PDF, see page 3, if not continue to page 4 > checklist) along with highly automated checking system, then we are going to see a lot more developers producing compliant sites. Just dream…an internet with more and more compliant web sites. Is that not what we all want?


Proposed Change:

Part of Item:
Comment Type: substantive
Comment (including rationale for proposed change):

The note to SC 3.1.2 reads: \"This requirement does not apply to individual words or phrases that have become part of the primary language of the content.\": this is a problem for foreign words in a passage or quote that is not in the primary language.
This wording was introduced in the June 2006 Working Draft; before that, it read \"This does not include use of foreign words in text where such usage is a standard extension of the language,\" but I believe this was changed because the term \"foreign\" was considered problematic.

Proposed Change:

Rephrase the note to: \"This requirement does not apply to individual words or phrases that have become part of the language of the immediately neighbouring text.\"

Part of Item:
Comment Type: substantive
Comment (including rationale for proposed change):

SC 3.1.4 reads: \" A mechanism for finding the expanded form of abbreviations is available.\"

Since technique G102 (Providing the expansion or explanation of an abbreviation) devotes a lot of attention to situations where you don\'t need to provide an expansion, but e.g. an explanation, this SC could be reworded as \"A mechanism for finding the meaning of abbreviations is available.\" Providing the expansion is only one way to provide the meaning.

Proposed Change:

Reword SC 3.1.4 to: \"A mechanism for finding the meaning of abbreviations is available.\"

Part of Item:
Comment Type: substantive
Comment (including rationale for proposed change):

The definition of Web unit is still ambiguous.

(1) If an HTML document (home.htm) has various linked stylesheets (one for screen, one for print, one for projection, ...), these are not all intended to be rendered together. I think the the following would all count as Web units:
- home.htm with the CSS for \'screen\',
- home.htm with the CSS for \'projection\',
- home.htm with the CSS for \'braille\',
- home.htm with the CSS for \'aural\',
- ...
However, this is not clear from the definition. If these are all different web units, it is also impossible to identify them with a URL, because the URL is the same for each.

(2) If an HTML page uses an object element with one or more fallbacks nested inside it (see the example slightly below http://www.w3.org/TR/1999/REC-html401-19991224/struct/objects.html#idx-object-5), I think the Web unit you claim conformance for is the HTML document with the outermost object element (with the TheEarth.py applet). However, the content of each of the nested object elements is not meant to be rendered together with the content of all the other object elements. Does that mean that there is a different web unit per fallback/nested object element?

(3) If a web page uses frames, the content of some of the frames depends on the user\'s interaction: e.g. clicking a link in the navigation frame opens a different document in the content frame. So the URL that identifies the frameset document does not always identify the same Web unit, unless the Web unit is limited to what is loaded by default.

(4) If user agent X requests URL http://www.example.com/ with MIME type aaa/bbb and user agent Y requests the same URL with MIME type ccc/ddd, and they get different web units because of the different MIME type, the URL cannot be used to differentiate between the two web units. Does that mean these are different Web units according to the current definition?

Most of this was previously discussed on the ERT mailing list in the context of conformance claims (see http://lists.w3.org/Archives/Public/public-wai-ert/2006May/0029.html and next messages in the same thread) and forwarded to the GL list (http://lists.w3.org/Archives/Public/w3c-wai-gl/2006AprJun/0181.html).

Proposed Change:

Part of Item:
Comment Type: substantive
Comment (including rationale for proposed change):

Should the baseline also identify the human or natural languages that the content covered by the conformance claim relies upon?
The rationale for this is twofold.
1. Success criteria 3.1.1 and 3.1.2 require language markup, especially for the benefit of users of speech synthesis and/or braille, but this language markup is of little benefit if the languages are not supported by, for example, the user\'s speech synthesis software.
2. Success criterion 3.1.5 requires supplemental content if text requires a reading ability more advanced than the lower secondary education level, but the algorithms or methods to determine the required reading ability are language-specific. (Similarly, the techniques you use to conform to WCAG depend on the technologies in your baseline.)

Proposed Change:

Consider adding the human languages that the content relies upon to the baseline. (This would imply a distinction between \"baseline technologies\", i.e. the current baseline concept, and \"baseline human languages\".)

3. WCAG defines a "web unit" as "one or more resources, intended to be rendered together, and identified by a single Uniform Resource Identifier ". Resources can in addition consist of moving images, or pages where part of the material is rendered through links into Web Services (such as with AJAX technology). The example given in the definition is static in nature - however in many situations in today's web the end result is not static, or defined solely by a single URI.

This appears to be clarified for a web unit in the section "Conformance claims" - where it states that it "can also take the form of a fully interactive and immersive environment"

However the situation becomes confused by later referring to "Aggregated content" and giving, as an example of this, "a web unit which is assembled from multiple sources that may or may not have their own levels of conformance". In a traditional web page, containing graphics, (as is given as an example in the definition of a "web unit"), this is conventionally exactly how images etc are rendered using the <IMG> tag.

Statements such as "The conformance level for a Web unit that contains authored units is equal to the lowest conformance level claimed for the Web unit content and any of the authored units it contains – including any claims pertaining to aggregated authored units" are extremely unclear, and indeed may be recursive following the unclear distinction apparently made between "web units" and "aggregated content". A "web page" on the other hand is fairly well understood. BSI recommend(s) a closer look at an accurately defined and understood syntax which is not open to misinterpretation and clearly conveys the ideas being communicated.

7. In the section "Examples of conformance claims", "jpeg" is specified as a requirement of one example (examples use "Real Video" and "png" in a similar manner). These are not testable specifications in the same sense as XHTML 1.0 (Strict) - for example progressive jpeg support was only added to many browsers long after the basic sub-baseline jpeg (actually correctly JPEG) decoding was implemented. IS 10918-1 | T.81 (which presumably is what is intended by JPEG) defines a 'shopping list' of image compression techniques, including a baseline. Actual JPEG implementations excludes many items in the list, and add other items (typically JFIF/EXIF file support), and are, almost without exception, sub-baseline. A claim that an item "relies upon" jpeg (sic) is fairly meaningless, and is dependent on many things other than a correct interpretation of parts of IS 10918-1 (for example bit resolution and colour rendering of the display)

8 A number of the test criteria and suggested 'solutions' are far from clear. For example, Guideline 1.2 at level 3 success criteria suggests the use of sign language interpretation for multimedia. Following the references in the specification lead to the "Understanding WCAG 2.0" document suggests including a sign language interpreter in the corner of the video stream. There are many sign languages - for example English and US sign languages are different and believed to be mutually unintelligible. No suggestion is made as to how to resolve this for (for example) an English language documentary. Clearly in this instance one possible solutions would be to use overlay replaceable video technology (as offered for example in MPEG-4 technology) rather than conventional digitised video as offered by MPEG1 or MPEG2 technology.

9 Comments on Appendix A - Glossary (Normative). This section should be re-written (preferably by a standards editor). Almost every definition is inaccurate, inappropriate or unnecessary. Several are simply incorrect. Starting just with those beginning with
A...

Definition of acronym is incorrect (relates to definition of abbreviation and initialism). An acronym is "A word formed from the initial letters or parts of other words" (SOED). An initialism is a subset of this, being formed from initials. Missing out the words 'parts of other words' is both incorrect and makes initialism and acronym identical.

Definition of "activity where timing is essential". 'Timing' should be defined for clarification (or better described in the definition).

Definition of "analog, time-dependent input" - This is 'analog, time-dependent movement', presumably as opposed to "digital, time dependent movement". Whilst not being very clear, adding a definition which constrains this to a very specific meaning in the context of a pointing device may not be useful. The wording should stand on its own as English text, and is not proper to a definition section.

Definition of ASCII art. It is assumed that an image rendered from many small images would classify as ASCII art (examples exist). The spatial arrangement is therefore of glyphs (or similar small sized graphical objects), not characters - their rendition is what provides the pseudo-photographic output.

Definition of "authored unit" (and implicitly "authored component"). See comments above about confusion between authored unit, component and web unit)

Other errors include: Re-definition of text (SOED: the wording of something written or printed). Unicode is defined by the Unicode Consortium (www.unicode.org) and no longer aligns with ISOIEC 10646-1 (or 106464, whatever that is supposed to be!)

Some definitions (eg Luminosity contrast ratio) are in the vein of defining pi as 22/7 - input from the relevant standards body (eg CIE) could have avoided these basic errors. In several places, values are referred to as RGB without any reference to colour spaces. Many definition would be much improved by using the same word definitions as are used in other Standards, where similar terms are correctly defined, and then simply referred to the appropriate Standard in the definition (or worst case by repeating verbatim the wording used in the Standard).

12. The role of blinking and flashing content is confused -
http://www.w3.org/TR/WCAG20/complete.html#time-limits-blink and
http://www.w3.org/TR/UNDERSTANDING-WCAG20/#seizure-does-not-violate-terms

CLARIFICATION
________________________________________
From: David Keech [mailto:David.Keech@BSI-GLOBAL.COM]
Sent: Friday, July 21, 2006 7:46 AM
To: Gregg Vanderheiden
Subject: RE: comment #12 clarification
Gregg

Sorry for the delay in clarifying our comment.

Regarding our statement:

• “The role of blinking and flashing content is hopelessly confused - http://www.w3.org/TR/WCAG20/complete.html#time-limits-blink and http://www.w3.org/TR/UNDERSTANDING-WCAG20/#seizure-does-not-violate-terms"

The distinction between blinking and flashing is very difficult to understand and is apparently drawn from human factors research into visual display devices such as television, where fairly precise measurement and control of flash rates is possible (we assume).

On the web we anticipate that the exact nature of the flash/blink behaviour will be affected by local conditions such as monitor refresh and hardware performance.

Furthermore, given that there are numerous ways to make an item Flash on the web, through the use of combinations of CSS and Javascript among other techniques, how can flash/blink rate be reliably tested?

If content cannot blink for more than three seconds (where blinking means "turn on and off between 0.5 and 3 times per second") it is presumably acceptable that content blinks for 0.49 times per second for 2.99 seconds....Is this sensible?

The most reliable method is to disallow blinking/flashing, any other suggestion is virtually impossible to work with in our view.

Please let me know if there is still any confusion.

Regards

David Keech
BSI
ICT/0070/06

Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):

I think there are problems with the idea that someone can claim level 3 conformance if they do only 50% of the techniques that apply to their content. That means someone could claim Level 3 conformance and have an audio track that has a loud background when there is a Level 3 SC that specifically says don't do this. I realize that some Level three items are very difficult. But that is what level 3 is all about - going above and beyond. (If some of our Level 3 SC are unrealistically difficult then let's remove those ones) On the other hand, if we are just providing level 3 as a way to encourage people to provide extra accessibility then it should not be a Level but rather a separate advisory section of our guidelines. I don't think we can allow people to say they have reached a level of conformance while blatantly while breaking the GL or SC in that level. I think it undermines the integrity of our Guidelines. I think it will be a source of much confusion and conflict in the public and among disability groups.

Proposed Change:

Require 100% of Level 3 SC that apply to the content to be met in order to meet Level 3. If there are some SC that the group identifies as unrealistically difficult then remove them to a separate document called something like "going the extra mile."

We need a definition of “relationship� for the glossary as it pertains to SC 1.3.1


1.3.1 Information and relationships conveyed through presentation can be programmatically determined, and notification of changes to these is available to user agents, including assistive technologies. [How to meet 1.3.1]


Here is my recommendation:

Definition of *Relationships*:

"Meaningful associations between distinct chunks of content"

Examples of chunks that have relationships include:
-a heading and the paragraph which follows it;
-a section title and the subsections that are within it;
-a control and its label;
-the boxes in an organization or flow chart;
-and table cells and their headers

Note: "Chunks" could also be "Blocks" or "Pieces"

Currently, 2.1.1 is not clear that HTML fallback techniques for Javascript dropdown menus are sufficient. Nor is our conformance section clear that deficiences on one web unit can be made up on another web unit. For example the LongDesc (1.1) provides an alternative on a separate web unit. But our conformance is "web unit" based. We need to allow for this.

This came up because many corporate web sites are meeting 508 compliance by having a JavaScript dropdown menu where the top item is a keyboard accessible link that goes to a separate page that has all of the links that were in the dropdown menu.

WebAim recommends this technique here.

http://www.webaim.org/techniques/javascript/eventhandlers.php (see example 2)

Real examples are here:
http://www.cab-acr.ca/english/default.shtm
http://www.futurescholar.com/Home.htm

When I read 2.1.1 and I thought about the (per Web Unit) conformance it seemed to me that our current wording didn’t allow it. Ben thought it might be able to go in Guideline 4 but if someone had JavaScript in their Baseline then I think 2.1.1 would apply… I talked with Michael and Bruce and they both thought we should clarify that this is a viable navigation strategy.

Gregg responded:
>>>One has to be completely accessible except that there can be a link from an inaccessible part to an accessible version of that part if it can be viewed independently – and then you return. (this is in fact what we do with Longdesc). I would run this answer past group A though just to be sure before I used it (unless you are just using it in an issue summary going to a team anyway.

Recommend:

How about something like in 2.1.1

Situation: For pages that have script or programmatic pop down navigation menus when that technology is not in the baseline

1. Providing an HTML link to a place (on the same page or a separate page) with the navigation menu in HTML

If script in baseline - then you CAN use “Create HTML fallbacks for Javascript menus� OR you can just have js script menu with full keyboard access

If script not in baseline – you CAN “Create HTML fallbacks for Javascript menus�. Full keyboard access to menu does NOT satisfy SC.

Also: Add phrase to the conformance section that allows for make up alternatives on a separate Web Unit directly accessed from a web unit.

(longdesc and HTML fallbacks for JavaScript menus).

How to Meet Success Criterion 2.5.1
2.5.1 If an input error is detected, the error is identified and described to the user in text. (Level 1)

There is no sufficient server side technique. Such as ASP, PHP etc...
I'm guess this is because we don't offer server side techniques on our site. But it brings up an issue that some people may think server side techniques are not sufficient because they are not listed. If we don't add anything to the "How To" document I think we need to make it clear that there are ways to meet the SC with server side programming and they are omitted from our Sufficient techniques because we do not do Server side exampes and not because they are not sufficient.

Why is F36 Example 2 a deprecated example.

"Failure Example 2:
This is a deprecated example that submits a form when the user selects an option from the menu."

I think it is still an issue and it us used all the time.

We could also add to it that Blind users and users with hand tremors can easily make a mistake on which item on the dropdown menu to choose and they are taken to the wrong destination before they can correct it.

Therefore the technique can also be linked from 2.5.1. I think. Because it would also be a failure to that technique.

I recently was evaluating a corporate web site that had image text as a title for a list of links. They had the image in the <p> element so Jaws would not identify it as a heading. I think we need a sufficient technique in 1.3.1 or an example added to H42 that says something like:

"Using heading markup to identify image text that is acting as a heading."

An example would look something like this.
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Cities of interest</title>
</head>
<body>
<h1><img src="../images/cities_of_interest.jpg" alt="cities of interest" width="91" height="95"/></h1>
<ul>
<li>Barcelona</li>
<li>New York</li>
<li>Paris</li>
</ul>
</body>
</html>

Response to WCAG 2.0

From the following UK organisations:

* JISC TechDis Service, Higher Education Academy Building, Innovation Way, York, YO10 5BR
* BECTA (British Educational Communications and Technology Agency), Millburn Hill Road, Science Park, Coventry, CV4 7JJ
* UKOLN, University of Bath, Bath, BA2 7AY
* JISC CETIS (Centre For Educational Technology Interoperability Standards), Research Institute for Enhancing Learning, Padarn, School of Education, University of Wales Bangor, Normal Site, Bangor, Gwynedd, LL57 2PZ
* Scottish Disability Team (SDT), Ewing Annexe, University of Dundee, Dundee, DD1 4HN
* Digital Media Access Group (DMAG), School of Computing, University of Dundee, Dundee, DD1 4HN

Contact: David Sloan, Digital Media Access Group (DMAG), School of Computing, University of Dundee, Dundee, DD1 4HN; dsloan @ computing.dundee.ac.uk

Summary

The above organisations, all active in the UK education/technology/disability field, broadly support the principles of inclusive Web design as set out by WCAG 2.0. We also have some reservations, many of which have been expressed elsewhere, over the practical application of WCAG 2.0 in its present form. We offer some general recommendations which, if followed, we believe will better serve Web content providers in the community in which we work.

Background

The 'Last Call' draft of version 2.0 of the Web Content Accessibility Guidelines (WCAG) has, since publication in April, attracted a significant amount of public comment, much of it of a negative nature. The authors of this response are all organisations heavily involved in promoting the appropriate use of technology to make access to education in the UK by disabled people as easy and effective as possible. We realise the importance of what will be the successor to the current de facto global standard for web accessibility in influencing commissioners and developers of Web content and applications, and all believe that WCAG 2.0 must build on WCAG 1.0 to improve, rather than inhibit levels of accessibility online.

We do not wish to repeat other detailed responses by providing a line by line critique of the current draft. Instead we present a higher-level view, outlining our concerns and our support where appropriate.

General

We note the many other responses that have been submitted to WAI in response to WCAG, and while we share the concerns expressed over the likely difficulty many developers will have in applying WCAG to HTML development, we strongly support the need to present Web accessibility as something more than "just following guidelines".

We are also conscious of the difficulty of developing accessibility guidelines, while also emphasising that readers must also be familiar with the ways in which disabled people access and use the Web; and the role of authoring and browsing tools - and their limitations - in ensuring an optimally accessible Web.

Our involvement in education has influenced our belief that Web accessibility should be considered on two levels:

* Developing Web sites to minimise the chances of excluding access by people with sensory, physical or cognitive impairments.
* Using the potential of Web resources to improve access to real-world information, experiences and services for disabled people.

This requires a holistic approach to Web accessibility - where development is driven by enabling the target audience to access and use the site for the intended purpose in the intended environment, whatever that may be [1, 2, 3]. In the UK, the recent emergence of PAS 78 [4] has highlighted the importance of other factors in optimising Web accessibility beyond technical conformance.

We believe that the principles and guidelines set out in the WCAG 2.0 Last Call draft offer a solid platform on which to build on the two levels above. In particular, the technology-neutral approach adopted by WCAG supports authors in providing the best solution for the resource and audience in mind, whatever that may be. We further believe that the Baseline concept is an important step to enabling a more audience-focused approach to development, by allowing WCAG conformance to be specified in the context of a defined user environment that accurately represents reality.

We also note the tensions that appear to have emerged between the Web Standards movement and the Web Accessibility movement. We support the principle of open standards adoption, we know of the accessibility benefits that standards-conformance can bring; but we also realise that standards-compliance is not always equivalent to optimal accessibility of experiences, services and information for disabled people. Therefore we appreciate the difficulty that WAI has faced in deciding where and how to include designing to HTML (and other) standards within WCAG 2.0. Standards-conformance should be strongly encouraged; at the same time, considering the relationship between WCAG and disability legislation around the world, the potential situation of a Web site being declared unlawful (or being removed for fear of being unlawful) because it fails to validate to a particular technical standard, despite no evidence to indicate that a specific group of disabled people face undue discrimination, must be avoided.
Concerns

As noted, we are concerned at the level of negative reaction to WCAG, much of which has come from prominent individuals in the field of web accessibility, notably [5]. We echo these concerns:
Extent of supporting documentation and relationship between WCAG 2.0 and Techniques for HTML development

The amount of documentation supporting the guidelines is immense; increasing complexity of navigation between guidelines and supporting documentation. We have welcomed the appearance in recent months of high-quality supporting material that has appeared on the redesigned WAI web site. However, we fear that the split between general guidelines and non-normative direction for specific technology development may lead to inappropriate solutions being applied. Given that, initially, most users of WCAG 2.0 will be HTML authors, this complexity, and in particular the relationship between WCAG and HTML Techniques needs to be revisited.

Baseline

We reject the arguments expressed elsewhere that the Baseline concept promotes a return to browser-specific development. However we recognise that there is scope for authors to abuse the Baseline concept, which therefore needs to be defined more coherently. We would anticipate that in the UK, were a case of alleged discrimination under the DDA to come to court, any court decision should look at the baseline (if specified) and its appropriateness to the target audience, and therefore baseline definition becomes a critical task.
Support for people with learning difficulties/disabilities

We share concerns expressed by others over the lack of focus on supporting people with varying cognitive impairments. We would like to see more encouragement given to supporting people who have difficulty reading on-screen text, through for example encouraging appropriate use of multimedia alternatives if they exist or can easily be created, but we also realise that there remains much work to do in this area. Nevertheless we have lent our support to the sentiments expressed in the Formal Objection co-ordinated by Lisa Seeman and Jonathan Chetwynd.

Conformance

We feel that the way in which WCAG conformance has been addressed is excessively complex. In the UK, our legal obligations are to ensure that facilities and services are made accessible, and thus concentration should be on making tasks optimally accessible, and reporting on that success. The WCAG however deals with conformance at an artificial level - i.e. "Web unit", introducing as it does a new set of terminology that may confuse many people. We would prefer to see a more task-oriented approach to conformance, whereby lack of conformance requires a responsibility to document alternative routes to achieving task completion - this should be stated explicitly in the guidelines.

Suggestions

HTML application of WCAG

We see the most critical task as redefining the relationship between WCAG 2.0 and the WCAG 2.0 HTML Techniques. There is a need to support the most common WCAG 2.0 use case (those seeking support for HTML/XHTML development) by making it clear to developers what is and is not permitted in WCAG-conformant design. Clarification on the WCAG position on validation of HTML/CSS is also necessary, given the nature of many comments on the current draft and worries that WCAG conformance may promote increased use of invalid HTML.

NB We note strong support amongst Web developers for focus to move to amending WCAG 1.0 as a matter of urgency; and that development of WCAG 2.0 be continued longer-term in parallel with a redefinition of the role of second-generation Web Content Accessibility Guidelines in a world where there is increasing diversity in the nature and source of Web content (for example podcasts, collaborative online publishing areas, email discussion list archives, to name but a few), but where UAAG support by widely-used user agents is likely to remain disappointing. While we have indicated our support for the 'principles' approach that WCAG 2.0 has taken, we would support the WAI should it decide to refocus efforts in producing a revised WCAG 1.0 as an interim measure.

Amount of supporting documentation

There is a need to reduce the perceived amount of reading required. We assume that the errors and logical absurdities pointed out by other commentators will be addressed; however we would also like to see a reduction in the amount of new concepts that must be learned by a reader. Some examples illustrating key concepts within the guidelines would be a very useful aid in this area.

NB We note the recent appearance of the WCAG 2.0 Quick Reference - which is a major step in this area.

Conformance

To ensure a practically useful conformance system, there is a need to shift focus from 'Web units' to user tasks. Defining what can be done in a Web site, and which groups may find these tasks difficult or impossible, is we argue of more relevance that a report of an artificial entity's conformance against a set of checkpoints. WCAG conformance should be seen as a means to achieving accessible experiences, and not an end in its own right.

Baseline

Clarification of the concept is necessary so as to limit misinterpretations and potential abuses. If not already happening, there is an urgent need for WAI to work with influential agencies across the globe to ensure that appropriate and reasonable baselines are defined and published for specific sectors.

Web Standards v Web Accessibility

The balance between Web Standards and Web Accessibility is altogether more difficult to address. We realise that external developments will be difficult for WAI to control, but we strongly urge WAI to re-establish links with those involved in any rival developments so that we have harmony in the way we all seek to achieve the common goal of an optimally accessible Web.

References

1. Kelly, B., Sloan, D., Phipps, L., Petrie, H. and Hamilton, F. (2005) Forcing Standardization or Accommodating Diversity? A Framework for Applying the WCAG in the Real World. Proceedings of the 2005 International Cross-Disciplinary Workshop on Web Accessibility (W4A). http://www.ukoln.ac.uk/web-focus/papers/w4a-2005/
2. Kelly, B., Phipps, L. and Howell, C. (2005) Implementing A Holistic Approach To E-Learning Accessibility. In: Cook, J. and Whitelock, D. Exploring the frontiers of e-learning: borders, outposts and migration; ALT-C 2005 12th International Conference Research Proceedings, ALT Oxford. http://www.ukoln.ac.uk/web-focus/papers/alt-c-2005/
3. Sloan, D., Kelly, B., Heath, A., Petrie, H. Fraser, H. and Phipps, L. (2006) Contextual Web Accessibility - Maximizing the Benefit of Accessibility Guidelines. Proceedings of the 2006 International Cross-Disciplinary Workshop on Web Accessibility (W4A). http://www.ukoln.ac.uk/web-focus/papers/w4a-2006/
4. British Standards Institute (2006) Publicly Available Specification PAS 78:2006 Guide to good practice in commissioning accessible web sites. http://www.bsi-global.com/ICT/PAS78/index.xalter
5. Clark J (2006) To Hell with WCAG 2.0. A List Apart 217. http://www.alistapart.com/articles/tohellwithwcag2

Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):

Even after reading the \"Understanding...\" document, the difference between SCs 2.4.8 and 2.4.4 is very subtle and needs to be a lot clearer.
N.B. any link where the link text alone indicates its purpose will already meet SC 2.4.4.

Proposed Change:

Reword, along the lines of:
2.4.8 The purpose of each link can be programmatically determined from extra information related to the link.

Part of Item:
Comment Type: GE
Comment (including rationale for proposed change):

I have reviewed the materials at this site and find that they are accurate.

Proposed Change:

From a user\'s and pedagogical perspective, can you simplify the documents so that they are easier for people to read? My students want to design accessible websites; however, they have difficulty interpreting the material at your site.

Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):

Many proposed edits to definitions, some editorial and some substantive, at
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006Jun/att-0043/S5-glossary-EGH-05Jun2006-01.doc

Proposed Change:

authored component
an authored unit intended to be used as a part of another authored unit[What is the relationship between an authored unit and a Web unit? I really think that this needs to clarified]
authored unit
set of material created as a single body by an author[What really is this.. unrendered stuff?][I think that since claims are about web units, that authored units need to bear a clear relationship to web units… Ideally, the authored unit that is mentioned in this document would exist within a single web unit… I don’t see this going in that direction…..]
Example 1: a collection consisting of markup, a style sheet, and an image or audio clip.
Example 2: a set of [one or more than one????!!!!]Web pages intended to be viewed only as a unit or in sequence.[As opposed to what? I thought this was the definition of Web unit…..! Priority AAA. This term needs to be related to Web unit in a more precise way.]
Note: This definition is based on Glossary of Terms for Device Independence.

baseline (in this document)

[Priority a set of technologies that are used as a basis for determining conformance to WCAG 2.0. These technologies may include: markup languages (e.g., XHTML, XML, SMIL, etc.), programming languages (e.g., …), style sheets (e.g., …), data formats (e.g.,,image formats, video formats, audio formats, document formats), and APIs.

In defining the baseline, it is valuable to consider, among other things, the set of technologies that are expected to be supported by, enabled in user agents by members of the intended audience. [This is obviously not the only consideration… The original definition leans too hard on the assumption (expectation) but is not clear about whose assumption it is…..!]
[Original : “set of technologies assumed to be supported by, and enabled in, user agents� ]
Note: For more information on baselines and their use, refer to Technology Assumptions and the "baseline."

2. viewport;[Needs definition]

multimedia
audio or video synchronized with another type of media and/or with time-based interactive components[What is meant by another media type. Does video plus captions count as multimedia? Do you need to refer to primary content? What are animations? Priority AAA]

natural languages [Note from Eric. The remaining edits were made by Ruth Loew of ETS. She has a strong background in both linguistics and sign language]
languages whose rules have evolved through usage within human communities and which are used by humans to communicate, including spoken, written, and signed languages

presentation
rendering of the content and structure in a form that is intended for perception by the user[Priority AAA. As we know, whether the user can perceive is greatly affected by factors such as sensory disabilities.]

programmatically determined
determined by software from data provided in a user-agent-supported manner such that the user agents can extract and present this information to users <del>in different modalities</del>[Some user agents may present in one and only one modality. Plurality is not an essential part of the definition][I am not sure I fully understand this concept of programmatically determined]

Web unit

[New:]

a collection of information identifiable by a single Uniform Resource Identifier (such as a URL) that consists of one or more resources and that is intended to be rendered together.

• Example1: A Web page and embedded media
• Example 2: An interactive or immersive environment addressable via a single URI.

[OLD version with comments:
“a collection of information, consisting of one or more resources, intended to be rendered together[By together, this may be simultaneous, or sequentially???], and identified by a single Uniform Resource Identifier (such as a URLs[Should both be singular, right?])
[Priority AAAA. I’d like to get greater clarity on this…..]
Note: This definition is based on the definition of Web page in Web Characterization Terminology & Definitions Sheet. The concept of simultaneity was removed to allow the term to cover interactive and scripted content.
Example 1: An interactive movie-like shopping environment accessed through a single URI, where the user navigates about and activates products to have them demonstrated, and moves them to a cart to buy them.[I thought that the shopping was considered a “process�…]
Example 2: A Web page including all embedded images and media.
[The notion of web unit is key in this document. Any characterization that is not explicitly tied into the notion of web unit has no normative force…! This included authored unit, authored component, content, supplemental content, etc.!] ]

Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):

• If non-text content is multimedia; live audio-only or live video-only content; a test or exercise that must use a particular sense; or is primarily intended to create a specific sensory experience; then text alternatives at least identify the non-text content with a descriptive text label. (For multimedia, see also Guideline 1.2 Provide synchronized alternatives for multimedia .)

This seems to be a significant retreat from WCAG 1.0….

Proposed Change:

Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):

1.2.2 Audio descriptions of video, or a full multimedia text alternative including any interaction, are provided for prerecorded multimedia.

This is a significant change from WCAG 1.0 (allowing the FMTA to replace the audio descriptions.

Proposed Change:

Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):

Note: A 20 decibel difference in sound level is roughly four times (4x) quieter or louder. Background sound that meets this requirement will be approximately four times (4x) quieter than the foreground audio content.)

Is this correct???

Proposed Change:

Per the definition of decibels, background sound that meets this requirement will be approximately four times (4x) quieter than the foreground audio content.

Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):

2.2.2 Content does not blink for more than three seconds, or a method is available to stop all blinking content in the Web unit or authored component.

If the claim is about Web units, then why does this refer to “or authored component.�??? Isn’t it redundant? If not then this really needs to be clarified. Same issue in later reference “authored� stuff…

2.4.6 When a Web unit or authored component is navigated sequentially, components receive focus in an order that follows relationships and sequences in the content.

It seems to me that the term authored components does not belong in the normative part of the document unless the relationship between an authored component and a Web unit has been clearly defined in the glossary….!

Proposed Change:

Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):

4.1.1 Web units or authored components can be parsed unambiguously, and the relationships in the resulting data structure are also unambiguous.

I find this checkpoint very hard to comprehend. It seems that it should be handled by a success criterion that requires conforming to spec. But I looked at some of the background discussion. I am not sure now how to improve.


Proposed Change:

Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):

4.2.1 At least one version of the content meets all level 1 success criteria, but alternate version(s) that do not meet all level 1 success criteria may be available from the same URI.

With all the effort to define terms like Web unit, authored unit, authored component, do we really need another term "content"?

Proposed Change:

Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):

4.2.2 Content meets the following criteria even if the content uses a technology that is not in the chosen baseline:

This presumably applies to technologies even beyond those explicitly listed as being used, right.? Needs to be clarified

Proposed Change:

Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):

Complete revision of conformance section proposed at
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006Jun/att-0042/S3-conformance-EGH-05Jun2006-01.doc

Proposed Change:

Part of Item:
Comment Type: GE
Comment (including rationale for proposed change):

Guideline 1.4 is the only part of the whole document I was able to find that addresses any component of the most basic element of accessibility to any non-blind user attempting access entirely visually: legibility. Thus legibility coverage appears to be inadequate, making the entire document inadequate.

If text content cannot be read at or all without pain, it is functionally inaccessible. Nothing else matters when the content cannot be read. Other very important criteria factor heavily in determining basic legibility in addition to the guideline 1.4 coverage:

1-font size
2-font family

Reduction of font size from the user preferred size, and substitution of an author chosen font family for a user preferred font family, both cause a reduction in legibility, and thus a reduction in accessibility.

The primary message from http://www.w3.org/QA/Tips/font-size is hereby incorporated by reference, and should be a part of the guideline. Additionally, please digest http://mrmazda.no-ip.com/auth/accessibility.html for more detail and background on legibility as relates to accessibility.

Proposed Change:

Legibility is so fundamental a component of accessibility that it demands its own subpart, with the current 1.4 a component thereof. The guideline in addition to the current 1.4 should spell out:

1-Avoid font size reduction from the user preference for primary (e.g. centrally located paragraph text) content. Never size text in px or any absolute unit.
2-Minimize font size reduction from the user preference for secondary content.
3-Use utmost care, preferably avoid entirely, substituting any font family for the user\'s preferred font family for primary content. Font family substitution should be limited to branding and secondary content.
4-Only users are in position to suitably determine the font size and font family required to provide adequate legibility.
5-Not all users are empowered to compensate, either at all or to sufficient degree, when authors deviate from these guidelines. (e.g., users of computers situated in public libraries or kiosks)

Part of Item:
Comment Type: ED
Comment (including rationale for proposed change):

Re the statement, \"Following these guidelines will also make your Web content more usable to many other users, including older users.\": Older users?! Really? How old? Over 40? 50? 60? Is there proof that \"older users\" need help using the Web just because they\'re over a certain age?

Proposed Change:

Delete this sentence.

Part of Item:
Comment Type: GE
Comment (including rationale for proposed change):

My main objection to WCAG 2.0 is that it is simply too big. Brevity has been abandoned in favor of excessive, often pedantic, discussion. Developers coming to WCAG 2.0 will want immediate, accessible answers that address their problems. Instead, they must follow multiple links in order to gain information about even the simplest topics (e.g., text alternatives). It\'s often necessary to wade through lengthy explanations and rationalizations before arriving at useful information, and this information is frequently cloaked in roundabout language (\"baseline?\" \"Web unit?\") that never makes a direct point.

If the W3C releases WCAG 2.0 in anything resembling its current form-- not just the guidelines document, but the related documents as well, because WCAG 2.0 can\'t really be used without them-- it must then be prepared to defend this document from backlash by a perplexed, bewildered general public. WCAG 2.0 is longer and more labyrinthine than most other recommendations published by the W3C. What does that say about accessibility? It\'s hard to achieve? It\'s overly complex? It\'s a big pain in the neck? If the WAI wants these *voluntary* guidelines to be widely adopted, they must be re-written in a concise, direct manner.

Proposed Change:

Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):

These comments also apply to 1.4.1:

1. Is it realistic to expect authors to do the math to figure out the luminosity contrast ratio?
2. Why isn\'t MathML used to represent the equations?
3. If the only difference between 1.4.1 and 1.4.3 is the ratio (5:1 vs 10:1), then drop one ratio and therefore one needless requirement.

Proposed Change:

1. Use MathML to represent the equations.
2. Eliminate either 1.4.1 or 1.4.3, preferably the latter.
3. Reconsider the expectation that authors will determine contrast through the use of the luminosity contrast ratio. Did anyone in the working group poll authors to see if this is realistic?

Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):


Regarding baseline: I\'ve read and re-read all the documentation about baseline and I just don\'t understand it. It seems like baseline is a great way to blame the victim: an author can claim that a user\'s accessibility problems are, in fact, strictly his or her problems. The answer to any complaint is, \"That\'s not in my baseline, so I didn\'t test for it.\" The only way it might be useful is in a closed environment, such as an Intranet, where authors really do know what technologies users have. And the fact that baseline requires an entirely separate explanatory document indicates to me that it is *far* too complex to be useful.

Regarding scoping: \"Scoping\" of a conformance claim introduces a perfect loophole for anyone who simply doesn\'t want to do the work required to make things accessible. Take Example 2: \"A site has a collection of videos for which it is not required to and does not want to claim accessibility.\" \"Not required?\" But aren\'t captions required by SC 1.2? Is \"I don\'t want to\" now a valid excuse? Further, Example 2 states that a scoped conformance claim of \"I don\'t want to caption/describe the videos\" is valid as long as the videos are played only in a standalone player. But if the videos are embedded in a Web page, suddenly they *must* be made accessible...? I don\'t see the distinction. Video is video. If I\'ve created an on-line physics curriculum that uses a standalone player to show an entire semester of lectures, you\'re saying that these videos do *not* have to be accessible if I \"scope\" my conformance claim to exclude these materials?


Proposed Change:


1. Delete baseline.
2. Delete scoping.

Content negotiation: In Conformance it says "Note: If multiple representations can be retrieved from a URI through content negotiation, then the conformance claim would be for the Web unit that is returned when no negotiation is conducted (unless the server returns an error for that condition, in which case one of the negotiated forms must comply)". Does the WG mean that if there is content negotiation, that only one version of the content need be accessible? What about if one version of content provides more information than the accessible version? That would be a violation of WCAG1 and should be a violation of WCAG2

Proposed Change:

Firstly it should be required that all content from different representations is available from the accessible version. Secondly, at Level 3 it should be required that all versions of content should be accessible.

Definition: "For all non-text content one of the following is true…if non-text content is pure decoration, or used only for visual formatting, or if it is not presented to users, it is implemented such that it can be ignored by assistive technology". What is the definition of assistive technology? If one assistive technology behaves one way and another assistive technology another, then how should this SC be followed?

Proposed Change:

Redefine this SC

2.2.1 & 2.2.3: As previously discussed, further details should be provided when timeouts is an important part of a real-time event or an activity when timing is essential.

Proposed Change:

I am happy to write an additional set of criteria (with Loretta)

2.2.2: Why is blinking allowed for three seconds?

Proposed Change:

Explain the meaning behind this SC

2.2.5: This should be L1 or there should be a L1 equivalent.

Proposed Change:

For example, it should not be possible to update a page every ten seconds under L1 otherwise people using screen readers won't be able to access all the content before the page refreshes.

2.4.4: Image maps (and images that are also links) are not mentioned and it could be interpreted that they are outlawed by this SC

Proposed Change:

Include image maps and image links (with appropriate ALT attributes) in the examples

Relative vs absolute units: There should be a WCAG2 equivalent at Level 1 for this WCAG1 checkpoint. The ability to change the text size in a page is very important to people with vision impairments. The ability to resize tables according to the size of the screen is very important to people using PDAs

Proposed Change:

Create a new SC outlawing absolute units (I am happy to write this)

the def. of level 1/2/3 is vague: what does “a minimum�, “enhanced�, “additional� mean? are you asserting that accessibility is a property that can be totally ordered over a ordered scale, as these adjectives are suggesting?

Proposed Change:

try to refer to defineable and measurable parameters; or, more reaslistically, say that this is an assumption that you may describe in details when presenting each success level.

and what do “can be reasonably� and “cannot necessarily be applied� mean?

Proposed Change:

again, this should be clearly stated as an assumption, when presenting each single criterion. From these “non definitions� readers would get that there is an increase of required effort (as conformance levels increases), an increase in accessibility (whatever that means), but would not be given any means for understanding which will the benefits that visitors of the website will get. And if these benefits are worth the cost (of “non reasonably� applying certain techniques).

in particular the only difference between L1 and L2 is that one is “minimum� accessibility and the other is “enhanced�. Why distinguishing them? if both sets of techniques can be equally easily applied, why should one want to go for the minimum?

Proposed Change:

provide a definition of these levels that refer to benefits that can make sense to people managing a website, so that they can take informed decisions as to whether to achieve a higher level or not.

the sentence “all wcag20 statements are testable� is a bit strong! Only a formally defined language can express sentences that can be formally, and therefore objectively, verified. And actually not even that.

The repeatability of assessments that you mention is one hypothesis; you should clearly say this; or otherwise provide evidence to support this (relatively important but demanding) claim.

Proposed Change:

I'd suggest to make it weaker, by saying that it is your assumption (and hope) that they are testable by somebody having a certain level of experience in .... and (perhaps) when following a certain procedure. No studies have been performed (yet) in order to determine is such a property is true.

the def of user agents include assistive tech, and that is clear. But what do you mean with “... as long as accessible user agents support the technology�? that a website useing a tech. not supported by any accessible user agent could never be claimed to be wcag20 conformant? also the clause “...user agents including AT� is confusing. If AT is already a user agent (or part of it), then the clause is not needed. But if you want to say that the technology should be supported by at least an accessible user agent that is compatible with at least one AT, you should say it clearly.

if content is “info communicated to user� then it does not include code and markup. IMO a person senses, perceives, understands signals sent over some medium by a physical device, and decides, plans an action, and acts physically on some device. Information can only be “sent� or “received� in this way (up to now). Code and markup is being sent to the user agent, which contributes to trasforming them into signals. But code is never information, as long as a web user is involved.

i don't think that's a proper and useful definition; arithmetic theory is a collection of facts and inferential rules; but I wouldn't say that saying “1+1 equals 2� is providing information.

Proposed Change:

at least refer to what others said about it; eg Bateson defined information as “the difference that makes a difference�

the problem is that in the conformance statement one needs to refer to a baseline, but wcag20 does not prescribe how a baseline is defined and what kind of mechanisms it should include. Could a conformance statement be referring to a baseline defined solely as “netscape 4 on windows 95�? would this be a valid conformance claim?

it is not that the content can be parsed unambiguosly or not. That is a property of the language, not of the processor of the language. If the language is ambiguous then a parser could take arbitrary decisions in interpreting the sentences. Like Italian. HTML, not even 2.0, was never ambiguous. And if user agents were strict since the beginning, web authors would have never been allowed to write incorrect html.

Proposed Change:

what 411 should say is that authors should write syntactically correct code, which is what the techniques say.

values that can be set by users should also be settable by a program? which values?

... all user interface components...: you mean that each single DOM element that has perceivable effects on some user needs to have name and roles defined? eg every <p>?

for example the word “weekend� is commonly used by Italians, and usually pronounced similarly to English. However the success criteria do not prescribe that it is correctly marked up (apparently).

what is a primary resource?

the criterion is ambiguous/or even empty: one could always be conformant to this by saying that the set of web resources consists merely of the webunits that share the same order. So if on my website I put the same 5 links in different orders within the pages, they are still ok with 323, because each web page makes its own set of webunits.

and how about systems that adapt their gui to the behavior of the specif user or of a group of similar users? (for example because the user agent sends an ID to the server that identifies the user as a blind person?) are these non conformant websites?

“content that changes the meaning of a web unit�? but a web unit is defined as “a collection of information ...� and content as “information to be communicated� how can a content change the meaning of other content? It surely can (eg adding a “not� in front of a sentence might change its meaning). Is this what 321 wants to prevent?

to me the distinction between L1 L2 L3 is arbitrary. violation of any of them is likely to hinder some user, and they seem to me equally difficult or easy to achieve

“entered� and “exit� should be defined in terms of focus changes

a “small class of input�? any gesture (which is by nature time-dependent) that requires a mouse by definition cannot be done with a keyboard. Similarly for a pointing pen (like signing on a screen). or using a joystick to fly a virtual airplane. I think that as long as the user clicks with the mouse then that can be reasonably easy and similarly be implemented with keyboard interaction. Clicks and movements (like in drag and drop) somewhat less easily and similarly.

you say “unless the task requires analog time dep. input�. But the task is defined by the designer and is supported by the GUI. By definition, if the task requires some mouse based input that is analog time dependent, then the page succeeds 211.

Proposed Change:

I think you should focus on the concept of “goal� rather than task. A goal is a desired state of things that a user wants to achieve, and tasks are the observable actions to achieve the goal. Thus you might want to say that the goal should be achievable through 1 or more tasks that do not require analog time dependent gestures. Except when for that goal there is no other way (like piloting a plane!).

The note in section "Conformance notes" states conformance for the case of content negotiation. The requirement that only the page returned with no content negotiation needs to comply with WCAG 2.0 is too weak, with regard to content negotiation for alternate language delivery. A page should comply for all of its language versions.

As an example, consider a website where only the English version (default for content negotiation on language) is accessible according to WCAG 2.0. The website could claim conformance although all non-English users would get inaccessible web pages through their user agents.

Proposed Change:

Add to the note: "Exception: This note does not apply for alternative language versions being delivered through content negotiation. A Web unit conforms to WCAG 2.0 only if all its language versions conform."

These success criteria would make a web page with multiple language versions compliant, with only one version being conformant and the others being inaccessible. We need to exempt alternative language versions from this success criterion. This should be mentioned and the definition of "alternate version(s)" should be amended correspondingly.

Essence: An accessible page in Korean is not an equivalent alternative for an inaccessable page in Urdu.

Proposed Change:

Add to 4.2.1 and 4.2.3: "This does not apply to alternate versions serving different languages."

Also, change the definition of "alternate version(s)" to exclude versions serving different languages, e.g.: "version that provides all of the same information and functionality in the same natural language and is as up to date as any non-conformant content".

Item Number: (none selected)
Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):
There doesn't seem to be a place to comment on the Baseline Document, so I'll post it here:

http://www.w3.org/WAI/WCAG20/baseline/

The potential for many baselines is possible, and each baseline will have an overall level of accessibility associated with it. For example, a baseline that includes only HTML 4, is going to be more universally accessible than a baseline that includes HTML 4, Flash, Java, and Javascript. For clients or developers using the latter baseline, we would essentially tell them that if their content made full use of the Flash, Java, and Javascript accessibility features, they can comply at Level 2 (hypothetically speaking). But, for a client who creates the same site that uses the first baseline (HTML 4 only), and has gone to the trouble of creating alternatives for their Flash, Java, and Javascript content, will have created a more accessible site than the site that uses second baseline and does not have any alternative formats. What motivation would there be for the developer of the site using the first baseline, if they can just place all the technologies in the baseline, and forget about creating more accessible alternative content.

Proposed Change:

The solution to this may be associating some base accessibility value with a variety of standard baselines, baselines which remain non-normative, and evolve as technologies evolve.

Item Number: Technology assumptions and the
Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):

There is a relatively easy possibility of Level AAA compliance by virtue of ommision. By default, the vast majority of sites will meet 50% of the level 3 guidelines without trying. The following are arguably not relevant on most Web sites.

---------------------

Irrelevant for most sites

1.2.5 (w/ no MM)
1.2.6 (w/ no MM)
1.2.7 (w/ no MM)
1.4.3 (use standard B/W)
1.4.4 (with no audio content)
2.1.2 (with no time dependence)
2.2.4 (no timed events)
2.2.5 (no auto updated content)
2.2.6 (no timeout)
2.3.2 (use no flashing components)
2.4.6 (don\'t use tab to create inconsitent tab ordering
3.1.6 (write in an alphabetic language)
3.2.5 (use no auto redirects)
4.2.4 (use only baseline technologies)

---------------------------

Potentially 13 L3 met by omission

So without any extra effort, a site without any of the above technologies would meet enough level 3 criteria to comply, even though none of the guidelines are relevant.

Things that could be done relevant to the content of the majority of sites

Relevant to most sites

2.4.5 (use descriptive titles, headings, and labels)
2.4.7 (use breadcrumb links to navigate, and identify location within a hierarchy)
2.4.8 (use meaningfult link text)
2.5.4 (describe expected input for form fields)
3.1.3 (provide a glossary)
3.1.4 (expand all abbreviations)
3.1.5 (Use low level language)

---------------------------

Potentially 7 L3 relevant to most sites.

Proposed Change:

Perhspa 75% of level 3 items would be more appropriate, or maybe 50%, which includes at least 4 or 5 items (or maybe all) from the second list of more common level 3 items.

Item Number: Conformance claims
Part of Item:
Comment Type: GE
Comment (Including rationale for any proposed change):

Re: Conformance notes.

http://www.w3.org/TR/2006/WD-WCAG20-20060427/conformance.html#conformance-claims

The Note suggests that the default version of the content displayed (i.e. Web unit that is returned when no negotiation is conducted) is the one that must comply. This would mean that myself for example, as a fully able user with no content negotiation enabled, would be forced to view the most accessible version of a content unit, despite, perhaps, a less accessible, more interactive, "flashy" version being more appropropriate for my needs.

Proposed Change:

I think the second statement (in parentheses) "...one of the negotiated forms must comply" makes more sense as the default here, with perhaps the added note that "...the most accessible version is easily accessed should the primary version not be accessible". A common example is the Flash splash page that includes a link to an accessible HTML version of the same content. In the initial statement it suggested that as a developer I would have to default to the HTML version of the page, with a link to the Flash version instead. Developers and their clients will not agree to this, but they will agree to a link that leads to a more accessible version..

Item Number: Success Criterion 4.1.1
Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):

In guideline 4.1.1 does "parsed unambiguosly" mean "well formed" or "valid"? The techniques seem to suggest that markup must be valid, though you would be hard pressed to find invalid code that disrupts any relatively recent screen reader's ability to read a Web unit. It takes severely broken markup to affect accessibility, or specific types of errors (such as broken table structures). While I am all for valid markup, it is *not* a requirement for accessibility in most cases, particularly at level 1. I can see this requirement at level 2 perhaps.

Proposed Change:

What would be appropriate here to have a well formed requirement at level 1, and valid at level 2. And still this really has to do with compatibility with future technologies, rather than affects on accessibility using current technologies.

Item Number: Success Criterion 4.2.1
Part of Item:
Comment Type: ED
Comment (Including rationale for any proposed change):

Guideline 4.2.1

This guideline does not read like a guideline (same with 4.2.3), is not immediately clear what it means without reviewing the HowTo, and can be interpreted in different ways (i.e. ...may [also] be, or ...may [instead] be...). I interpret it first as meaning I can include a link from the accessible version to the innaccessible version. In fact it should be the opposite that is true (and I'm sure based on the howto that is what was intended), including a link from the innaccessible version to the accessible one.

Proposed Change:

Ideally there should be reciprocol links between the two versions.

"The Conformance section and SC 4.2 clearly contradict each other. The section on Conformance currently reads ""WCAG 2.0 conformance at level A means that all Level 1 success criteria in the guidelines are met assuming user agent support for only the technologies in the specified baseline."" By contrast, 4.2.1 and 4.2.3 say ""At least one version of the content meets all level N success criteria, but alternative version(s) that do not meet all level N success criteria may be available from the same URI.""

Take for example a URI that has two versions of the same content, one not meeting SC 1.1.1 and the other an accessible alternative that does meet 1.1.1. Can that URI conform at Single-A? Under the current wording of the Conformance section, the answer is clearly NO! That page complies with 4.2.1 (by providing an accessible alternative), but it still fails 1.1.1: the rules stated in the Conformance section provide no exemption from 1.1.1 just because something passes 4.2.1, nor does 1.1.1 itself define any such exemption.

If conforming with 4.2.1 is meant to provide exemptions from most other Level 1 criteria, the document MUST say that in the normative Conformance section or in the description of each success criterion.

You might say that the intent is understood, but the question is, is the intent supported or contradicted by the actual wording of the normative sections of the document?"

Proposed Change:

"Change Conformance to explicitly say that conformance requires that each URI conforms with all SC of the appropriate level OR that an accessible alternative that does so is available from the same URI (with a link to the details of what that means, currently in the Understanding document's discussion of Guideline 4.2).

OR, change the section ""Conformance Levels and the Baseline"" to say that only conformance with criterion 4.2.1 is required to claim Single-A conformance, and leave it to 4.2.1 to require all the rest of the Level 1 criteria."

This is closely related to the previous comment on Conformance, and a follow-up to existing issue 1590.

I was unable to spot where, in the Conformance section or elsewhere, it is made explicit whether success criteria need to be met all the time, or by default, or only on request. For example, 1.4.1 says ""Text or diagrams, and their backgrounds, have a luminosity contrast ratio of at least 5:1""; is it acceptable if that is a user-selectable option, and if so, does it have to be on by default? The closest I can find to addressing this is Guideline 4.2, ""Ensure that content is accessible or provide an accessible alternative,"" under which SC 4.2.1 (for example) says ""At least one version of the content meets all level 1 success criteria, but alternate version(s) that do not meet all level 1 success criteria may be available from the same URI."" This can be taken as making it clear that all success criteria can be met at the user's request, and do not need to be met in the default configuration. However, it seems strange to have success criteria in one guideline (4.2) effectively define exceptions to every other success criteria in the document, essentially saying ""You know that thing we said you have to do? Well, you don't have to do it under certain circumstances."" As a result, 4.2.x are the only success criteria that are actually required; the rest are all conditionally required, although you won't find this out unless you read 4.2.

The example conformance claims are invalid because they omit the full name and URI of the guidelines, which are required according to the section "Required components of a conformance claim".

Proposed Change:

Replace "W3C's WCAG 2.0" with "Web Content Accessibility Guidelines 2.0 at http://www.w3.org/TR/2006/REC-WCAG20-YYYYMMDD/"

One required component of a conformance claim is "Scope of the claim (a URI, list of URI's, or a set of URIs defined by a regular expression)," and the examples each include a single URI. This, the Examples, and the Conformance Notes all fail to clarify whether citing a single URI implies conformance is claimed for that one web page (or equivalent), or all pages referenced by it, or all pages "beneath it" on the server. For example, does claiming conformance for http://telcor.example.com/nav/G7/intro.html mean that conformance is claimed just for that one page, or for all the pages it links to, or all the pages in the /nav/G7/ directory on the server, including or not including subdirectories? I suggest clarifying this and also including an example of a claim for an entire Web site or multi-page portion thereof.

The example conformance claims list things like jpeg as 'specifications that this content "relies upon"'. How can jpeg ever be a relied upon specification since the guidelines require Web pages to be usable even when the images are turned off?

Proposed Change:

Remove JPEG from list of "specifications that this content relies upon", or else clarify what is meant by including it.

In the phrase "different forms are provided to accommodate multiple disabilities", the word "multiple" could be read as saying these forms should address the needs of an individual with multiple disabilities, which is a nice goal but not the baseline requirement.

Proposed Change:

Change "different forms are provided to accommodate multiple disabilities" to "different forms are provided to accommodate different disabilities".

The order of the two clauses is reversed from all the other success criteria for guideline 1.2.

Proposed Change:

Change
"For prerecorded multimedia, a full multimedia text alternative including any interaction is provided" to read
"A full multimedia text alternative including any interaction is provided for all prerecorded multimedia."

The phrase "visually evident without color" could be misinterpreted as meaning "visually evident, and without color". Suggest rephrasing to be less ambiguous.

Proposed Change:

Change "visually evident without color" to read "visually evident even if any color cannot be perceived".

The guideline reads, "Any information that is conveyed by color is also visually evident without color." This wording clearly implies that it is acceptable to convey information by contrast, a technique that is discussed in other criteria but overlooked both here and its Understanding. Is the intent here to make sure information is visually evident without perceiving color and contrast, or to say that conveying information by contrast alone is acceptable? I suspect the former. If the latter, we should provide guidance for 1.3.2 on minimum acceptable contrast between items when color/contrast is used alone to denote differences in type, state, etc., just as we do for differences between foreground and background elsewhere. Even if the former, such guidance on the use of contrast would be valuable as a Level 2 or Level 3 criterion.

Proposed Change:

Change to read "Any information that is conveyed by color or contrast is visually evident even if any color and contrast cannot be perceived.."

The wording "When the sequence of the content affects its meaning, that sequence can be programmatically determined" is ambiguous as to whether it refers to intended viewing/reading order, keyboard navigation order, presentation order (e.g. navigation links are at the top despite the designer's intention that they not be actually read on every page), and/or declaration order (e.g. content is declared early in the HTML despite being positioned at the bottom of the page using vertical alignment attributes). The Understanding section only addresses conveying intended reading order, but if that is the intention, the wording of the Success Criterion should reflect that. However, other ordering may be important to some types of assistive technology (e.g. keyboard navigation order for use by speech recognition software).

1.3.5 says information required to operate the content should not rely on visual location or orientation of components, but in HTML forms the association between a control (e.g. radio button) and its visual label (e.g. static text nex to it) are only exposed programmatically through the DOM and visually by the spatial relationship between the two objects. The only way to avoid relying on spatial cues is to use assistive technology; is that the intention of this criterion, even though the word "programmatically" does not appear in the wording and the Understanding and Techniques don't explicitly mention steps to assist assistive technology?

1.4.1 specifies a minimum luminosity contrast between text or diagrams and their backgrounds. Often diagrams include portions that convey information and other portions that are purely decorative; in such cases, shouldn't this criterion apply only to portions of the text or diagram that are functional or convey information? Large text used as a decorative element behind the text of a Web page is an example of purely decorative text, and in such cases you really need to retain low contrast with the background.

Proposed Change:

Change to read "Portions of text or diagrams that are not purely decorative have a luminosity contrast ratio of at least 5:1 when compared with their backgrounds."

1.4.4 Note uses the phrase "four times (4x) quieter", but that seem a meaningless term. One can only talk about something being "four times louder" because loudness is measured relative to the absence of audible sound. "Four times quieter" would only make sense if noise A is compared with some other, even louder sound.

Proposed Change:

Change to read "Background sound that meets this requirement will be approximately one quarter as loud as the foreground audio content."

2.1.1 requires all functionality of the content to be operable in a non-time-dependent manner through a keyboard interface. However, many Web sessions eventually time out, and there is no practical way to design the server software to avoid this. Even when the Web content complies with criterion 2.2.1 and 2.2.6, which in many cases requires the user have some control over such time-outs, that does not make it comply with 2.1.1.

Proposed Change:

Define "non-time-dependent manner" as "method that does not require user action within any period shorter than ten minutes", or else add a Note to 2.1.1 explaining that server-based session time-outs of at least some minimum duration are not considered part of the content.

2.2.1 applies to each time-out "that is a function of the content". Does that include time-outs that are applied by the server software, and of which the Web unit may have no knowledge (e.g. session timing out from inactivity)? Clarification is needed. The Understanding document addresses this but fails to clarify it, but it looks like server-based session time-outs would be non-conforming.

Proposed Change:

"Remove the phrase ""that is a function of the content"".

Add clarification of server-based session time-outs to the Understanding document or the SC itself."

2.2.2 requires content to not blink for more than three seconds or a method be available to stop all blinking in the Web unit or authored component. Many Web sites display GIF images that are provided by a third-party (e.g. advertisements, or user-contributed photos); are such sites required to ensure that none of those are animated GIFs, in case some blink? Is it sufficient for the authors to define a baseline that includes user agents that allow the user to stop blinking on the current Web unit (e.g. pressing ESC)?

2.5.3 option 3 is that the user is able to review and confirm or correct information before submitting it. However, in almost all cases the user can pause after entering data, and review it before pressing ENTER or clicking SUBMIT, etc. I believe the intent of this option is that pressing ENTER or clicking SUBMIT should bring up a new Web unit that displays how the system interpreted what the user wrote (as opposed to what they thought they were writing). If so, shouldn't the wording make this clearer?

Proposed Change:

Change to read "The user is able to have the information they entered re-presented to them so they may review and confirm or correct it before final submission."

2.5 3 requires, for Double-A, that methods are provided to help avoid or undo errors, but only for a certain narrowly-defined set of interactions. I would recommend that these steps, or at least UNDO, be repeated as a level 3 success criterion, but applying to all interactions rather that just those listed in 2.5.3.

Proposed Change:

Add a new Level 3 success criteria:
2.5.5 For all user actions, at least one of the following is true:
1. Actions are reversible.
2. Actions are checked for input errors before going on to the next step in the process.
3. The user is able to have the information they entered re-presented to them so they may review and confirm or correct it before final submission.

4.2.2. says that if the user can enter content using the keyboard they must also be able to exit it using the keyboard, even if the content uses a non-baseline technology. This helps, but is not a complete solution, because it does not require that the keyboard method be discoverable by the user, especially if the user has a disability (e.g. a screen that cannot be read by a screen reader displays "text" telling the user they can exit by pressing F10, but the user who relies on the screen reader has know way of figuring that out). This is addressed in Techniques, but I fear that is inadequate because such documentation is so critical.

Proposed Change:

Change "If content can be entered using the keyboard, then the content can be exited using the keyboard." to read: "If content can be entered using the keyboard, then the content can be exited using the keyboard, and the method for doing so is described using technology in the baseline."

Definitions of GENEAL FLASH THRESHOLD and RED FLASH THRESHOLD, it might be worth noting, will eventually need to be revised when OLED technology allows for increasing use of very large, animated displays. Picture one big OLED display replacing the sign board in the lobby of a major office building, listing all the businesses and their locations; in this case the user will be focusing their attention on one small area of the large sign, but close enough to read the text easily. In that case, the entire area the user is looking at might be flashing, but it still would not be 1/3 of the screen high and 1/3 of the screen wide.)

Proposed Change:

In both GENERAL FLASH THRESHOLD and RED FLASH THRESHOLD, append to list item 1, "or designed to occupy a region larger than 6" by 6" on the intended physical display".

Comment: Where it states "The broader term was chosen because it covers Web applications and other types of content to which the word "page" may not apply" it gives no example of a "web unit" that is not a "web page".

Proposed Change:

Provide an example of a "web unit" that is not a web page.

Comment: The text "The WCAG Working Group believes that all success criteria of WCAG 2.0 are essential for some people. Thus, the system of checkpoints and priorities used in WCAG 1.0 has been replaced by success criteria under Levels 1, 2, and 3 as described above" is not very clear, it is still difficult to understand the rationale behind the move from WCAG 1 and Priorities to WCAG 2 and "Levels".

Proposed Change:

Expand and explain the rationale