Prepared 23 August 2006 by Bruce Bailey.
Synopsis. Paraphrasing. Opinion. Comments.
There are 3 specifically identified keyword issues, 7 general hits. Of the three, all have been assigned to Team B. the sort term “title-attribute” never stands on its own and appear once with “AT-Push” and once with “link-text” and once with both.
All three commenters are pointing out problems with reliance on the title attribute.
The other four mention the title attribute only tangentially.
User Agents do not handle the title attribute in a consistent fashion. Reliance on title as a sufficient technique may mislead content providers as to its utility. Steve Faulkner in LC-557 below details several inconstancies and possible contradictions to underlying principles.
Roger Hudson (LC-473) asks that SC 2.4.4 be re-written to require unambiguous link text and that the title attribute not be a sufficient on its own. Gian Sampson-Wild (LC-1108) asks that at least be explicitly noted that the attribute is not supported on a variety of assistive technology.
Unambiguous link text is required by Level 3 SC 2.4.8.
Move H33 from sufficient to advisory techniques for Level 2 SC 2.4.4.
Not represented in this sample are the number of people, probably in the majority, who think using the title attribute is a best practice.
It must be noted that we require title for frame and web pages (Level 2 SC 2.4.3, “Web Units have titles.”) Screen reader support for the attribute was poor when WCAG 1.0 came out (hence the confusion between frame names and titles) but has consistently improved.
We also cite title as a sufficiency technique for Level 1 SC 1.3.1 (H44). Making the technique advisory will leave us without a means to permit form elements to be used in data tables (but I am working on that separately).
It is reasonable to anticipate that UA (both browser and AT) support for title attribute will improve.
On the other hand, there is no compelling argument that the majority combination (IE+JAWS) is exhibiting correct (per the specification) behavior, and therefore no unambiguous reason why its features should be expected or endorsed by WCAG 2.0. It came up in discussion on a recent call that the Mozilla folks are dogmatic that exposing an available title attribute on images in the absence of alt would be a fundamental error. I understand from a WindowEyes beta tester that GW Micro has no plans to support exposing the title attribute on form elements.
Can this be deferred to baseline? That is, if WindowsEyes is in the baseline, then techniques relying on title attribute behavior would not be sufficient.
Clarifying that the the technique is not supported on a variety of assistive technology seems non controversial.
My recommendation is to leave the SC and associated techniques as they are and not adjust any Levels associated with them. We should add information about the current implementation limitations associated with many UA combinations.
Listed here by number, first where title-attribute appears as keyword, then only in body text. Full comments follow, as generated by the Long Format of the Issuing Tracking database. Highlighting has been added using a mechanism conformant with WCAG 1.0 Checkpoint 2.1 and all SC associated with WCAG 2.0 Guideline 1.3, but remains functionally useless to screen reader users. (Which just goes to show that maybe relying upon the title attribute is okay. AT has other ways to improve!)
7 results found.
Sort Terms: link-text title-attribute
Document: WCAG 2.0 Guidelines
Submitter: Roger Hudson <rhudson@usability.com.au>
Comment Type: substantive
Location:
Comment:
Item Number: Success Criterion 2.4.4
Part of Item:
Comment Type: GE
Comment (Including rationale for any proposed change):
Although the wording of SC 2.4.4 is convoluted, it is presumably a replacement for WCAG 1.0, Checkpoint 13.1 "Clearly identify the target of each link [Priority 2]". However 13.1 also required the link text to meaningful enough to make sense when read out of context, either on their own or as a sequence of links, and this does not appear to be the case with SC 2.4.4.
In my experience, many screen reader users extensively use the screen-reader facility that enables them to obtain a list of links on a page. This is often the preferred technique when looking for information on a site or undertaking a task, and in virtually all situations it is only effective when the link text indicates the link destination. While I believe it is possible with some screen readers to select an option that provides context from the surrounding text I have never seen this done. However, many times I have seen screen reader users become frustrated with links that contain only the words "more", "next" or "click here".
I believe it is very important for link text to provide a clear indication of the link destination. Also, the link text should make sense without the need to rely on surrounding contextual information or a title attribute within the link element.
Proposed Change:
I believe 2.4.4 should remain a level 2 SC, but should be rewritten to read, "The target or destination of each link should be clearly indicated by the link text."
Status: open
Working Group Notes: [TEAMB] [SM] [HOLD] "It is covered by 2.4.8, which is Level 3." (2.4.8 The purpose of each link can be programmatically determined from the link. [How to meet 2.4.8] )
Resolution Working Notes - Unapproved:
Related Issues:
LC-712
Assigned To: Nobody
Last Edited: 20060814215655
Sort Terms: AT-Push link-text title-attribute
Document: Techniques Document
Submitter: steve faulkner <steven.faulkner@nils.org.au>
Comment Type: substantive
Location: (Applicability)
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
Status: open
Working Group Notes: [TEAMB] [HOLD]
This may be related to 2.4.4 vs 2.4.8. Should discuss whether the title attribute should be advisory for both.
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.
Because of Ben Caldwell's comments to Keep Open, decided to move to HOLD and add to user_agent keyword.
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.
Resolution Working Notes - Unapproved:
{accept}
@@ Move H33 from sufficient to advisory techniques for 2.4.4
@@ Response to Commenter:
Although the title attribute provides a mechanism for supplementing link text, as you point out, current user agent support does not provide an effective way of accessing this information. We have made this an advisory technique so that authors do not rely on it.
Related Issues:
1108
Assigned To: Nobody
Last Edited: 20060814215740
Sort Terms: link-text
Document: WCAG 2.0 Guidelines
Submitter: Jim Thatcher <jim@jimthatcher.com> Affiliation: JimThatcher.com
Comment Type: substantive
Location: accessible-alternatives-plugins
Comment:
Part of Item:
Comment Type: GE
Comment (including rationale for proposed change):
I had a talk with John Slatin about 4.2.2 on 5.21.2006. It is clear that what he was looking for:
\"The goal was to permit the user to explore the context without needing to navigate away from the link.\"
This is an admirable and very understandable user goal.
But I think it is impossible to build this requirement build into a success criterion. Using a phrase like “Programmatically associated” without defining it – doesn’t solve the problem.
Screen Reader/2 for OS/2 had a key command that allowed the user to “save the current state” do any other command, and return to the saved state when that completed or was stopped. So the goal of allowing the user to explore the context is AT specific, which you mentioned, Loretta. The point is that there is nothing structural about that exploration. Nothing related to the current link. You could “push the state, and read “line” 123 and be back where you were. You could read the whole page and be back at your link.
John Slatin mentioned http://slashdot.com as an example. In this case the context is the text above, not a paragraph; good context is the previous heading. But with current AT – I think –you can’t read the previous heading without loosing your place – or the previous paragraph. There are several different situations on Slashdot.com where generic links relate to a previous text which is not a paragraph tag – just a div.
However, with Slashdot (as John pointed out in our conversation), when you move to the Read more link from the JAWS links list JAWS announces the heading which is the (or a) context for the link – that’s cool. Furthermore, even though JAWS isn’t as sophisticated as Screen Reader/2 (!) you can accomplish the same kind of thing with PlaceMarkers. When you are on the link, press CTRL K to set a temporary place marker, Press SHIFT H for previous heading, Press K to return to the PlaceMarker, and you are back at the link. So the context is read without loosing your place.
One of my favorite examples of this problem area is the Priceline.com hotel listing - http://tinyurl.com/qh9o2.
There is a framed block for each hotel, of maybe 30 hotels. Each hotel block has 7 generic links, Choose, More, Features, etc., all concern the hotel at the top of the block. Priceline uses the title attributes to resolve this but we all know how well that is supported – the issue here is not about the title attributes – The issue is that there is no sensible “Programmatic association” of the hotel title to the generic links. For each generic link there is a (different) technique for accessing the hotel name – using a PlaceMarker. For Choose, use next table cell (CTRL ALT RIGHT ARROW). For More, Features, ... Map, use current table cell,(CTRL ALT UP ARROW), For the last link go up two cells. Combine these with the CTRL K and K combination, and one is able to explore context with out loosing the link.
The reason I am saying all this is I believe that there is nothing special about these examples. I think it is always going to be possible to find a combination of keys that will provide context for a “generic link.” And I think there will be no general sequence that will work in all or even many cases. (How about setting a place marker and moving back (up arrow) in the document? It fails for the Choose link in the Priceline example.)
In the same way as the Priceline and Slashdot examples, the first and third Examples of Success Criterion 2.4.4 don’t necessarily have any programmatic connection to the link itself. The important information could just be in a div – not the same paragraph, maybe not the same table cell. But WCAG 2.0 calls these success!
I think that 2.4.4 should be eliminated because there is no definition of what is wanted, and I think what is wanted will always be available anyway.
Proposed Change:
Remove SC 2.4.4.
Status: open
Working Group Notes: [TEAMB] [HOLD]
Resolution Working Notes - Unapproved:
Related Issues:
Assigned To: Nobody
Last Edited: 20060814215800
Sort Terms: title-attribute AT-Push
Document: Understanding WCAG 2.0
Submitter: Gian Sampson-Wild <gian@tkh.com.au>
Comment Type: substantive
Location: navigation-mechanisms-refs (Techniques)
Comment:
title attribute: Recent research has discovered that screen readers differ in how they read the title attribute and some assistive technologies, such as magnifiers usually can't access the information at all.
Proposed Change:
Remove the title attribute technique or specify that it is not supported on a variety of assistive technology
Status: open
Working Group Notes: [TEAMB][HOLD]
Resolution Working Notes - Unapproved:
Related Issues:
557
Assigned To: Nobody
Last Edited: 20060728201433
Sort Terms: popup windows
Document: Techniques Document
Submitter: Joe Clark <joeclark@joeclark.org>
Comment Type: substantive
Location: F22
Comment:
Comment (including rationale for any proposed change):
From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0121
A user clicks on a link, and a new window appears. The original link has no associated text saying that it will open a new window. [...] Check if elements that open new windows have associated text saying that will happen. The text can be displayed in the link, or available through a hidden association such as an HTML title attribute.
target="_blank" is programmatically determinable and it is up to the user agent to warn the user. JavaScript is another story and should be addressed by the Techniques.
Proposed Change:
Status: Proposal from team to be surveyed (proposal).
Working Group Notes: [TEAMB] [BB]
Most readable version of comment can be found at URL:
http://joeclark.org/access/webaccess/WCAG/response1_Techniques-WCAG2.html#h2-480
Joe is correct that target="_blank" is programmatically determinable, but that is tangental. The SC wording is more broad: “Changes of context are initiated only by user request”. It does not follow that because a (properly configured) UA *could* warn the user of the authors intended change of context that this is sufficient to give authors a pass on this SC. It should be noted that the most popular browser has only recently added this feature, and it is still not an option for IE under Win2K.
On the other hand, we do not currently require scaleable fonts (even at Level 3, but it is an advisory technique), and the rational behind that decision is that robustly adjusting font size is a UA feature.
Response below is terse since opening and closing pleasantries will be added when the full range of concerns raised in the one comment are addressed.
Resolution Proposed by Individual or Small Group:
Response:
You are correct that target="_blank" is programmatically determinable, but the working group does not feel that it is sufficient for a content provider to rely on this feature to satisfy SC 3.2.5. It is intentional that WCAG 2.0 bans all popup windows without explicit alert beforehand at Level 3.
Related Issues:
Assigned To: Nobody
Last Edited: 20060817154543
Sort Terms: Labels
Document: Understanding WCAG 2.0
Submitter: Johannes Koch <koch@w3development.de> Affiliation: Evaluation tool developer
Comment Type: substantive
Location: (Common Failures)
Comment:
Part of Item: Common Failures
Comment Type: TE
Comment (including rationale for proposed change):
While there are two HTML techniques about labeling form controls--\"H44 (Using label elements to associate text labels with form controls)\" and \"H65 (Using the title attribute to identify form controls when the label element cannot be used)\"--there is no common failure about _not_ labeling form controls. This also applies to 4.1.2.
Proposed Change:
Add a common failure about not labeling form controls.
Status: Resolved (resolved_yes).
Response Status: Resolution implemented
Working Group Notes: [TEAMC]
DONE change test procedure in H44 to:
For all input elements of type text, file or password, for all textareas and for all select elements in the Web unit:
1. check that there is a label element that identifies the purpose of the control before the input element;
2. check that the for attribute of the label element matches the id of the input element.
For all input elements of type checkbox or radio in the Web unit:
1. check that there is a label element that identifies the purpose of the control after the input element;
2. check that the for attribute of the label element matches the id of the input element.
Discussed in the 20 July 2006 telecon:
Resolution: Accept proposal for LC-654 as ammended to reference SC 1.3.1.
http://www.w3.org/2006/07/20-wai-wcag-minutes.html
DONE (28 July 2006) add "Failure of SC 1.3.1 and 4.1.2 due to omitting labels for form controls for item selection or text input"
Proposed technique is available at http://lists.w3.org/Archives/Public/public-wcag-teamc/2006Jul/0018.html
Resolution - Pending Response:
Thank you for pointing out the missing failure. We will add a "Failure of SC 1.3.1 due to omitting labels for form controls for item selection or text input".
Related Issues:
587
Assigned To: Nobody
Last Edited: 20060728191320
Sort Terms:
Document: WCAG 2.0 Guidelines
Submitter: Joe Clark <joeclark@joeclark.org>
Comment Type: substantive
Location:
Comment:
From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0119.html
text alternative
programmatically-determined text that is used in place of non-text content, or text that is used in addition to non-text content and referred to from the programmatically-determined text
Hence a title attribute absolutely is a text equivalent. An image with empty alt plus a title containing what would otherwise be the alt text will pass WCAG 2. (There is some overlap here with UAAG, which can be interpreted to allow presentation of title text instead of regular or alt text.)
Status: Resolved (resolved_partial).
Working Group Notes: [EDITORZ]
Discussed in the 13 July 2006 telecon:
Refer LC-850 back to committee
http://www.w3.org/2006/07/13-wai-wcag-minutes.html
Discussed in the 17 August 2006 telecon:
resolution: unanimous consent to accept the following proposals from the Editorz: LC-847, LC-849, LC-850, LC-1006, LC-987, LC-936, LC-890, LC-852
resolution: unanimous consent to accept the following proposals from Team C: LC-1047, LC-1082, LC-1089, LC-1116, LC-1117, LC-1196, LC-1326
resolution: unanimous consent to accept the following proposals from Team B: LC-1127
http://www.w3.org/WAI/GL/2006/08/17-wai-wcag-minutes.htm
Resolution - Pending Response:
{partial_accept}
@@ add a failure, "Failure of SC 1.1.1 due to providing a title attribute without also providing a non-null alt attribute
The use of title alone (with empty alt text) is not cited as a sufficient technique by the working group. If one would like to assert and defend this as conforming to the success criterion one would have to show that it did indeed work for users with disabilities and their AT.
We have added a failure titled, "Failure of SC 1.1.1 due to providing a title attribute without also providing a non-null alt attribute," to make this clear.
Related Issues:
Assigned To: Nobody
Last Edited: 20060818015251