Disposition of comments for the Accessibility Guidelines Working Group

Advisory techniques: There should not be any advisory techniques unless they are linked to a particular SC. Having advisory techniques linked to a GL only, means that the level (A, AA or AAA) is not specified.

Proposed Change:

Move all GL advisory techniques to specific SC

Transcripts: Why isn't this at Level 1? Shouldn't the equivalent information be provided at Level 1?

Proposed Change:

Move to Level 1

Seizures: This is a Level 3 SC yet the Intent specifies that it is intended not to cause seizures.

Proposed Change:

Clarify the SC. If it is intended not to cause seizures it should be at Level 1.

Frames: 2.4.1 is a Level 1 SC. I don't believe we should be advocating frames at the minimum level (see Techniques section). There are better ways to group blocks of repeated content

Proposed Change:

Remove the frame technique

Supplemental text: I completely disagree with supplementing link text with hidden text via CSS. If more information is required in order to understand the link, then it should be available to everyone, not just people who use screen readers

Proposed Change:

Remove this Technique

Home link: why is the technique to add a home link an additional technique?

Proposed Change:

Change the additional technique to a mandatory technique

Script: The techniques and examples are very script heavy. It appears, to a casual reader, that the W3C is advocating scripting above other technologies, such as PDF, XHTML or CSS.

Proposed Change:

Ensure that techniques and examples are evenly spread over a variety of technologies

There are examples in the Intent section

Proposed Change:

All examples should be in the Examples or Failures section

Example 6: Add another alt text example "Shaking a world leader's hand can subtly affect the distribution of power in the relationship" and "Shaking hands is a purely Western artifice"

Click here: Please clarify whether or not this SC allows for link text such as "Click here" and "more". If so this SC should be rewritten to outlaw this ext

Proposed Change:

Clarify or rewrite SC

Situation A - If an application causes a legal transaction…: what is a "period of time"? Is this going to be quantified? Should we be doing that?

Proposed Change:

Clarify the Technique

Needs more examples

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

For each guideline & success criteria, provide a couple of word summary, rather than just a number. Sometimes referred to as \"shortname\".



Proposed Change:

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

In the current framework, while there are success criteria there are no
normative explanations of how they apply to given technologies. Instead,
understanding WCAG 2.0 has been made an informative document.

This is inappropriate to ensure interoperability of tools and content.
This has been a major problem with the implementation of WCAG 1.0, where
important questions of interpretation (such as "are tables OK for
layout?", "do all user agents identify form fields without default text in
them?", "is it OK to rely on javascript?", "are px units OK for layout?"
among others) have gone unanswered for many years leading to a major
breakdown in interoperability between tools, services, and content itself.

I propose that the information be made available in a normative document.
The process requirements for publishing such a document would seem to be
very lightweight in the context of how long it takes the WCAG group to
determine necessary changes, and this will at least ensure that an
authorative answer becomes available for issues which arise.

cheers

Chaals

Example 2: As previously discussed, people who use screen readers (people with vision impairments and people with dyslexia) expect that the order of the site with CSS on matches the order of the site with CSS off

Proposed Change:

Change this example so that the order of the content is the same with CSS on or off

Limiting the number of links per page: Firstly this should be an advisory technique under a specific SC, not under the entire GL (otherwise how do we know what level it is aimed at?). Secondly, why is this a technique? A portal site or a news site etc would have difficulty complying and I believe the number of links on a page is entirely dependent on the content. It will be diffiicult to define a "limit"

Proposed Change:

Remove this advisory technique

Examples: The two examples should be moved to Advisory Techniques

Is this SC about providing corrections to field errors or highlighting field errors. The techniques and examples seem contradictory

Proposed Change:

Clarify the techniques and examples

Comment:

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

Time limits

In circumstances where a sign-language interpreter may be relating audio content to a user who is deaf, control over time limits is also important.

Then that isn't an issue of Web content anymore. Hiring a human aide to make a site accessible to you is no longer our problem.

Comment (including rationale for any proposed change):

The technical notes are not wrong, but misleading. One can get the impression that sign language videos are only necessary if there are captions in videos. This does not meet the reality.

Proposed Change:

Please delete this notes.

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

Web safe colors, web friendly colours
The access Working group GOC has recently made a requirement for web friendly colours.
They believe that some versions of magnifiers (older) only handle web safe or web friendly colours and then they dither non friendly colours. They believe that the dithering process will affect contrast. For instance, a light background that is not safe might get dithered darker, and a dark foreground might be dithered lighter. And the combination could cause lower overall contrast in older user agents.


Proposed Change:

Discuss why or why not web safe/friendly is an issue.

Add something like:

Note: some older user agents are limited to web friendly, web safe colours. If older user agents in your baseline, use web friendly/safe colours.

Example - A questionnaire with a timeout: In this example, there are several recommendations that certainly would make the questionnaire more accessible (alert popups, information on timeout etc) but these do not actually relate to this (or any) SC. These are excellent requirements - they should be developed into SC

Proposed Change:

Create new SC (I am happy to help with this)

Comment:

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

Endorsement of "non-W3C technologies"

A deficiency of WCAG 1 was its chauvinism toward anything not invented by the W3C. They pretty much didn't want you to use any "non-W3C technologies"; there's a whole [3] guideline telling you not to. WCAG 2 tries to be technology-neutral. In so doing, it authorizes the use of "HTML" that was never ratified by a specification, notably embed.

While this is the only reliable method to include multimedia on a Web page (still, in 2006), is univerally understood by graphical browsers, and can easily be made legal via a custom DTD, it still isn't real HTML. I find its inclusion curious given WAI's ideology of yore. (Elsewhere, the Understanding document lists the blink element as a failure method. That isn't real HTML either, thankfully.)

3. http://www.w3.org/TR/WAI-WEBCONTENT/#gl-use-w3c

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

A few other pointers that should be included.

-Don\'t use the same term/word/sentince to symbolize a link if they go different places
-show links have been visited
-don\'t recommend to repeat the same text over and over hard on screen readers.

Proposed Change:

Add the aditional pointers.

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

Should consider adding the following reference in the related resources area.
http://www.w3.org/TR/turingtest/

Proposed Change:

Should consider adding the following reference in the related resources area.
http://www.w3.org/TR/turingtest/

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

May want to add advisory technique to skip over non-baseline content.

Proposed Change:

Add the optional/advisory techniques to skip over non-baseline content.

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

It is not clear from the success criteria that greyed-out inactive element would pass 1.3.2.

Proposed Change:

Add simple example that grey-out inactive elements are visually distinguishable from normal active elements.

The Dynamic Web Accessibility Adaptable States and Properties module includes a describedby property which provides help text to describe the object. This maps to platform accessibility APIs as well.

Proposed Change:

Add an XHTML technique that demonstrates using Dynamic Web Content Accessibility "describedby" property.

Users who are filling out forms need a mechanism to indicate whether form elements are required. This is addressed in XForms and Dynamic Web Accessibility by indicating if a form field is required or invalid. If the user does not know a field is required form submissions will fail and the user must repeat the process.

Proposed Change:

Add an XHTML technique to How to meet 1.3.1 that demonstrates using Dynamic Web Content Accessibility attribute of required=""true"".

Such a technique could also be useful in meeting GL 2.5 but there is no success criteria to relate it to. It could be an advisory technique under ""Understanding guideline 2.5"" or listed as a related technique under the GL 2.5 success criteria.

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

The following Examples are currently associated with 1.3.2:

Situation A: If the color of particular words is used to indicate information.
Ensuring that color encoded information is also available in text.
Including a text cue whenever color cues are used

The above are too broad for 1.3.2 and should be associated only with 1.3.4.



Proposed Change:

Move the above to 1.3.4.

Add example of using colored text that is also bold and italic as a way to satisfy 1.3.2.

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

I have been working on a Dutch translation of the guidelines and noticed that \"legal transactions\" is hard to translate into Dutch in a way that rings a bell with readers; I translated it as if it meant \"transactions recognized by the law\".
Other translators may also have this problem because \"legal transactions\" in the SC text is not clarified in the intent of HtM 2.5.3. If it means \"transactions where the person incurs a legally binding obligation or benefit (a marriage license, a stock trade (financial and legal), a will, a loan, adoption, signing up for the army, a contract of any type, etc), please clarify this.

Proposed Change:

Add the following to the intent of HtM 2.5.3: \"Legal transactions are transactions where someone incurs a legally binding obligation or benefit, for example a marriage license, a stock trade (financial and legal), a will, a loan, adoption, signing up for the army, a contract of any type, etcetera.\"

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

Please clarify how one would determine the reading ability required by a multilingual Web unit or page, for example an English text with long quotes in French.

Proposed Change:

One could consider the following approach: for each language that constitutes at least 5% of the content and that is used in full sentences or paragraphs (not just individual words or phrases), determine the reading ability required by the content in that language. Compare the scores for each language and use the \"worst\" score as the readability score for the whole Web unit or page.

Add failure: Add a failure where a long description is not descriptive enough

Proposed Change:

I am happy to create this failure

Example 3: Why isn't a long description required?

Proposed Change:

Add to example that a long description is required which gives the same information as the image

SCOPE: One of the HTML techniques is to usee the scope attribute to associate header cells and data cells in tables. Research has shown that SCOPE is not supported by any known assistive technology and therefore should not be advocated.

Proposed Change:

Remove the SCOPE HTML technique, OR indicate that it is not supported yet, and TH & TD are preferable

Example 1 - "A form that uses colour and an asterisk…": Research has shown that screen readers differ in their approach to asterisks - some do not read them out at all.

Proposed Change:

Remove this example, and provide additional examples, such as using the word "required" instead of an asterisk (I am happy to write these)

Add failure: Add a failure where the default underline is removed from linked text - therefore links are only differentiated from normal text through colour alone

Proposed Change:

I am happy to create this failure

Needs examples: This SC needs examples in order to fully understand the implications

Proposed Change:

I am happy to create some examples (eg. See the use of dots - and equivalents - at: http://www.melbourne2006.com.au/Schedule+and+Results/

Intent: Add to the intent that people with Parkinson's disease find using a mouse very difficult and therefore usually use a keyboard

Situation A: In this situation clarify whether scripts are part of baseline or not

Example B: automatic updates are not timeouts.

Proposed Change:

Remove this example from this SC

Example - A stock ticker: In this example it specifies that stocks updated during the pause will not be shown. This sounds like showing the stocks updated during the pause is outlawed.

Proposed Change:

Change the text to "Stocks updated during the pause may or may not be displayed, depending on the interface."

Example - A stock ticker: Doesn't this example violate 1.1.1? If someone stops the stock ticker and therefore misses out on some information shouldn't that information be provided elsewhere?

Proposed Change:

Clarify example

Techniques: Add a technique to turn the flash off before it begins

Examples: The example in SC 2.3.1 (Level 1) specifies two lightning flashes, whereas the example in SC 2.3.3 (Level 3) specifies three lightning flashes. A level 3 SC should have less flash than a Level 1 SC

Proposed Change:

Rewrite the examples or the SC

Examples: The information provided in the Examples should be in the Techniques section (eg. Setting the id3 property of an mp3)

Proposed Change:

Rewrite Techniques &/or Examples

JPG: Are we requiring that all JPG images have EXIF data? If not this example should be removed or moved to advisory.

Proposed Change:

Remove JPG example

TITLE attribute: Recent research has discovered that screen readers differ in how they read the TITLE attribute and some assistive technologies, such as magnifiers usually can't access the information at all.

Proposed Change:

Remove the TITLE attribute technique or specify that it is not supported on a variety of assistive technology

Situation A - If a mandatory field contains no information: also add "and provides an example of a correct answer"

Proposed Change:

For example, incorrectly filled out fields have a message that says "This field has been filled out incorrectly. Please enter your age, for example "18" "

Situation B - If an action causes information to be deleted… Providing a message to the user asking him or her to confirm…: I disagree that this should be a valid technique. There should be further ability to recover deleted information

Proposed Change:

Remove this Technique

Situation B - If an action causes information to be deleted… Requiring a user to select a checkbox…: This technique doesn't make sense

Proposed Change:

Rewrite the technique

RUBY element: Is the RUBY element supported by any user agents? If not this should be deleted or lack of support should be mentioned

Viewport: What is the definition of this?

Proposed Change:

Replace viewport with another word or define it

A change in content is not always a change in context…: I would argue that a change in content is always a change in context. How do screen readers or magnifiers deal with expanding menus etc?

Proposed Change:

Clarify or rewrite SC

Submit buttons: Research has found that labelling a button "Go" is not informative enough. Buttons should be labelled "Find", "Submit", "Search" etc instead

Proposed Change:

Change the technique & replace "Go" with "Find", "Search" etc

Dynamic navigation: Why is this an additional technique? It is irrelevant to the SC

Proposed Change:

Delete this additional technique

Example 3 - Example of a Failure: Why is this a violation of this SC - it is unclear

Proposed Change:

Clarify the example

… and that the Web unit is well-formed: whether the document is well-formed or not is irrelevant to this SC

Proposed Change:

Remove this part from the technique

Item Number: How to Meet Success Criterion 3.1.5
Part of Item: Intent
Comment Type: GE
Comment (Including rationale for any proposed change):

The statement "help people with reading disability" in the intent section of the How to meet 3.1.5 section is incorrect. The ability to comprehend high level language is not related to reading disability. Reading disability is strictly associated at a more general level with lessened ability to mentally convert visual textual information, into verbal auditory information (phonemic awareness). There is no concept of sematic disability associated with reading disability. By definition, a person with a reading disability does not have a sematic processing disability, with normal or above normal intelligence. There are several references throughout the HowTo document that refer to reading disability as an inability to understand. These statements need to be removed. They are not true (see: howto 3.1.6). Reading disability does not affect a person's ability to understand.

Proposed Change:

Remove references to to simplified language being an accomodation for those with a reading disability.

Comment: The paragraph "This requirement does not apply to individual words or to phrases that have become part of the primary language of the content. For example, "rendezvous" is a French word that has been adopted in English, appears in English dictionaries, and is properly pronounced by English screen readers." does not give enough guidance to developers as to what individual words or phrases qualify as a change in language.

For example, some words are *just* entering the English language or are names used in products. For example is does Bordeaux wine have to have Bordeaux marked up?

Proposed Change:

Give further examples of how to clarify if a word should be marked up or not. One example may be is the word is in the dictionary for the natural language of the page (i.e. in the UK the word is in the Oxford English Dictionary).

Comment:

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

Device-independence?

A Web page has a field that automatically updates with the latest headlines in a rotating fashion. There is a slider that allows the user to slow the update rate by as much as 10.

A slider? That requires a mouse, not to mention full vision.

Comment:

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

Flashing (but not blinking)

A movie with a scene involving very bright lightning flashes is scripted so that the lightning only flashes two times.

Yes, WAI wants you to rewrite your script.

Comment:

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

Text alternatives

[INS: [For n] :INS] on-text content that is multimedia... it is important that users know what it is when they encounter it on a page so they can decide what action if any they want to take with it. A text alternative that describes the multimedia and/or gives its title is therefore provided.

How do I do that with, say, embed, which permits no fallback content? (Of course there's noembed, but, since all graphical browsers understand embed, noembed content will never be displayed. In any event, there is no actual or official specification for embed and especially noembed.) Does this not mean I have to label each video in plain text?

Comment:

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

Text alternatives

And now, the biggest failure of the section on text equivalents. I've been warning WCAG Working Group about this topic for years. The fact that the following example made it this far into the writing process demonstrates that the Working Group simply will not accept reality.

A data chart: A bar chart compares how many widgets were sold in June, July, and August. The short label says, "Figure one - Sales in June, July and August." The longer description identifies the type of chart, provides a high-level summary of the data comparable to that available from the chart, and provides the data in a table. It is obviously a lost cause to try to explain to WCAG that diagrams and data are not interchangeable. We create diagrams because data are too hard to understand. To use an analogy over again, diagrams and data are like a suitcase that can be unpacked but not easily repacked. If data were understandable by themselves, we wouldn't make a chart. I can assure the Working Group that giving nondisabled people a really nice chart and disabled people a table with 10,000 or more data points does not constitute equality in any sense. Moreover, some data can be understood only if transformed (as by plotting on a logarithmic scale), which is the sort of thing that simply cannot be expressed understandably in numbers. I am aware that the National Braille Association has authorized WAI to publish parts of its training manual concerning the rendition of charts and graphs in audiobooks. I have seen no evidence that those techniques are viable on the Web. Given that they seem to work fine for audiobooks, I would be interested to see any such evidence.

Comment:

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

Multimedia

People who are deaf, are hard of hearing, or who are having trouble understanding audio information for any reason can read the text presentation or (in the future) have it translated and presented as sign language by assistive technology.

No such vapourware technologies of text-to-sign translation will be available and reliable during the lifetime of WCAG 2. (If you think otherwise, here's something for you: Can you make it work in Quebec Sign Language?)

Similarly:

Captions may be generated using real-time text translation service (stenographic or, in the future, speech-to-text with corrections).

Who's gonna do those corrections (in real time, no less)? And at what point in the "future" will this be developed? The existing technique of speaker-dependent speech recognition, known as voicewriting, could be included here if defined properly.

Comment:

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

Providing open captions that are embedded directly in the video stream

"Embedded"? As by using embed? What are they trying to get at here? Burned-in open captions (a nice, easy, understandable terminology that could be used) or encoded captions that always display even if the viewer doesn't want them (a much rarer case, similar to forced subtitles on DVD)?

Comment:

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

Providing closed captions using any readily-available media format that has a video player that is free of charge and supports closed captioning

Funny... Jaws isn't free. Why are we restricted to the usage of free players when accessibility software in other contexts is expensive?

Comment:

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

+ An audio file begins playing automatically when a page is opened. However, the audio can be stopped by the user by selecting a "silent" link at the top of the page.

+ An audio file begins playing automatically when a page is opened. However, the audio can be stopped by the user by selecting a "silent" link at the top of the page.

Why does this section not cover the more typical scenario, a Flash splash page with sound that plays and then stops, or that plays and can be turned off only by a hard-to-find control, often at the bottom of the page? (I've also seen such controls appear only after the sound has finished playing.)

Comment:

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

A sequence is meaningful if the order of content in the sequence cannot be changed without affecting its meaning. The order of words in sentences and sentences in paragraphs, for instance, is always meaningful.

Not in free-word-order languages, though many of those do tend to converge on certain preferred word orders.

Comment:

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

Ensure that numerals or other look alike glyphs are not used in place of letters

There goes your l33tspeak, h4xorz! (\/\/C4G iz teh sux0r @nyw@y111oneoneone)

Comment:

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

Failure of SC 1.3.5 due to using a non-text mark alone to convey information

Note: Glyphs are non-text marks.
This is insane. Unicode [6]defines glyph as:

1. An abstract form that represents one or more glyph images.
2. A synonym for glyph image. In displaying Unicode character data, one or more glyphs may be selected to depict a particular character.

In Web content, glyphs are text marks.

http://www.w3.org/WAI/GL/2006/07/10-wcag-teamc-minutes#item06 Michael to propose additional information about what glyphs are and are not, and what would be relevant to to this failure condition

Comment:

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

Using an image for "0m" (circle mark) or "×" (cross mark) instead of text and providing alternative text for the image which describes the meaning of its mark

Those circle and cross marks are text. Even the Understanding document itself uses them as such. (The "cross mark" is incorrectly chosen. What is depicted is a [7]multiplication symbol.) WAI may wish to look at Unicode characters like U+2611 BALLOT BOX WITH CHECK.

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

While there are two HTML techniques about labeling form controls--\"H44 (Using label elements to associate text labels with form controls)\" and \"H65 (Using the title attribute to identify form controls when the label element cannot be used)\"--there is no common failure about _not_ labeling form controls. This also applies to 4.1.2.

Proposed Change:

Add a common failure about not labeling form controls.

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

While there are common failures about _inappropriate_ text alternatives (F30) and omitting the alt attribute _for decorative non-text content_, namely img and applet per test procedure (F38), there is no common failure about not having a text alternative for img, area, input[@type=\'image\'] in general (alt attribute).

If there is no alt attribute, F30 does not apply. If the non-text content is not decorative only, F38 does not apply.

applet and object is a different case. As the text alternative is the text content of these elements (or in case of applet the alt attribute), there is always at least an empty text alternative.

Proposed Change:

Add a common failure about omitting the alt attribute for img, area, input[@type=\'image\'] in general.

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

In the document \"About Baseline and WCAG2.0\" it states

\"They would use the HTML 4.01 techniques described as “sufficient� in Understanding WCAG 2.0. (Authors may further enhance the user experience by also using additional HTML techniques listed as “advisory� (optional) in Understanding WCAG 2.0.)\"

The sections with advisory techniques are clearly labeled as \"Additional Techniques (Advisory) for x.x.x\"

The techniques deemed as sufficient requires that you read the paragraph under the title \"Techniques for Addressing Success Criterion x.x.x\" which does says \"Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion x.x.x as long as the technologies used are in the baseline you are using.\"

Proposed Change:

Clearly mark the \'sufficient\' techniques in the document to aid understanding both documents.

Comment (including rationale for any proposed change):

The technique "Providing a synchronized video of the sign language interpreter that can be displayed in a different viewport or overlaid on the image by the player." can be deleted. There is no need for a different viewport. The video can be placed in the same viewport, either on the same page or in an own page.

Proposed Change:

Replace this with "If the sign language interpreter expresses a content of a video you can include a sign language interpreter in the corner of the video stream. For best comprehensibility only use this technique in videos with fullscreen size."

Comment (including rationale for any proposed change):

The technique "Including a sign language interpreter in the corner of the video stream" is only sensible for fullscreen videos, otherwise the signer is too small and not understandable.

Proposed Change:

Replace this with "Provide a video with a sign language interpreter expressing the text contents without restrictions."

Comment from the i18n review of:
http://www.w3.org/TR/2006/WD-UNDERSTANDING-WCAG20-20060427/

Comment 4
At http://www.w3.org/International/reviews/0606-understanding-wcag2/
Editorial/substantive: S
Owner: RI

Location in reviewed document:
3.1.1 Example 1

Comment:
"A Web unit produced in Germany includes content in both German and English, but most of the content is in German. The primary natural language is identified as German (de)."


If the primary language is expressed using HTTP or meta tags, it is possible that both languages should be identified if this is a document aimed at a bilingual audience. If the primary language is to be expressed in the html element tag, only one language can be chosen. This example is too vague. This goes back to the question of what WCAG means by 'primary language'.

5. Source order must match presentation order even at the lowest
level ... why?

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

Refer to paragraphs under Advisory Techniques for Guideline x.x starting with "Specific techniques for ..." and ending with "more accessible to more people."

Comment:

The fact that there are two categories is already stated in the introductory content at the start of the doc. The paragraph that follows this heading is unnecessarily repetitive.

Proposed Change:

Consider replacing with headings like:

- Advisory Techniques for Guideline x.x (general, not criteria specific)
- Advisory Techniques for Guideline x.x (criteria specific)

(If there are none under either category, a single word following the heading saying, “None�, is sufficient). The recommendation made is consistent with other headings like: Technology-Specific Techniques

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

Highlighting information should also be mentioned. Many people highlight text using just a span and it is a cue to visusal users but not to computer devices.

Proposed Change:

Add highlighting to the list that includes emphasising, headers, strong, etc. I recommend that highlighting is a special form of em tag using css.

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

Multimedia documents are not mentioned. There are many flash documents that have a constantly moving background which is highly distracting.

Multimedia should also be mentioned with luminosity and other sections. It may, however, be out of the scope of the document.

Proposed Change:

Include multimedia in the recomendations so people will not be in compliance if they use obnoxious moving backgrounds.

Comment: JIS X 8341-3 has an example of sound effects such as beep, chime, and ding-dong, which sound notify the user that, for example, the answer is correct. These sounds may be used in e-learning system. In this case, people who are deaf, hard of hearing, or having trouble to understand audio information may not hear or understand the sound effects.

Proposed Change:

Add the following example to the "Examples" section.

8. A sound effect
The web page of the e-learning content uses the sound effects. The chime sound indicates that the answer is correct and the beep sound indicates that the answer is incorrect. An alternative text is shown on the page so that people who can't hear or understand the sound understand whether the answer is correct or incorrect.

Comment: New example should be added to Understanding document. JIS X 8341-3 has an example of the words of foreign origin which may be unfamiliar to users.

Proposed Change:

The meaning of an unfamiliar adopted foreign word

The meaning or the translated word is provided within the page by using the parenthesis right after the word or the internal link from the word.

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

I\'ve been up to to my eyeballs in the documents lately for a multination client who is developing a policy. And have noticed a few things I hadn\'t noticed before.

Although GL 1.3 says \"Ensure that information and structure can be separated from presentation\" we have not said *anywhere* in the document that we discourage table layout. If we discuss layout tables (ie. table summary element) and do not mention our prefference to CSS layout then we are tacidly endorsing layout tables I would say.



Proposed Change:

Propose that we add a note to all the techniques that address table layout (F46,F49,G57 etc.) which would say something like:

\"Note: Although Layout tables are allowable under the GUidelines, the working group recommends the use of CSS layout rather than HTML layout tables because CSS layout is more in line with the principle of separation of presentation and content.\"

Part of Item: Examples
Comment Type: TE
Comment (including rationale for proposed change):
"breadcrumb trail" is no more an obvious term than many others in the glossary.

Proposed Change:

Add glossary entry for "breadcrumb trail".

Move to Level 1: From what I understand, this is the equivalent of making sure information is not provided via colour alone, so why is it at Level 2?

Proposed Change:

Move 1.3.5 to Level 1

Intent vs Benefits: These two sections are essentially the same

Proposed Change:

Either differentiate the two sections more, or merge them

Heading: Heading "Additional techniques (Advisory) for 2.4.1 should be the same heading level as "Common failures…"

Benefits: The benefits section does not describe this SC

Proposed Change:

Rewrite the Benefits section

Example: The text "Example of the results of a failure to meet the success criterion" is incomprehensible

Proposed Change:

Rewrite example

Small sites: What if a site is only three pages - is it still required to provide a breadcrumb trail etc?

Proposed Change:

Clarify SC

Add a technique (or example) to use the LINK REL attributes of Next, Index etc

Benefits: Add that this benefits people with cognitive disabilities

Examples: The example implies that this SC requires that correctly filled out fields are kept available after reload - is this what this SC requires?

Proposed Change:

Clarify the SC

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

Situation A - If a mandatory field contains no information: recommend replacing text "text message" with another word - this has connotations with mobile phones

Proposed Change:

Rewrite the technique

Benefits: These SC do not assist people with cognitive disabilities

Proposed Change:

Remove from the Benefits section that these SC assist people with cogntive disabilities

Resources: The Juicy Studio Readability Comprehension tool should be included

I cannot comment properly on this SC until there are failures documented

Proposed Change:

Consistency: Sometimes the Benefits section is bulleted, sometimes it is prose.

Proposed Change:

Ensure consistency throughout the documents

Backwards compatibility: There is mention of future compatibility but nothing about backwards compatibility. Has the W3C reversed its position on backwards compatibility?

Proposed Change:

Clarify the W3C's position on backwards compatibility

How can you have an Advisory example?

"Grouping blocks of repeated material in a way that can be skipped USING one of the technology-specific techniques below (for a technology in your baseline)" is ambiguously worded due to a dangling participle. I read it at first as equivalent to saying
"Group blocks of repeated material, using a method that can be skipped using the techniques."

Proposed Change:

Insert a comma so it reads
"Grouping blocks of repeated material in a way that can be skipped, USING one of the technology-specific techniques below (for a technology in your baseline)"

In " Techniques for Addressing Success Criterion 4.2.1", the ordered list of three items has "OR" between items 1 and 2, but nothing between items 2 and 3 to clarify their boolean relationship.

Proposed Change:

Insert "OR" at the end of bullet item 2.

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

In the GL list Wendy posted the following explaination that i think would be good to add to the intent section to explain. John suggested an edit which is also included.

Proposed Change:

WCAG 1.0 says "If you can't avoid building stairs, build an elevator." It doesn't say anything about making the elevator easy to find or get to. SC 4.2.1 of WCAG 2.0 says, "If you can't avoid building stairs, provide an elevator at the main entrance, along with the stairs."

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

Pat yourselves on the back and don't let anyone tell you otherwise, your documentation is FANTASTIC. I found it very helpful while redesigning the interface for Safari Books Online to meet WCAG 2.0 guidelines (not an easy task). Your compliance techniques were indispensable. All the techniques are well-written, cristal clear, and "trustworthy" meaning that I know the techniques are based on what works for real people, not just in theory. Thanks to you, I have a prototype I and the client can be proud of. Your efforts continue to ensure that compliance isn't something you do to "get the sticker", but something you do to make sites better for everyone.

Proposed Change:

Treat yourselves, you deserve it. Don't forget to post those party photos. :-)

Comment:

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

Text alternatives

Providing what description is possible is also desired. If the intent of the author in creating the content - or the intent of the page author in putting the content on the page - is known and can be described, this is also very useful

"Intent of the page author"? What is this talking about?

Comment:

Text alternatives

Linking to live textual information, e.g., if it is a traffic Webcam, linking to a site that provides textual traffic reports

If my Webcam is pointed out my window and depicts my obscure street or intersection, exactly how am I going to locate a traffic-report site that covers my neighbourhood? And how is that actually "equivalent" given that a sighted visitor can watch traffic in real time, while a "textual traffic report" has to be written and published post-facto and can never keep up?

Comment:

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

I appreciate the fact that my work is cited in this document - [4]Best Practices in Online Captioning and [5]Standard Techniques in Audio Descriptions (sic - it's actually singular). I note, though, that the only contributors to these "Related Resources" that merit a real byline are the National Braille Association and... Gregg Vanderheiden, dear coleader of the WCAG Working Group

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

reposting the comment at:
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006Jun/0225.html
due to incorrect paste of comment.

(Helpful detail in \"Understanding WCAG 2.0.\" EOWG sends its compliments)

Unclear purpose of document.



Proposed Change:



The Introduction needs an opening statement along the lines of \"this is not an introductory document - it is a detailed description of the guidelines and their success criteria\" and adds a pointer to the \"Overview\"
document for people requiring a simple introduction.

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

The title of \"Understanding WCAG 2.0\" continues to be a concern for EOWG, because of several possible misinterpretations.


Proposed Change:

EOWG recommends adding an exlanatory subheading to the document. Suggestions include:
a. Your guide to meeting the requirements of WCAG 2.0
b. A guide to How to Meet the Web Content Accessibility Guidelines 2.0
c. A definitive guide to meeting WCAG 2.0
d. The authoritative, encyclopaedic and indispensable guide to WCAG2.0
e. A guide to learning and implementing WCAG 2.0
f. A guide to understanding and using WCAG 2.0

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



Proposed Change:

Please add explanations of the four principles to the Understanding document.

Comment (including rationale for any proposed change):

Reasons of why using sign language videos are wrong.

Proposed Change:

Replace it with: "The intent of this success criterion is to enable people who are deaf or hard of hearing and who are fluent in the sign language to understand whole texts. Many people, especially native signers, find it easier to follow sign language than to read the text, since the text are often a second language to them."

Comment (including rationale for any proposed change):

The thesis "People whose primary language is a sign language sometimes have limited reading ability" is not always true. The reading ability of native signers is broad, from low to top. The focus on captions is not meeting the reality. Many native signers are able to understand captions. The focus has to move to the complete content, i.e. the texts.

Proposed Change:

Replace it with "These individuals may not be able to read and comprehend the textual contents and thus require a sign language interpretation to gain access to the multimedia content."

Comment (including rationale for any proposed change):

The thesis "Some people who communicate using sign language and are proficient readers may have impaired vision which may make it difficult to read the captions on the screen. A sign language interpretation may be easier to view." is misleading: Captions are zoomable, a video with a signer is not zoomable to meet impaired vision.

Proposed Change:

Suggestion: Delete it.

Comment (including rationale for any proposed change):

The note "Different sites may address...sufficient by the working group" is a little bit misleading in case of deaf people.

Proposed Change:

Please add to the note that in case of deaf people it is wrong to think about deaf people as human beings not able to understand "texts above upper secondary education level". It is not about cognitive impairments, it is about linguistic matters. It is just that many deaf people understand sign language better than written language, because sign language is their mother tongue. With sign language "texts above upper secondary education level" are more understandable for deaf people.

Comment from the i18n review of:
http://www.w3.org/TR/2006/WD-UNDERSTANDING-WCAG20-20060427/

Comment 3
At http://www.w3.org/International/reviews/0606-understanding-wcag2/
Editorial/substantive: E
Owner: RI

Location in reviewed document:
3.1 Additional techniques

Comment:
We would be interested in knowing what you will say about use of dc:lang

Comment from the i18n review of:
http://www.w3.org/TR/2006/WD-UNDERSTANDING-WCAG20-20060427/

Comment 5
At http://www.w3.org/International/reviews/0606-understanding-wcag2/
Editorial/substantive: E
Owner: RI

Location in reviewed document:
3.1.2 Related resources

Comment:
The links to Liam Quinn's documentation are not very specific. We are also concerned that the information at the end of these links no longer constitutes best practise - for example, if you look under SPAN there are recommendations to use the <i> tag, rather than <em>, and attribute values are given without quotes.

Comment from the i18n review of:
http://www.w3.org/TR/2006/WD-UNDERSTANDING-WCAG20-20060427/

Comment 6
At http://www.w3.org/International/reviews/0606-understanding-wcag2/
Editorial/substantive: E
Owner: RI

Location in reviewed document:
3.1.2 Related resources

Comment:
There should be a pointer to
http://www.w3.org/TR/i18n-html-tech-lang/ [http://www.w3.org/TR/i18n-html-tech-lang/]
when that document is published. Note that it is currently a WD, and that the title has recently changed in the editor's copy to "Internationalization Best Practices: Specifying Language in XHTML & HTML Content".

Comment from the i18n review of:
http://www.w3.org/TR/2006/WD-UNDERSTANDING-WCAG20-20060427/

Comment 7
At http://www.w3.org/International/reviews/0606-understanding-wcag2/
Editorial/substantive: E
Owner: RI

Location in reviewed document:
3.1.3 Idioms

Comment:
The markup for the Dutch example says:


<span lang="nl-NL">Hij ging met de kippen op stok</span>


We recommend that you remove the -NL unless you really want to make the point that this is an idiom specific to the Netherlands. In general, language values should be kept as short as possible.


On the other hand, since the W3C uses American English spelling, you may want to change the lang attributes in the html element to "en-US" - which will help for spell-checking, and possibly also for voice browsers?

Comment from the i18n review of:
http://www.w3.org/TR/2006/WD-UNDERSTANDING-WCAG20-20060427/

Comment 8
At http://www.w3.org/International/reviews/0606-understanding-wcag2/
Editorial/substantive: S
Owner: RI

Location in reviewed document:
3.1.3 Idioms

Comment:
The markup for the Japanese and Dutch examples should include xml:lang attributes as well as the lang attribute, since this is XHTML served as text/html.


Please check this for any other phrases in non-English text.

Comment from the i18n review of:
http://www.w3.org/TR/2006/WD-UNDERSTANDING-WCAG20-20060427/

Comment 9
At http://www.w3.org/International/reviews/0606-understanding-wcag2/
Editorial/substantive: E
Owner: RI

Location in reviewed document:
3.1.5 Resources

Comment:
Since this section says that this guideline can be applied to non-English text, it seems strange that there are no references at all to non-English assessment techniques in the Resources section.


Please provide some.

Comment from the i18n review of:
http://www.w3.org/TR/2006/WD-UNDERSTANDING-WCAG20-20060427/

Comment 10
At http://www.w3.org/International/reviews/0606-understanding-wcag2/
Editorial/substantive: Owner:
Location in reviewed document:
3.1.3 Idioms

Comment:
"Example 3: In Japanese, the phrase "��を投�る（���る� �も�� ���り���ら�る��" literally translates into "he threw a spoon". But it means that there was nothing he could do and finally he gave up. "


The Japanese original text is confusing, since it contains both "he threw a spoon" *and* the explanation. The latter, that is ���る� �も�� ���り���ら�る�� , should be deleted.


(If the non-English text in this comment is mangled by the email process, please follow the above link to the original table of comments.)

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

It would be helpful to show working examples of the code sample given. This would be useful in other places in the document as well. I don\'t want to create HTML files for each example.

Proposed Change:

Create the working examples.

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

Also applies to other sections.

The content must be identical. If you allow people to use mutliple versions, you must tell them that they have to keep the two identical because it is an easy way to create discrepancies and then there is an information gap. I would rather have one accessible version that exists.

Proposed Change:

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

I would add another section to 3.1 that alows users to increase or decrease the text size through the browser or the website. Or the text will work with multiple default text sizes. I think this is a bigger deal than screen readers and zooming in. Most 50 people have bad eyesight and don\'t know how to use windows zoom, but can be taught the make text bigger trick and have it as a large size by default. This breaks some websites and makes the content un-usable.

Proposed Change:

Add a section under 3.1 that allows users to increase the text size a reasonable amount and still have the website readable/usable/etc.

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

It would be extremely useful to have an easy way to refer to specific guidelines and success criteria. Trying to refer to them by numbers or their long text is awkward. More importantly, it is a significant barrier to common Web developers being able to communicate about them, and it makes the guidelines even more esoteric.

I propose including “shortnames�? or “handles�? in the “Understanding�? doc. I understand that it is quite difficult to do. I think it is OK for them to not be technically accurate, and instead make them easy and use common terminology, e.g.,:
- “Alt-text�? for “Guideline 1.1 : Provide text alternatives for all non-text content�?
- “Multimedia alternatives�? for “Guideline 1.2 : Provide synchronized alternatives for multimedia�?
- “Separate content and presentation�? for “Guideline 1.3 : Ensure that information and structure can be separated from presentation�?
- “Contrast�? for “Guideline 1.4 : Make it easy to distinguish foreground information from its background�?

I understand the concerns with shortnames/handles being used inappropriately; however, I think the benefits far outweigh the risks.

Also, I think that putting these in the “Understanding�? doc and not the /TR/WCAG10 doc helps some with concerns about them not being insufficient to convey the full meaning of the long text.


Proposed Change:

Include shortnames/handles for each guideline and success criteria (and principle while you’re at it since those are easy :).