Disposition of comments for the Accessibility Guidelines Working Group

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

First step in test should be to check if longdesc is required.

Proposed Change:

Add first step \"Check if short text alternative is sufficient for image\". If not sufficient then go on to step 2.

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

H51 seems to be the same as F34 \"using white space characters to format tables in plain text content\".

Proposed Change:

Remove either H51 or F34 or describe difference between them.

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

Labeling of form controls is covered by H44 so these 2 techniques should be rolled into one.

Proposed Change:

Combine H65 and H44 into one technique or clarify differences between the two.

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

All layout tables have no summary? What about first first layout table with description? Could be others too. A description of layout table is beneficial in some cases.


Proposed Change:

Allow for summary on first level layout table if summary describes navigation of table.

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

Does not apply to all text. Only text that is relative, pertains or necessary.

Proposed Change:

Change wording so it applies only to necessary text.

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

Not a good technique. Jim Thatcher\'s article (referenced from this technique) says \"Better than such a \"jump table\" would to be to markup the sections with headings markup\".
Also better is to create an index.

Proposed Change:

Remove technique or provide examples of how it\'s more useful than other techniques.

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

Too broad and undefined. How many links? Where should they be placed? All documents? Which terms? This technique is untestable as is.

Proposed Change:

Clarify the technique so it is more specific.

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

Good technique but which sites require a sitemap? Should sitemap really contain *all* links? Contain hierarchy, structure? Alphabetic, category? Same as site\'s organization?

Proposed Change:

Describe when to use sitemap instead of other organizational structures. Provide other examples of good sitemaps and describe characteristics of bad sitemaps.

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

Refers only to change of focus but problem can occur with other actions. i.e. select, onmouseout, onblur or page loading etc.

Proposed Change:

Broaden the technique to include other actions that should not cause change of context. Or describe exactly what constitutes an \"activate\" action.

Comment (including rationale for any proposed change):

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

Trivial examples

One of the most common examples of using inconsistent labels for components with the same function is to use a button that says "search" in one page and to use a button that says "find" on another page when they both serve the identical function.

And the words have identical meaning.

Proposed Change:

Comment (including rationale for any proposed change):

Testing in browsers

The blink value of the text-decoration property is not supported by Internet Explorer. For Windows or Mac? It is supported in Netscape/Mozilla family browsers. Not tested in others (e.g., Safari, Opera). And why wasn't it tested in those "others"?

Proposed Change:

Comment (including rationale for any proposed change):

CSS defines the blink value for the text-decoration property. When used, it causes any text in elements with this property to blink at a predetermined rate. This cannot be interrupted by the user, nor can it be disabled as a user-agent preference.

User stylesheets would seem to be useless in this regard, as they do not permit the rewriting of selectors. However, User Agent Accessibility Guidelines [4] Checkpoint 3.3 requires the ability to toggle blinking text. This appears to be a user-agent problem, in whole or in part.

Proposed Change:

Comment (including rationale for any proposed change):

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

A user clicks on a link, and a new window appears. The original link has no associated text saying that it will open a new window. [...] Check if elements that open new windows have associated text saying that will happen. The text can be displayed in the link, or available through a hidden association such as an HTML title attribute.

target="_blank" is programmatically determinable and it is up to the user agent to warn the user. JavaScript is another story and should be addressed by the Techniques.

Proposed Change:

Comment (including rationale for any proposed change):

The note "These techniques may need to be adapted for Web-based presentation" is not really helpful.

Proposed Change:

Link to examples, e.g. http://www.taubenschlag.de/videos/index.html. Add a english translation of the German guidelines for Sign Language Videos.

4. You can’t use offscreen positioning to add labels (e.g., to forms)
that only some people, like users of assistive technology, can
perceive. Everybody has to see them.

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

G14 is associated with 1.3.2. As written, it is too restrictive and is more applicable to 1.3.4. Unfortunately, that does not leave a technique for 1.3.2.

I have also commented that 1.3.4 may be rated at too low a level. This comment assumes that 1.3.2 and 1.3.4 remain unchanged.

Proposed Change:

Associate G14 with 1.3.4.

Just one idea: Add a technique for 1.3.2 where red H3 headings are underlined and green H3 headings are italicized.

Item Number: H1: Adding the dir attribute to a block level element to change its directionality...
Part of Item: Applicability
Comment Type: ED
Comment (Including rationale for any proposed change):

Says H1 is referenced from 1.3.1 but it's not. It is referenced from 1.3.3.

Proposed Change:

H1 could fall under both 1.3.1 and 1.3.3. Fix applicability so it falls under the appropriate SC.

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

Confusing technique.
Does Jim Thatcher\'s article state this?
Examp1e 1 \"Skip navigation links\" is same as G1.
It seems that breaking up the page into several pages would be better.

Proposed Change:

Provide more examples of where this is used to clarify its use.

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

There needs to be a technique the describes how to include words within an image in the alternate text.

Proposed Change:

All text within the image that is relative to the document should be included in the alternate text. Relates to technique H36 and others.

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

None of the tests are expressed as testable statements. None of the tests have examples.
Tests already exist at:
http://www.w3.org/WAI/GL/WCAG20/tests/

Proposed Change:

Express the tests as testable statements. Include example files.
Use the existing tests.

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

Location of alt text is ambiguous. Could be in alt attribute or in body of applet.

Proposed Change:

applet contains a text equivalent in the alt attribute of the applet.

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

Does not describe what should go in noembed.

Proposed Change:

noembed should contain alternate content that provides the same information as the embed.

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

Test does not test for technique. Test only looks for long description.

Proposed Change:

Modify test so it looks for any alternate content that provides same information as object.

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

HTML technqiues H46 and H53 are also referenced from SC 1.1.1. In SC 1.1.1 they are used for
\"Providing long description for non-text content that serves the same purpose and presents the same information\".
In SC 1.2.7 they are used for \"Providing a full multimedia text alternative including any interaction\".
Are these the same thing? If different then there should be 2 techniques.

Proposed Change:

Clarify the use of H46 and H53 or create new techniques.

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

Contains the text \"Use of layout tables is not recommended...\". The text \"not recommended\" is unclear. Does this mean \"must not\" or \"should not\"?

Proposed Change:

Remove text \"not recommended\" or define its meaning.

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

There needs to be a technique on the use of layout tables.

Proposed Change:

Add a technique describing the use of layout tables. Layout tables are OK as long as they are not nested too deep (more than 4 levels). They should not have too many rows or colums (not more than 4 X 4).

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

The example showing an implicit label association is misleading: \"<label>First name <input type=\"text\" name=\"firstname\"></label>\"
This label is explicitly associated with the form control (the label contains the form control, it is not implied).
Technique H65 states this is OK \"...by including the form control within the label element\".
If there was more than one control within the label element then it is ambiguous and wrong.
If the label does not contain the form control then there is an implicit relationship.
The \"note 2\" text is incorrect: \"Labels for these elements are implicitly associated via the value attribute\".
Using an attribute of the element is an explicit association, not implicit.

Proposed Change:

Do not use the word \"implicit\" to describe relationship of label containing control or label using attribute.

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

The use of the word \"label\" can be confusing. Its use here does not refer to the label element.

Proposed Change:

Use the word \"name\", \"identifier\" or something similar so readers do not think this is a technique about using the label element.

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

Technique is poorly defined. There are several ways to group related sentences other than using a P element (i.e. lists, tables).
Technique may not apply to other languages.
Technique deals with writing style which is difficult to describe and test for.

Proposed Change:

Clarify the use of P element in relation to other text structuring elements.

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

Does not mention other semantic markup used improperly in layout tables (see H43).

Proposed Change:

Include other semantic markup SCOPE, ID, HEADERS in list of elements to avoid.

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

Should also include Applet, Object and Embed.

Proposed Change:

Include other examples of applet, object and embed that make use of pattern and color.

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

Very vague and difficult to test for. The words \"meaningful sequence\" are not defined. As this is a level 1 it should be clearly defined.

Proposed Change:

Provide clear examples of when this problem occurs and how to test for it.
Define \"meaningful sequence\".

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

Seems similar to H1. What is the difference between using DIR attribute on inline and block elements?

Proposed Change:

Roll H1 and H56 into one technique or describe differences between use of DIR attribute on inline vs. block elements.

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

Very difficult to test for this.
Says to use Q element which fails under IE.
WCAG doc itself does not use Q element.
Should be techniques about misuse of semantic markup for presentation.

Proposed Change:

Describe clearly when this applies.
Do not recommend use of Q element.
Add techniques that discourage use of semantic markup for presentation (i.e. misuse of Hx, BLOCKQUOTE etc.)

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

Very broad. Should only be used when there is ambiguity. i.e. if there is only one image then OK to refer to it as \"see image below\".
Does the use of \"top\" (WCAG2 navigation buttons) fall under this? What about G74 that uses text \"Details in text following the chart:\"


Proposed Change:

Make it clear that this is needed only if there is ambiguity.

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

Should be modified so you must set all colors or no colors. (i.e. Just specifing text and background colors without vlink colour is wrong)


Proposed Change:

Change text so it says \"set all colors or no colors\".

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

It\'s unclear how many are in a group.
\"related\" is not defined. Are all links on a page related?

Proposed Change:

Navigation and menu are good examples. Provide other examples or keep it to navigation and menu or define what \"related\" links are.

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

This technique suggests that using frames to group material is on par with using headers, div\'s, link groups etc. Is that the intent?
Is this really a problem? Are there examples of sites that change frame content types?
The requirement for NOFRAMES has been dropped. Is this an oversight or is NOFRAMES really no longer necessary?

Proposed Change:

Add text that explains this technique is useful *if* frames are used in the page. If frames are not used then don\'t add them just for grouping blocks of material.

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

Too broad. Not all documents require a TOC so must specify which ones do.
Is this the same as navigation links?
Is this for a document or whole site?

Proposed Change:

Specify when this is needed.
Describe how this is different from navigation links.
Describe how TOC for document is different from TOC for site.

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

Very broad. How long before deleted material is really gone? Is recovering from backup OK. Call to admin required to regain backup OK?
Type of information is not specified. Could be trivial information like stored by search engine.

Proposed Change:

Add text to explain that this applies only to non trivial information. Or info that is difficult to enter again. Define parameters for getting backup. Can\'t be difficult like phoning sys admin.
Put a time limit on getting backup info. Perhaps session timeout.

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

The \"set of web units\" is not defined. Does this include every single page?

Proposed Change:

Define which pages of the site must have this. Or describe exclusions.

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

the title of this technique refers to
\"Placing a link to the transcript immediately next to the non-text content\"
However, a transcript is not sufficient here. It needs to be a \" full multimedia text alternative including any interaction \"

Proposed Change:

Change \"transcript\" to \" full multimedia text alternative including any interaction \"

Comment (including rationale for any proposed change):

As far as I understand http://www.w3.org/TR/WCAG20-TECHS/#N100C7 (or http://www.alistapart.com/articles/tohellwithwcag2 which translate it into point 12 : « CSS layouts, particularly those with absolutely-positioned elements that are removed from the document flow, may simply be <http://www.w3.org/TR/WCAG20-TECHS/#N100C7> prohibited at the highest level. In fact, source order must match presentation order even at the lowest level. », I can't agree with that.

Proposed Change:

http://blog.html.it/layoutgala/ shows 40 design based on the same markup, but with differents visual apparences and ordering. It is accessible! Accessibility means that the content must be *understandable* without the CSS, not that it should be presented in the same order.

Comment (including rationale for any proposed change):

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

Instant-messaging applications are not Web content

An instant-messaging application uses two simple glyphs to indicate a person's instant messaging status. An instant-messaging application is not Web content. (Yes, I know, it's possible to use the Web as a front end for instant messaging, as with Google Chat and Meebo. Those are not applications.)

Proposed Change:

Comment (including rationale for any proposed change):

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

Text equivalents

alt="" "" is officially permitted alongside the actually correct alt="""".

Proposed Change:

Comment (including rationale for any proposed change):

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

Incorrect CSS or usage

The Techniques document gives incorrect CSS in places, or simply gives unrealistic examples that don't match the practices of standards-compliant developers.

<!DOCTYPE html PUBLIC ""-//W3C//DTD XHTML 1.0 Transitional//EN""
""http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"">
<html xmlns=""<url>http://www.w3.org/1999/xhtml"">http://www.w3.org/1999/xhtml</
title>"">
<html>
<head>
<title>A study of population dynamics</title>
</head>
<body bgcolor=""white"">
<p> ... document body...</p>
</body>
</html>

body bgcolor="""" is an incorrect usage; that's what we have CSS for. (Same for body color="""" later.) Note that the DOCTYPE URL is mangled.

Proposed Change:

Comment (including rationale for any proposed change):

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

Procedure

1. Examine the code of the Web unit.
2. Check to see if a foreground color is specified.
3. Check to see if a background color is specified.

Colours may have been specified in preceding selectors. The C in "CSS" does stand for "cascading," after all. As written, this technique authorizes pedants to write in and complain that not every single element has foreground and background colours explicitly stated. They don't have to be.

Proposed Change:

Comment (including rationale for any proposed change):

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

Failure Example 4:

An E-commerce application uses a printer icon that allows the user to print receipts and invoices. In one part of the application, the printer icon is labeled ""Print receipt"" and is used to print receipts, while in another part it is labeled ""Print invoice"" and is used to print invoices. The labeling is consistent (""Print x""), but the labels are different to reflect the different functions of the icons. Therefore, this example does not fail the success criterion.

So why is it in there?

Proposed Change:

Comment (including rationale for any proposed change):

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

On a page with moving or scrolling content,
1. Check that a mechanism is provided in the Web unit or user agent to pause moving or scrolling content.
2. Use the pause mechanism to pause the moving or scrolling content.
3. Check that the moving or scrolling has stopped and does not restart by itself.
4. Check that a mechanism is provided in the Web unit or user agent to restart the paused content.
5. Use the restart mechanism provided to restart the moving content.
6. Check that the movement or scrolling has resumed from the point where it was stopped.

But the Understanding document uses an example of a stock ticker: A stock ticker has "pause" and "restart" buttons. Pausing the ticker causes it to pause on the current stock. Restarting causes the ticker to jump ahead to the current stock. Stocks that were updated during the pause will not be displayed. So which is it: Once you resume you have to start from where you paused, or can you skip what you missed?

Comment (including rationale for any proposed change):

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

Examples of text streams that are not captions include... subtitles that do not include important sounds

No "subtitles" are "captions." By implication, this technique permits subtitling into a foreign language as long as non-speech information is included.

Proposed Change:

Comment (including rationale for any proposed change):

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

Procedure

1. View the material with captioning turned on.
2. Check that all dialog is accompanied by a caption.
3. Check that all important sounds are captioned.

And how does a deaf person do this?

Proposed Change:

Comment (including rationale for any proposed change):

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

Failure due to opening new windows when the user does not expect them. New windows take the focus away from what the user is reading or doing. This is fine when the user has interacted with a piece of user interface and expects to get a new window, such as an options dialogue. The failure comes when pop-ups appear unexpectedly. Actually, WCAG 2 [5]bans all popup windows without explicit alert beforehand (though at Level 3).

Proposed Change:

Comment (including rationale for any proposed change):

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

A user clicks on the body of a page and a new window appears. No indication that the area that was clicked has functionality is present.

If that area were marked up as a or indeed as area, such warning is programmatically determinable and it is up to the user agent to warn the user.

Proposed Change:

Comment (including rationale for any proposed change):

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

The objective of this technique is to show how using a non-text mark to convey information can make content difficult to comprehend. A non-text mark may be non-text content such as an image, or a font glyph which is not text nor an image of text.

Font glyphs are text. This whole section is nonsense.

Proposed Change:

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

I think it could be helpful for a web developer and evaluator to have the HTML techniques/failures sorted by what the techniques/failures are about, e.g. specific elements like img, area, etc. or concepts like lists, data tables, etc.

Proposed Change:

Add a list of HTML techniques/failures sorted by e.g. specific elements or concepts.

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

I believe the title "Techniques for WCAG 2.0" is misleading. As the document is about failures to correctly address accessibility, I believe the document should be retitled.

Proposed Change:

Retitle "Techniques for WCAG 2.0" as "Failures in Technique for WCAG 2.0".

Name: Liz Danaher
Email: liz.danaher@dwpdevelopment.net
Affiliation:
Document: TD
Item Number: (none selected)
Part of Item: Related Techniques
Comment Type: TE
Comment (Including rationale for any proposed change):
Hi,

I hope you can help clarify something for me. I work on a UK government website and we\'ve recently been checking the site to ensure our colours comply with W3C checkpoint 2.2. We found your suggested algorithms here:
http://www.w3.org/TR/AERT#color-contrast
and subsequently found that some of our colours fail the algorithms for brightness and contrast. However, on checking your own site I also found that the w3.org homepage fails in some areas too.

eg. white text on biege background, brightness = 90 (fail), contrast = 306 (fail)

white text on blue background, brightness = 128 (ok), contrast = 362 (fail)

So I was just wondering, were you thinking of adding any caveats to the checkpoint 2.2, to reassure developers that if their font is above a certain size and/or weight then the algorithms may change. I do realise that you say it's only a "suggested algorithm" anyway, but I'm afraid our bosses are saying we must comply with it, and although our text is also bold and large like yours, we're facing having to redesign the whole colour scheme of our site.

I'd be very grateful if you could provide me with any more advice that you have on this subject so I can work out whether my colours are actually passable or not.

Thanks very much in advance!
Yours,
Liz Danaher

Proposed Change:
(EMPTY)

I think that we need some clarifications about the terms "relative", "absolute" and "relative positioning", expecially when they are used regarding both font sizing units and CSS positioning rules.

In the "Comparison of WCAG 1.0 checkpoints to WCAG 2.0" [1] appendix we can read:

In General (Priority 2):
3.4: Use relative rather than absolute units in markup language attribute values and style sheet property values.

that is is related to:

WCAG 2.0 Success Criteria:
This maps to an advisory technique (Using readable fonts) for Guideline 1.4.

Guideline 1.4 refer to visual and audio contrast [2] and I've not yet found, even in the "Techniques for WCAG 2.0", the advisory technique mentioned (Using readable fonts).

Even in the "CSS Techniques for WCAG 2.0" draft [2] - in which is correctly introduced the idea of "Using em or percent for properties that need to change" instead of "Use relative rather than absolute units..." - the corresponding guideline mentioned is "1.3" ...that refer to the separation of structure and presentation.

However, as Gregg Vanderheiden told: "Most advisory techniques have not been written yet".

Having said that, I must point up that using terms like "relative units", "absolute units" or "relative positioning" maybe somehow confusing.

I'll start from the following assumptions:

1) The general accessibility principle in question is that users (expecially partially sighted people) must be able to enlarge fonts using their visual UA tools.

2) Microsoft Internet Explorer 6 for Windows - and all the previous versions - is not able to enlarge text if it is sized in pixels. But pixels are "relative" lenght units (they are relative to the viewing device resolution) [4].

3) On the other hand there are some CSS absolute-size values that IE/WIN can perfectly enlarge: the absolute-size keywords (x-small, small, medium etc.) [5].

So, it is really confusing to advise CSS designers that they should use relative length units to size fonts.

CSS Techniques correctly tell us to "Use "em" or % for properties that need to change". But we should make another stride to avoid to mention a specific unit identifier: e.g. here in Italy, in our recent accessibility law [6], we have introduced a requirement (Requirement 12) that says: "The presentation and textual content of a page must be able to be adapted to the dimensions of the browser window used by the user, without superimposing objects present or loss of information such as to render the content incomprehensible, including in the case of resizing, enlargement or reduction of the display area or characters in relation to the predefined values of these parameters.". In other words, with this approach we say that the designer must size characters with a unit of his choice that guarantees the enlargement of text in every UA. This is expecially useful to ensure forward and backward compatibility. We cannot forget that, at the time of this writing, IE 6 cover almost all the market.

Cynthia Shelly suggested the term "scalable" to describe this text resizing function.

Summarizing, there are relative and absolute CSS units that are scalable (also in IE6/WIN):

1) for fonts: em, percentages and absolute-keywords (e.g. medium, small, x-small etc.)
2) for containers: percentages and em.

But we have to think about the near future when IE/WIN will be able to make pixels scalable. So we definitively should talk about *functions* rather than units, and I agree with Cynthia that "scalable" is the right term to use.

Therefore I suggest to tell designers something like "Use scalable units for CSS properties that need to change: font-size and line-height" rather than "Use these units...".

Directly following that we must also clarify the use of the phrase "relative positioning": when a CSS designer hear that words he think about a CSS rule like this: #box { position: relative; } [7]. But, in itself, a positioning scheme isn't related to accessibility.

When you talk about relative positioning I think that you mean a concept like "use liquid design" rather than a specific CSS positioning scheme. It is wrong to advise designers to use a specific positioning scheme. Instead, i.e., we should tell them that a liquid design is more accessible than a fixed design, no matter which technique they use to obtain that. Obviously we must first justify this suggestion!.

These terminological problems are really serious: I've hardly discussed, here in Italy, with tricky designers that keep on using their beloved pixels for text sizing because these are relative units as checkpoint 3.4 of WCAG 1.0 suggest (no matter if partially sighted people using IE/WIN cannot resize them).

Marco Bertoni
--
Referente Regionale IWA Liguria
International Webmasters Association ITALIA
Fax Verde: 800 12.64.96 - Web Site: http://www.iwa-italy.org

[1] http://www.w3.org/TR/WCAG20/appendixD.html
[2] http://www.w3.org/TR/WCAG20/guidelines.html#visual-audio-contrast
[3] http://www.w3.org/TR/WCAG20-CSS-TECHS/#syntax-data-types
[4] http://www.w3.org/TR/CSS21/syndata.html#length-units
[5] http://www.w3.org/TR/CSS21/fonts.html#font-size-props
[6] http://www.pubbliaccesso.it/normative/DM080705-A-en.htm
[7] http://www.w3.org/TR/CSS21/visuren.html#relative-positioning

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

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

Location in reviewed document:
H55, H56

Comment:
It is not clear to us why correct support of the 'direction of the text' is an accessibility issue. We recommend that you remove all mention of text direction from this document.


This would include F5, H1, H34, H56, H55


(If you disagree with this recommendation, we will come back to you with a substantial number of additional comments based on the content of this document related to text direction, and probably recommend that i18n WG needs to be involved in drafting that text. For now we will hold all such comments until this one is addressed.)

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

Comment 2
At http://www.w3.org/International/reviews/0606-wcag2-techniques/
Editorial/substantive: S/E
Owner: RI

Location in reviewed document:
H57

Comment:
The term 'primary' is used here in a different way than currently used in i18n documents. We use 'primary language' to mean the intended audience of the document - as specified in the HTTP header or the meta statment. Our equivalent for your term 'primary language' (based on the advice given in your techniques) would be 'default text-processing language'. This is what is expressed via the language attribute(s) on the html element. (Note that we are currently considering options for replacing our use of the term 'primary language' with something less ambiguous andmore accurate.)


For a summary of our current usage see
http://www.w3.org/TR/i18n-html-tech-lang/#ri20040808.100519373 [http://www.w3.org/TR/i18n-html-tech-lang/#ri20040808.100519373]


i18n WG needs to discuss this section with WCAG WG to understand more clearly what the intent is with regard to 'primary' vs.'text-processing' language, and to help formulate clearer guidelines.

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

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

Location in reviewed document:
H57, H58, Resources

Comment:
There is a pointer to RFC 3066 'Tags for the Identification of Languages'. This specification has now been superceded by RFC3066bis, although, unfortunately, there is no number for the new RFC just yet. We suggest that you add a new link as soon as possible.


In the meantime, you may wish to point to http://www.w3.org/International/core/langtags/rfc3066bis.html

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

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

Location in reviewed document:
H57, Tests

Comment:
Step 3 should say 'conforms to RFC 3066 or its successor', since RFC 3066 is now, already out of date, and RFC 3066bis should be used. Note that hopefully it will be possible to point to its successor very soon - we are awaiting the assignment of an RFC number.

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

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

Location in reviewed document:
H57, Tests

Comment:
Step 2 should say 'a lang and/or xml:lang attribute'.

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

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

Location in reviewed document:
H58, Tests

Comment:
Please add text referring to xml:lang to the procedure.

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

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

Location in reviewed document:
H58 Tests

Comment:
Please require conformance to RFC 3066 *or its successor*, since it has already been succeeded, and change this as soon as RFC 3066bis has an RFC number.

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

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

Location in reviewed document:
H62, Examples

Comment:
"rp is used to ensure that pronunciation information shown through Ruby text is displayed by user agents that do not support Ruby annotation."

This is misleading. The ruby text is always shown - adding rp doesn't do anything other than make it clearer, for non-ruby enabled user agents, that the ruby text is ruby text and not a typo.

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

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

Location in reviewed document:
H62, Tests

Comment:
"the rp element is used to provide pronunciation information for user agents that do not support Ruby annotations"

This is misleading. It should say something like

"the rp element is used for user agents that do not support Ruby annotations to indicate that text in rt elements provides pronunciation information"

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

2.4.4 Each link is programmatically associated with text from which its purpose can be determined. (Level 2)
“The intent of this success criterion is to help users understand the purpose of each link in the content�
The intent of the criterion is not met by the use of technique H33.
Critisisms of Technique H33
“User agents will display a tool tip when the mouse hovers above an anchor element containing a title attribute.�
1. Current User agents do not provide access to title attribute content via the keyboard [1]
a. Will result in content not being accessible by non-mouse users who do not use screen reading software.
b. Contradicts the intent of Guideline 2.1 Make all functionality operable via a keyboard interface.
c. Contradicts the intent of Guideline 4.2 Ensure that content is accessible or provide an accessible alternative, because the technique does not include advice that an accessible alternative version of the content within the title attribute be provided.

2. The “tool tip� in some commonly used user agents disapears after a short period of time (approximately 5 seconds) [1]
a. Will result in difficulty accessing title attribute content for those users who can use a mouse, but have fine motor skill impairment.
b. May result in reading difficulties of title attribute content for users with cognitive/learning impairment.
c. Contradicts the intent of Guideline 2.2 Allow users to control time limits on their reading or interaction.
3. Presentation of title attribute content cannot be resized or colours changed via the user agent or by the content author.
a. The foreground and background colours of the “tool tip� cannot be modified by the user via the user agent.
b. The size of the text within a “tool tip� cannot be modifed by a user via the user agent.
c. Contradicts the intent of Guideline 1.3 Ensure that information and structure can be separated from presentation
4. The placement and location of the “tool tip� cannot be modified by users.
a. This results in some screen magnifier users being unable to access meaningful portions of the title attribute content, because the “tool tip� cannot be fully displyed within the view port [2].

Assistive technology issues
Three pieces of assistive technology are cited in the “User Agent and Assistive Technology Support Notes� [4]. Two of those cited do not provide a practical or functionally equivalent method for users to access the information within the title attribute of links.
JAWS 7.0
“JAWS 7.0 will speak either the link text or the title attribute for a link depending upon a JAWS setting. This setting can be changed temporarily or permanently within JAWS.�
Discussion
JAWS does not provide a practical or functionally equivalent method for users to hear the content of a link’s title attribute
If a user has JAWS set to read “Title text� for links they cannot access the “screen text� without changing the JAWS verbosity settings (This process involves a minimum of 7 keystrokes / keystroke combinations and in 5 out of 7 tests caused JAWS to start reading again from the top of the page, thus losing focus on the link that had a potential “title text�.).
So in Example 2 (
Table 1) of technique H33 a JAWS user with verbosity set to “use title� for links would hear
“link opens in new window�
, but would not hear
“Subscribe to email notifications about breaking news�
, nor would they be given any indication that this additional information was available and could not access the information without going through these steps:
In order for a user to change the verbosity setting for links a user must:
“press INSERT V to open the Adjust JAWS Verbosity dialog box. Select an option with the arrow keys and then press SPACEBAR or use the Execute button to cycle through the available settings. Press ENTER to accept your changes and close the dialog box. “ [3]
Conversely if the user had the default “screen text� settings they would not hear the information \"link opens in new window\" nor would they be given any indication that this additional information was available.


Table 1 H33: Supplementing link text with the title attribute - Example 2
<a href=\"http://www.newsorg.com.com/subscribe.html\" target=\"_blank\" title=\"link opens in new window\"> Subscribe to email notifications about breaking news</a>

Homepage Reader 3.04
“Home Page Reader 3.04 will speak the title attribute of any element with focus when the control-shift-F1 keys are pressed simultaneously.�
· This is not a documented feature of HPR 3.04. The documentation in reference to this states that the URL of the page will be read out (no mention of the title attribute).
· The title attribute content is read out, but after the URL of the current page is read.
· The user has no way to know that there is supplementary information available unless he/she activates the key combination. It is totally impractical to expect users to query each link to find supplementary information.

References
1. Display of the TITLE attribute in some common browsers - http://www.sf.id.au/WE05/#slide7
2. Screen Magnifier users - http://www.sf.id.au/WE05/#slide12
3. JAWS 6 documentation - JAWS 6.20 documentation [EXE file, 1.57 MB]
4. Technique H33 - Supplementing link text with the title attribute http://www.w3.org/TR/2006/WD-WCAG20-TECHS-20060427/Overview.html#H33


Proposed Change:

Remove technique H33

Item Number: H51: Using table markup to present tabular information...
Part of Item: Description
Comment Type: ED
Comment (Including rationale for any proposed change):
Using the HTML table element... - "table" not marked as "code".

...the HTML pre element... - "pre" not marked as "code".

Proposed Change:
Mark the two words as "code".

Item Number: H63: Using the scope attribute to associate header cells and data cells in data tables...
Part of Item: Applicability
Comment Type: ED
Comment (Including rationale for any proposed change):

Technique H63 says it is referenced from SC 1.3.4.

It is actually referenced from SC 1.3.1

Proposed Change:

Change reference to SC 1.3.1.

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

Typo: "#1 and #2 are true"
There is only 1 check.

Proposed Change:

#1 is true

Item Number: H34: Using a Unicode right-to-left mark (RLM) or left-to-right mark (LRM) to mix text dire...
Part of Item: Applicability
Comment Type: ED
Comment (Including rationale for any proposed change):
Says H34 is referenced from SC 1.3.1 but it is not. It is referenced from SC 1.3.3

Proposed Change:
H34 could fall under both 1.3.1 and 1.3.3.

Add link to H34 on 1.3.1 or remove from \"applicability\". Add 1.3.3 to applicability or remove link to H34 from 1.3.3.

Item Number: G18: Ensuring that luminosity contrast of at least 5:1 exists between text ...
Part of Item: Tests
Comment Type: ED
Comment (Including rationale for any proposed change):
Procedure step #4 does not exist.

Proposed Change:
Renumber the steps or change the step number.

Item Number: G17: Ensuring that luminosity contrast of at least 10:1 exists between text...
Part of Item: Tests
Comment Type: ED
Comment (Including rationale for any proposed change):
Expected results - there is no point #4

Proposed Change:
Add other points or change number.

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

A few links are outdated; a few can be added.

Proposed Change:

* Remove \'Search Engine World HTML Validation Service\' (no longer available).
* Remove \'XSD Schema Validator by GotDotNet\' (no longer available).
* Remove \'This article is also available as a single file: Working with XML.\'
* Change http://www.nvu.com/index.html to http://www.nvu.com/
* Add \'Off-line CSS Validator – A clipbook for NoteTab\' (http://www.tuke.sk/podlubny/oc.html)
* Add \'Schema Validator\' (http://www.xmlforasp.net/SchemaValidator.aspx): this is a validator that allows you to paste XML and W3C XML Schema code into text boxes to validate XML code.
* Add \'XML Nanny\' (http://www.xmlnanny.com/), a graphical tool for validating XML and XHTML, with support for DTD, W3C XML Schema, RELAX NG and Schematron (Max OX X).

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

In example 3, the double backslash in the dir attribute (and the explanation above it) should be a single forward slash.

Proposed Change:

Replace dev\\\\web (double backslash) with dev/web (single forward slash).

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

The relationship with the main WCAG document should be bi-directional, and the document should be able to "stand alone",especially if (as I was) you're working from a printed copy of the document.

Proposed Change:
Add relevant SC text to the start of each of the "Failure" sections.

Part of Item: Related Techniques
Comment Type: GE
Comment (including rationale for proposed change):
To aid navigation of hardcopy versions of the document, removing the need to keep refering to the table of contents.

Proposed Change:
Add the relevant section numbers to the internal link texts in "Related Techniques".

Comment (including rationale for any proposed change):

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

Incorrect CSS or usage

The Techniques document gives incorrect CSS in places, or simply gives unrealistic examples that don't match the practices of standards-compliant developers.

/* Rules for bidi */
HEBREW, HE-QUO {direction: rtl; unicode-bidi: embed}
ENGLISH {direction: ltr; unicode-bidi: embed}
/* Rules for presentation */
HEBREW, ENGLISH, PAR {display: block}
EMPH {font-weight: bold}

Each of those class names must begin with a dot (e.g., .HEBREW), and all-lower-case is preferred, as XML documents have [3]case-sensitive CSS parsing.

Proposed Change:

Comment (including rationale for any proposed change):

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

Procedure

1. Using a keyboard, navigate through the content.
2. Check to see that the keyboard focus is not ""trapped"" and it is possible to move keyboard focus out of the plug-in content without closing the user agent or restarting the system.

What if this depends on the user agent, as it so often does? What if nothing the author can do will ever permit the user to escape from the trapping content? (This was a real example with accessible Flash.)

Proposed Change:

Comment (including rationale for any proposed change):

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

The objective of this technique is to describe how using blank characters, such as space, tab, line break, or carriage return, to format individual words visually can be a failure to present meaningful sequences properly. Blank characters have no appearance when rendered visually

Yes, they do. They're blank!

Proposed Change:

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

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

Location in reviewed document:
H57

Comment:
This technique is titled:


Using the lang attribute of the html element


But it should make reference to the xml:lang attribute too. We suggest:


Using language attributes on the html element

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

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

Location in reviewed document:
H57, H58, Description

Comment:
"(Note that HTML only offers the use of the lang attribute, while XHTML (transitionally) allows both attributes or onlyxml:lang , respectively, since lang was removed in XHTML 1.1.)"


This would be clearer if it said


(Note that HTML only offers the use of the lang attribute, while XHTML 1.0 (as a transitional measure) allows both attributes, and XHTML 1.1 allows only xml:lang.)

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

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

Location in reviewed document:
H57, example 1

Comment:
This example, unlike the two following, omits the <head> element. It seems at best inconsistent. (Note, btw, that these examples are invalid, since the title element is required.)

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

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

Location in reviewed document:
H57, Resources

Comment:
There is a link to


Using language information in XHTML, HTML and CSS


We suspect that what you meant to link to was


Declaring Language in XHTML and HTML [http://www.w3.org/International/tutorials/language-decl/]

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

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

Location in reviewed document:
H57, Resources

Comment:
There is no mention of bidi in this technique, so we think the last two links in this section are irrelevant.

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

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

Location in reviewed document:
H58, title

Comment:
This technique is titled:

Using the lang attribute to identify changes in the natural language

But it should make reference to the xml:lang attribute too. We suggest:

Using language attributes to identify changes in the natural language

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

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

Location in reviewed document:
H58 example 1

Comment:
Is je ne sais quoi really French still?

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

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

Location in reviewed document:
H58, Resources

Comment:
This is a strange version number, and the link points to the First Edition, whereas we are up to the 3rd edition now, and soon 4th. Please point to the generic URI http://www.w3.org/TR/REC-xml/#sec-lang-tag

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

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

Location in reviewed document:
H58, Resources

Comment:
This points to an obsolete document. Please update to point to
http://www.w3.org/International/articles/language-tags/

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

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

Location in reviewed document:
H62, Descn

Comment:
Ruby text is said to be rendered "above or immediately before the base text'. The word 'before' here is a technical usage meaning above horizontal text or to the right of vertical text. This is not clear to the reader of this technique, and should be made so.


The sentence "A Ruby annotation that gives the meaning of the base text usually follows the base text" is also not clear. It should say that sometimes Japanese uses ruby related to the meaning of text on the other side of the base text (visually) from the phonetic annotation.

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

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

Location in reviewed document:
H62, Examples

Comment:
Examples 1 and 2 should have rp tags. There is no good reason to leave them out. This will just set a bad example.


This comment, of course, affects Example 3 also.

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

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

Location in reviewed document:
H62, Desc

Comment:
"Ruby annotation is unnecessary in languages such as Hebrew, where Unicode fonts can include diacritical marks that convey pronunciation. It is also unnecessary in English and European languages."


Note that Ruby provides for annotations that can equally well be used in non-Asian text. We suggest "Ruby annotation is uncommon in languages such as ".


(Note that the term Ruby derives from *English* typesetting practise.) (Note also that you actually include an example of Ruby used with English a little further down the page.)

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

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

Location in reviewed document:
H62, Resources

Comment:
There are resources dedicated to Ruby on the i18n subsite. We are not sure why you don't link to them. eg. see links from
http://www.w3.org/International/techniques/markup#ruby .