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
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: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Ben Caldwell
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter'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: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Ben Caldwell
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter'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: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Ben Caldwell
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter'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: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter'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: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Ben Caldwell
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter'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: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Ben Caldwell
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter'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: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Ben Caldwell
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter'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: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter'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: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter'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: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Becky Gibson
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter'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: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter'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: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter'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: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter'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: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter'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: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter'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: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter'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: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter'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: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Nobody
Abma, Jake
Abou-Zahra, Shadi
Allan, Jim
Auclair, Christopher
Avila, Jonathan
Babinszki, Tom
Bailey, Bruce
Bernard, Renaldo
Bernier, Alex
Blake, Matthew
Boudreau, Denis
Brewer, Judy
Butler, Shari
Campbell, Alastair
Carlson, Laura
Chakravarthula, Srinivasu
Cirrincione, Pietro
Conway, Vivienne
Cooper, Michael
Crutchfield, Elizabeth
Deltour, Romain
Dick, Wayne
Ding, Chaohai
Dirks, Kim
Dixit, Shwetank
Draffan, E.A.
Duggin, Alistair
Eggert, Eric
Elledge, Michael
Faulkner, Steve
Ferraz, Reinaldo
Fiers, Wilco
Fischer, Detlev
Foliot, John
Garrish, Matt
Garrison, Alistair
Gower, Michael
Guarino Reid, Loretta
Hakkinen, Markku
Haritos-Shea, Katie
Henry, Shawn
Hoffmann, Thomas
Horton, Sarah
Isager, Kasper
Jensen, Tobias Christian
Johansson, Stefan
Johlic, Marc
Johnson, Rick
Jones, Crystal
Joys Andersen, Wilhelm
Kapoor, Shilpi
Keim, Oliver
Kirkpatrick, Andrew
Kirkwood, John
Kiss, Jason
Kraft, Maureen
Ku, JaEun
Kurapati, Sujasree
Lauke, Patrick
Lauriat, Shawn
Lee, Steve
Lemon, Gez
Li, Alex
Li, Kepeng
Li, Liangcheng
Loiselle, Chris
Lowney, Greg
Lui, Edwina
Lund, Adam
Ma, Jia
MacDonald, David
Mace, Amanda
Manser, Erich
Martin, Debra
McCormack, Scott
McMeeking, Chris
McSorley, Jan
Milliken, Neil
Montgomery, Rachael
Mueller, Mary Jo
nicole, windmann
Niemann, Gundula
Nurthen, James
O Connor, Joshue
Oh, Jeong-Hun
Panchang, Sailesh
Pandhi, Charu
Pasi, Aparna
Patch, Kimberly
Philipp, Melanie
Pluke, Mike
Pouncey, Ian
Repsher, Stephen
Rochford, John
Runyan, Marla
Savva, Andreas
Sawczyn, Steve
Schnabel, Stefan
Seeman-Kestenbaum, Lisa
Sims, Glenda
Singh, Avneesh
Skotkjerra, Stein Erik
Sloan, David
Smith, Alan
Smith, Jim
Solomon, Adam
Spellman, Jeanne F
Strobbe, Christophe
Suprock, Greg
Swallow, David
Thompson, Kenneth
Thyme, Anne
Ueki, Makoto
Vaishnav, Jatin
Vanderheiden, Gregg
Venkata, Manoj
Wahlbin, Kathleen
Wang, Can
WANG, WEI
White, Jason
Zelmanowicz, Erica
Zerner, Adam
Zhang, Mengni
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter'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: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter'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 .