Re: validating understanding of techniques for 1.1.1 & 2.4.4

Dear Ian and Loretta,

Ian asks -
"Do you have any thoughts on how this sentence could be phrased to
avoid developers making incorrect assumptions on the accessibility of
tittle attributes for text-to-speech software users?"

>>Technique H33: Supplementing link text with the title attribute states:
>> “Implementing this technique with the title attribute is only sufficient
>> if the title attribute is accessibility supported. The content of the
>> title attribute needs to be available to all keyboard users (not only
>> those with text-to-speech software) for this attribute to be 
>> accessibility
>> supported.”

The key to understanding the first sentence (I believe) is "if the title 
attribute is accessibility supported". If you are managing an intranet site 
where you know that all the users have appropriate technology then you can 
use the attribute safely. However if you are managing a site for the general 
public where you need to allow for all types of browser then the attribute 
may not make the link accessible to everyone. Perhaps a clearer rendering of 
the sentence would be -

“Implementing this technique with the title attribute is only sufficient
 if it is known that the title attribute is accessibility supported by end 
users."

The second senetence is clear and supports this concept in that, if used, 
the title attribute must work on hover, active and focus within the user's 
browser.

Regards

Richard


----- Original Message ----- 
From: "Ian Pouncey" <w3c@ipouncey.co.uk>
To: "Loretta Guarino Reid" <lorettaguarino@google.com>; <w3c-wai-ig@w3.org>
Cc: <asuncion@alcor.concordia.ca>
Sent: Saturday, July 31, 2010 11:57 PM
Subject: Re: validating understanding of techniques for 1.1.1 & 2.4.4


Hi Loretta,

This sentence (...not only those with text-to-speech software...)
suggests to me that title attributes are reliably exposed to
text-to-speech software users when this is not the case. For example
screen readers will often ignore title attributes with their default
settings while VoiceOver (on OSX 10.5 at least) defaults to reading
_only_ the title attribute on links and not the link text - arguably
worse than ignoring the attribute completely given how badly written
title text often is. Even with a traditional display and pointing
device a title attribute is easy to miss because of the delay user
agents add before display - technically accessible but not necessarily
usable!

If the value of the title is essential to understanding the purpose of
the link for all users then  in the case of the user agent being a web
browser with or without assistive technology it is not possible to
assume that it will be available to any users!

Do you have any thoughts on how this sentence could be phrased to
avoid developers making incorrect assumptions on the accessibility of
tittle attributes for text-to-speech software users?

Regards,

Ian.

On Tue, Jul 27, 2010 at 12:23 AM, Loretta Guarino Reid
<lorettaguarino@google.com> wrote:
> On Wed, Jul 14, 2010 at 7:00 AM, Jennison Mark Asuncion
> <asuncion@alcor.concordia.ca> wrote:
>> Hello,
>>
>>
>> 2.4.4 Link Purpose (In Context):
>> The purpose of each link can be determined from the link text alone or
>> from the link text together with its programmatically determined link
>> context, except where the purpose of the link would be ambiguous to users
>> in general.
>> Technique H33: Supplementing link text with the title attribute states:
>> “Implementing this technique with the title attribute is only sufficient
>> if the title attribute is accessibility supported. The content of the
>> title attribute needs to be available to all keyboard users (not only
>> those with text-to-speech software) for this attribute to be 
>> accessibility
>> supported.”
>> Question 3: This technique implies that for links using the “title”
>> attribute to be fully accessible, the “title” of each link must also be
>> keyboard accessible. Is this interpretation correct? Has anyone
>> successfully implemented this technique in this manner?
>>
>> Any help on the above three questions is, as always, appreciated.
>>
>> Jennison
>>
>>
>> --
>> Jennison Mark Asuncion
>> Co-Director, Adaptech Research Network <www.adaptech.org>
>> LinkedIn at <www.linkedin.com/in/jennison>
>>
> ================================
> Response from the Working Group
> ================================
> The answers to your questions will depend on whether the information
> provided by the title attribute is available to keyboard users by
> other means. For example, if the title is used to provide
> supplementary information about link text that already describes the
> purpose of the link, then it may not be necessary to make the value of
> the title attribute keyboard accessible. Similarly, it may not be
> necessary to make it keyboard accessible if the title includes
> information that is otherwise clear from the layout or positioning of
> the link within the context of the page.
>
> On the other hand, if the value of title is essential to understanding
> the purpose of the link for all users, then this information needs to
> be available to keyboard users as well.
>
> One example of providing keyboard access to tooltips can be found at
> http://www.brothercake.com/site/resources/scripts/tooltips/. There are
> also a number of tooltip plugins written for the various JavaScript
> libraries that could easily be customized so that this information
> appears on keyboard as well as mouse focus.
>
> We have modified the user agent note you mentioned to read, "If the
> value of the title is essential to understanding the purpose of the
> link for all users, then the content of this attribute needs to be
> available to all keyboard users (not only those with text-to-speech
> software) for this technique to be accessibility supported."
>
> Loretta Guarino Reid, WCAG WG Co-Chair
> Gregg Vanderheiden, WCAG WG Co-Chair
> Michael Cooper, WCAG WG Staff Contact
>
>
> On behalf of the WCAG Working Group
>
>

Received on Sunday, 1 August 2010 19:57:05 UTC