List of comments on “Techniques for WCAG 2.0” (dated 27 April 2006)

There are 94 comments (sorted by their types, and the section they are about).

1-20 21-40 41-60 61-80 81-94

question comments

Comment LC-776: Commenter: Joe Clark 3 <joeclark@joeclark.org> (archived message); Context: F10: Failure of SC 2.1.1 due to combining multiple content formats in a waythat traps users inside one format type; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
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:; Related issues: (space separated ids); WG Notes: [TEAMA]; Resolution: If there's nothing an author can do to prevent this behavior, then the content will fail this success criterion and can not meet WCAG 2.0.; (Please make sure the resolution is adapted for public consumption)

typo comments

Comment LC-524: > H34 is referenced from SC 1.3.1 but it is not.: Commenter: Chris Ridpath <chris.ridpath@utoronto.ca> on behalf of ATRC University of Toronto (archived message); Context: Document as a whole (applicability); Status:
assigned to Ben Caldwell; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
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.; Related issues: (space separated ids); WG Notes: [BEN] Fixed. Updated XML source 14 June 2006.; Resolution: The technique has been updated to reference SC 1.3.2 (formerly 1.3.3).; (Please make sure the resolution is adapted for public consumption)

Comment LC-553: > G18 expected results numbering typo: Commenter: Chris Ridpath <chris.ridpath@utoronto.ca> on behalf of ATRC University of Toronto (archived message); Context: Document as a whole (Tests); Status:
assigned to Ben Caldwell; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
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.; Related issues: (space separated ids); WG Notes: [BEN] Fixed. Updated XML source 14 June 2006. The number was correct, but two of the items in the procedure section were incorrectly coded as paragraphs instead of list items.; Resolution: The procedure section has been updated to include the correct number of steps.; (Please make sure the resolution is adapted for public consumption)

Comment LC-554: > G17 Procedure Numbering: Commenter: Chris Ridpath <chris.ridpath@utoronto.ca> on behalf of ATRC University of Toronto (archived message); Context: Document as a whole (Tests); Status:
assigned to Ben Caldwell; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
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.; Related issues: (space separated ids); WG Notes: [BEN] Fixed. Updated XML source 14 June 2006. The number was correct, but two of the items in the procedure section were incorrectly coded as paragraphs instead of list items.; Resolution: The procedure section has been updated to include the correct number of steps.; (Please make sure the resolution is adapted for public consumption)

Comment LC-765: Commenter: Joe Clark 3 <joeclark@joeclark.org> (archived message); Context: Document as a whole; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
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:; Related issues: (space separated ids); WG Notes: [BEN] Fixed. Updated XML source 15 June 2006.; Resolution: The syntax errors have been removed.; (Please make sure the resolution is adapted for public consumption)

Comment LC-468: > Missing code markup: Commenter: Chris Ridpath <chris.ridpath@utoronto.ca> on behalf of ATRC University of Toronto (archived message); Context: Document as a whole; Status:
assigned to Ben Caldwell; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
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".; Related issues: (space separated ids); WG Notes: [BEN] Fixed. Updated XML Source 14 June 2006. Revisions will be published with next draft.; Resolution: Thanks. The missing code elements have been added as proposed.; (Please make sure the resolution is adapted for public consumption)

Comment LC-477: > H63 Reference Typo: Commenter: Chris Ridpath <chris.ridpath@utoronto.ca> on behalf of ATRC University of Toronto (archived message); Context: Document as a whole (Applicability); Status:
assigned to Ben Caldwell; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
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.; Related issues: (space separated ids); WG Notes: [BEN] Fixed. Updated XML Source 14 June 2006. Revisions will be published with next draft.; Resolution: Thanks. The reference has been updated as proposed.; (Please make sure the resolution is adapted for public consumption)

Comment LC-522: > G95 Test Typo: Commenter: Chris Ridpath <chris.ridpath@utoronto.ca> (archived message); Context: Document as a whole (Tests); Status:
assigned to Ben Caldwell; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
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; Related issues: (space separated ids); WG Notes: [BEN] Fixed. Updated XML source 14 June 2006.; Resolution: The technique has been updated as proposed.; (Please make sure the resolution is adapted for public consumption)

Comment LC-1519: Commenter: Christophe Strobbe <christophe.strobbe@esat.kuleuven.be> on behalf of DocArch, Katholieke Universiteit Leuven (archived message); Context: G134: Validating Web units (Examples); Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
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).; Related issues: (space separated ids); WG Notes: [BEN] Internal WD updated 23 April 2007 Response: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0007.html; Resolution: Done.; (Please make sure the resolution is adapted for public consumption)

substantive comments

Comment LC-1383: Commenter: Richard Ishida <ishida@w3.org> on behalf of I18N WG (archived message); Context: Document as a whole (H55 and H56); Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
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.); Related issues: (space separated ids); WG Notes: [TEAMB] This is a good point - direction seems critical to rendering, not accessibility. Problems occur when the reading order of the text is compromised when incorrect mechanisms are used to achieve visual rendering. We should keep techniques that address 1.3.3 problems, but remove references to directionality from 3.1.2 Discussed in the 20 July 2006 telecon: Resolution: accept LC-1383 as proposed. http://www.w3.org/2006/07/20-wai-wcag-minutes.html {Partial accept} DONE Other edits: - Delete technique H1: Adding the dir attribute to a block level element to change its directionality (also find all references to this technique and delete them) - Delete technique H55: Using the dir attribute of the html element (also find all references to this technique and delete them) - delete F5: Failure of SC 3.1.1 due to using CSS styling to control directionality in XHTML/HTML (also find all references to this technique and delete them) - remove SC 3.1.2 from referenced SC list for techniques H34, H56 DONE Modifications to How to Meet SC 1.3.3 - Remove "Adding the dir attribute to a block level element to change its directionality" from HTML techniques - Remove advisory CSS technique "Specifying the direction of text" - Remove "and the direction is identified as right-to-left" from Example 2 DONE Modifications to How to Meet SC 3.1.1 - Remove the second paragraph of the Intent Section - Remove Situation A and Situation B , keeping the Situation A sufficient technique as the only sufficient technique for SC 3.1.1. - Remove the section and technique for identifying text direction in HTML - Remove the advisory CSS technique - Remove Example 2 - Remove the common failure Internal WD updated 21 August. (note that some deletions are not shown in diff-marked version) Response: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0025.html; Resolution: Thank you for pointing out that the direction of text is not an accessibility issue. As long as the text itself is presented in reading order, text direction just affects the rendering. We are removing general requirements for indicating the direction of text, but retaining several techniques for SC 1.3.3, to ensure that the reading order of the text is not compromised to achieve the desired visual effect. We would welcome collaboration from i18n on those portions of the document. We made the following modifications to How to Meet SC 3.1.1 - Removed the second paragraph of the Intent Section - Removed Situation A and Situation B , keeping the Situation A sufficient technique as the only sufficient technique for SC 3.1.1. - Removed the section and technique for identifying text direction in HTML - Removed the advisory CSS technique - Removed Example 2 - Removed the common failure We made the following modifications to How to Meet SC 1.3.3 - Removed "Adding the dir attribute to a block level element to change its directionality" from HTML techniques - Removed advisory CSS technique "Specifying the direction of text" - Removed "and the direction is identified as right-to-left" from Example 2 We have also incorporated the following edits: - Deleted technique H1: Adding the dir attribute to a block level element to change its directionality - Deleted technique H55: Using the dir attribute of the html element - deleted F5: Failure of SC 3.1.1 due to using CSS styling to control directionality in XHTML/HTML - removed SC 3.1.2 from referenced SC list for techniques H34, H56; (Please make sure the resolution is adapted for public consumption)

Comment LC-665: Commenter: Chris Ridpath <chris.ridpath@utoronto.ca> on behalf of ATRC University of Toronto (archived message); Context: (none selected) in (Applicability); Status:
assigned to Becky Gibson; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
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.; Related issues: (space separated ids); WG Notes: [TEAMC] Words in images is covered by example 1 in technique H37, "Using alt attributes on img elements." Unless the group feels that we need a technique with a title that relates to images of text, I think the scenario is already covered. July 17 - updated per suggestion from Michael to add more explicit text about putting the (important) text in images into the alt text. Discussed in the 20 July 2006 telecon: Resolution: refer LC-665 back to team C to update the description of G94 and H57 to explain that the alt text for non-text content for words must be those same words. http://www.w3.org/2006/07/20-wai-wcag-minutes.html July 21: Append the following to the description of H37 "When an image contains words that are important to understanding the content, the alt text should include those words. This will allow the alt text to play the same function on the page as the image. Note that it does not necessarily describe the visual characteristics of the image itself but must convey the same meaning as the image." Add the following after the fourth sentence in the first paragraph of the description of G94, "When non-text content contains words that are important to understanding the content, the alt text should include those words." Modify the example 1 text of H37 to:"An image on a website provides a link to a free newsletter. The image contains the text "Free newsletter. Get free recipes, news, and more. Learn more." The alt text matches the text in the image." Updated the test procedure for G94 and H37. See full set of proposed changes in response below. Discussed in the 27 July 2006 telecon: resolution: accept LC-665 as amended realtime by Becky http://www.w3.org/WAI/GL/2006/07/27-wai-wcag-minutes.html DONE add the following to the description of H37: When an image contains words that are important to understanding the content, the alt text should include those words. This will allow the alt text to play the same function on the page as the image. Note that it does not necessarily describe the visual characteristics of the image itself but must convey the same meaning as the image. If the text in the image is more than can fit in a short text alternative then it should be described in the short text alternative and a longdesc should be provided as well with the complete text. DONE update example1 in H37 to: Example 1. An image on a website provides a link to a free newsletter. The image contains the text "Free newsletter. Get free recipes, news, and more. Learn more." The alt text matches the text in the image. DONE add the following test procedure to H37: We will also add the following test procedure to H37: 1. Examine each img element in the content 2. Check that each img element which conveys meaning contains an alt attribute. 3. If the image contains words that are important to understanding the content, the words are included in the text alternative. DONE add the following expected results to H37: Check #2 is true. If the non-text content contains words that are important to understanding the content, Check #3 is also true. DONE add to description of G94: "When non-text content contains words that are important to understanding the content, the alt text should include those words. If the text in the image is more than can fit in a short text alternative then it should be described in the short text alternative and a long text alternative should be provided as well with the complete text." DONE add example to G94: A heading contains a picture of the words, "The History of War" in stylized text. The alt text for the picture is "The History of War". DONE add to the test procedure of G94: 4. If the non-text content contains words that are important to understanding the content, the words are included in the text alternative. DONE update the Expected results of G94 to: Step 3 is true. If the non-text content contains words that are important to understanding the content, Step 4 is also true. Internal Draft updated 10 August.; Resolution: The working group believes that the technique you are requesting is covered by example 1 of technique H37 and thus, there does not need to be a specific technique covering words in images. However, we have updated techniques H37 and G94. We have added the following to the description of H37: When an image contains words that are important to understanding the content, the alt text should include those words. This will allow the alt text to play the same function on the page as the image. Note that it does not necessarily describe the visual characteristics of the image itself but must convey the same meaning as the image. If the text in the image is more than can fit in a short text alternative then it should be described in the short text alternative and a longdesc should be provided as well with the complete text. We have updated example 1 in H37 to: Example 1. An image on a website provides a link to a free newsletter. The image contains the text "Free newsletter. Get free recipes, news, and more. Learn more." The alt text matches the text in the image. We have also added the following test procedure to H37: 1. Examine each img element in the content 2. Check that each img element which conveys meaning contains an alt attribute. 3. If the image contains words that are important to understanding the content, the words are included in the text alternative. We added the following expected results to H37: Check #2 is true. If the non-text content contains words that are important to understanding the content, Check #3 is also true. We also added the following to the description of G94: "When non-text content contains words that are important to understanding the content, the alt text should include those words. If the text in the image is more than can fit in a short text alternative then it should be described in the short text alternative and a long text alternative should be provided as well with the complete text." We added the following example to G94: A heading contains a picture of the words, "The History of War" in stylized text. The alt text for the picture is "The History of War". We added the following item to the test procedure of G94: 4. If the non-text content contains words that are important to understanding the content, the words are included in the text alternative. We have updated the Expected results of G94 to: Step 3 is true. If the non-text content contains words that are important to understanding the content, Step 4 is also true.; (Please make sure the resolution is adapted for public consumption)

Comment LC-775: Commenter: Joe Clark 3 <joeclark@joeclark.org> (archived message); Context: Document as a whole; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
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:; Related issues: (space separated ids); WG Notes: [TEAMA] Discussed 29 June 2006 resoution: 829, 775, 723 accept because they were unanamous in the surveys http://www.w3.org/2006/06/29-wai-wcag-minutes.html; Resolution: They can't. These are some tests that have to be done by people with particular skills and abilities. That does not affect the accessibility of the content. (This also happens in other areas as well. For example, a blind person cannot tell if there is meaningful content that has been marked decorative either.); (Please make sure the resolution is adapted for public consumption)

Comment LC-666: TEST-TASK-FORCE: Commenter: Chris Ridpath <chris.ridpath@utoronto.ca> on behalf of ATRC University of Toronto (archived message); Context: Document as a whole (Applicability); Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
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.; Related issues: (space separated ids); WG Notes: [EDITORZ] Discussed in the 13 July 2006 telecon: resolution: accept LC-666 as proposed http://www.w3.org/2006/07/13-wai-wcag-minutes.html; Resolution: Each of the techniques has a test procedure and an expected result from the procedure. We have test files (actually example files for pass and failure) for some of the techniques, most of which came from the location you cited http://www.w3.org/WAI/GL/WCAG20/tests/ There is now a joint task force with ERT WG that will be working on identifying or developing sample files for the other techniques.; (Please make sure the resolution is adapted for public consumption)

Comment LC-764: Text-Alternatives: Commenter: Joe Clark 3 <joeclark@joeclark.org> (archived message); Context: F38, F39, H67 in (F38, F39, H67); Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
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:; Related issues: (space separated ids); WG Notes: [TEAMC] [] H67 was discussed at the 9 March 2006 telecon. F38 was surveyed for 26 January teleconference (http://www.w3.org/2002/09/wbs/35422/2006-01-26-text-equiv/results#xnotnull) but I can see no record that it was discussed so I suspect it was referred back to Team A. John raised an objection to alt=" " in the survey. In the wiki page on this technique (http://tinyurl.com/got59), John's comment isn't even mentioned. The edited technique was surveyed again on 16 March (http://tinyurl.com/ya3szs) and John accepted it without changes. F39 was discussed at the 30 March 2006 telecon and accepted with edits. Looking for the survey. Discussed in the 08 February 2007 telecon: Resolution: LC-764 closed with unanimous consent http://www.w3.org/WAI/GL/2007/02/08-wai-wcag-minutes.html; Resolution: Yes, whitespace alt is permitted because there are situations in which it is desirable to have a space in the text version of the Web page where the image is located, for instance to act as a separator between words that in some designs would otherwise run together in the text version. To our knowledge, assistive technologies treat whitespace and null alternative text equivalently, and this is known to be a widespread practice that we do not have the justification to limit. However, we do recommend the use of null alt text preferentially, which is mentioned in the applicable techniques H67, F38 and F39.; (Please make sure the resolution is adapted for public consumption)

Comment LC-557: AT-Push link-text title-attribute: Commenter: Steven Faulkner <steven.faulkner@nils.org.au> (archived message); Context: Document as a whole (Applicability); Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
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; Related issues: 1108
(space separated ids); WG Notes: [TEAMB] [] Related comments: 497 573 576 473 Discussed at Team B meeting on 6-27-2006. Decide to incorporate comments from Team B Survey results of June 22 (http://www.w3.org/2002/09/wbs/35422/teamb062206/results) into the database. Discussed at WCAG full meeting on 6-29-2006. OUTCOME from July 29 Full WCAG Discussion: Make it AT Push (new key word). Put on hold. Discussed in the 19 October 2006 telecon: resolution: accept LC-557 and LC-1108 as amended http://www.w3.org/WAI/GL/2006/10/19-wai-wcag-minutes.html {not-accept? partial accept?} DONE See changes in wiki: http://trace.wisc.edu/wcag_wiki/index.php?title=Supplementing_link_text_with_the_title_attribute Internal WD updated 02 Nobember.; Resolution: We have added the information you provided to the list of user agent notes for this technique. The working group would like to see better user agent support for the title attribute, but feels that this should reamain a sufficient technique while efforts to improve user agent and assistive technology support are made. It has been made an advisory technique for SC 2.4.8, since the link text itself must be sufficiently descriptive without depending upon the title attribute content to meet that criterion. Because title attributes should only be used for supplementary information, we have added a sentence to the Intent section "If the supplementary information provided through the title attribute is something the user should know before following the link, such as a warning, then it should be provided in the link text rather than in the title attribute." We also included a Failure Example where the title attribute contains non-supplementary information about the link.; (Please make sure the resolution is adapted for public consumption)

Comment LC-555: Commenter: John Thomson <john@shal.org> (archived message); Context: Document as a whole (Applicability); Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
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".; Related issues: (space separated ids); WG Notes: [EDITORZ] GV BC DONE Change title to "Techniques and Failures for WCAG 2.0" 17-may-2007: just discovered we can't change title without director's permission. Adding subtitle instead.; Resolution: We have added the subtitle "Techniques and Failures for WEb Content Accessibility Guidelines 2.0".; (Please make sure the resolution is adapted for public consumption)

Comment LC-523: > H1 could fall under both 1.3.1 and 1.3.3: Commenter: Chris Ridpath <chris.ridpath@utoronto.ca> on behalf of ATRC University of Toronto (archived message); Context: Document as a whole (applicability); Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
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.; Related issues: (space separated ids); WG Notes: [TEAMB] BBC: Fixed reference so that H1 now links to 1.3.3 and updated XML source (14 June 2006). Updated type to substantive and assigned to Team B to consider the question of whether this should also be referenced from 1.3.1. LGR: Based on the resolution to 1383, text direction is only an issue if it affects 1.3.3. Discussed in the 27 July 2006 telecon: accepted by unanimous consent http://www.w3.org/WAI/GL/2006/07/27-wai-wcag-minutes.html {partial accept}; Resolution: Thank you for catching this error. After reviewing comments from the Internationalization Working Group, we believe the direction of text is only an accessibility issue when it affects the proper sequencing of mixed-direction text, so we have deleted this technique.; (Please make sure the resolution is adapted for public consumption)

Comment LC-1391: Commenter: Richard Ishida <ishida@w3.org> on behalf of I18N WG (archived message); Context: Document as a whole (Tests); Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
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.; Related issues: (space separated ids); WG Notes: [TEAMB] Reviewed at July 18, 2006 Team B meeting; send to survey. Discussed in the 20 July 2006 telecon: Accepted by unanimous consent. http://www.w3.org/2006/07/20-wai-wcag-minutes.html {Accept} DONE Change Step 3 of the test to say 'conforms to RFC 3066 or its successor' Internal WD updated 28 August.; Resolution: We agree with this suggestion and have updated the reference to refer to RFC 4646 or its successor.; (Please make sure the resolution is adapted for public consumption)

Comment LC-521: CONTRAST: Commenter: Liz Danaherliz <danaher@dwpdevelopment.net> (archived message); Context: Document as a whole (Related Techniques); Status:
assigned to; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
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); Related issues: (space separated ids); WG Notes: [TEAMA] http://trace.wisc.edu/docs/luminosity-contrast-ratio-examples/ {partially accept} "The color contrast measure that you cite in your comments is different than the color contrast specified in the current WCAG 2.0. If you look at How to meet 1.4.1, there are tools listed in the resource section that will evaluate content using the new success criteria. Even though you used the wrong measure, your comment still is valid. he page you cite would fail the WCAG 2.0 criteria as well. The W3C is examining its pages now that the new guidelines are in last call and changes are anticipated". Discussed in the 08 March 2007 telecon: resolution: accepted as proposed http://www.w3.org/WAI/GL/2007/03/08-wai-wcag-minutes.html; Resolution: The color contrast measure that you cite in your comments is different than the color contrast specified in the current WCAG 2.0. If you look at How to meet 1.4.1, there are tools listed in the resource section that will evaluate content using the new success criteria. Despite the changes to the algorithm, your comment is still is valid and some of the text on the w3.org home page would fail the WCAG 2.0 contrast criteria. Our hope is that these pages will be updated once the new contrast requirements become a recommendation.; (Please make sure the resolution is adapted for public consumption)

Comment LC-1050: FONT: Commenter: Marco Bertoni <mbertoni@webaccessibile.org> (archived message); Context: Document as a whole (clarifications about the terms "relative", "absolute" and "relative positioning"); Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
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; Related issues: (space separated ids); WG Notes: [TEAMB] Discussed in the 25 January 2007 telecon: accepted by unanimous consent http://www.w3.org/WAI/GL/2007/01/25-wai-wcag-minutes.html {accept} SEE LC-469 http://lists.w3.org/Archives/Public/public-comments-wcag20/2007May/0161.html http://lists.w3.org/Archives/Public/public-comments-wcag20/2007May/0164.html http://lists.w3.org/Archives/Public/public-comments-wcag20/2007May/0165.html http://lists.w3.org/Archives/Public/public-comments-wcag20/2007May/0166.html; Resolution: Although text resizing is primarily a user agent function, we have added new success criteria to address the author's responsibility for supporting text resizing: Level AA: Visually rendered text can be resized without assistive technology up to 200 percent and down to 50 percent without loss of content or functionality. Level AAA: Visually rendered text can be resized without assistive technology up to 200 percent and down to 50 percent without loss of content or functionality and in a way that does not require the user to scroll horizontally.; (Please make sure the resolution is adapted for public consumption)

1-20 21-40 41-60 61-80 81-94

Add a comment.