W3C home > Mailing lists > Public > public-html@w3.org > May 2011

Re: device independent title attribute support in browsers and follow up question

From: Steve Faulkner <faulkner.steve@gmail.com>
Date: Sun, 8 May 2011 12:18:42 +0100
Message-ID: <BANLkTiky3QWMyfU0-48AAuoSEZbLsjGX8g@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: HTMLWG WG <public-html@w3.org>, Charles McCathieNevile <chaals@opera.com>, David Bolter <dbolter@mozilla.com>, Adrian Bateman <adrianba@microsoft.com>, Cynthia Shelly <cyns@microsoft.com>, Ian Hickson <ian@hixie.ch>
Hi Maciej,

>I'm not sure if this is intentional behavior or a bug. It definitely is
intentional that we expose title to assistive technologies

I have never questioned the implementation of title in regards to exposure
of the title attribute content to AT via accessibility APIs, it is a common
implementaion pattern to expose title attribute content as the accessible
name in accessibility APIs when no other source is available.

you wrote
"It is also intentional that alt does not create a tooltip, which I believe
is the primary intent of the HTML5 requirement that title and alt should not
be displayed in the same way. Historically, some older browsers displayed
alt text as a tooltip. This led to authors choosing alt text which was
advisory in nature and suitable for use in a tooltip, rather than alt text
which could act as a textual equivalent for the image. By this standard,
it's not necessarily wrong to show the title text on a missing image when
alt is missing, though it does seem the letter of the spec would forbid this
behavior."

In versions of IE prior to IE8 (and still is in quirks mode in 8/9) alt
attribute content was

1.displayed as a tooltip (when a non-empty title was not present)
2.exposed as the accessible name property in accesssibility APIs
3. displayed when the image was not rendered

This was considered poor behaviour because it lead  " to authors choosing
alt text which was advisory in nature and suitable for use in a tooltip" so
user agents are forbidden to display alt attribute content as a tooltip.

So instead in HTML5 we now make it conformant to use the title attribute
(and leave out alt) which is

1.displayed as a tooltip
2.exposed as the accessible name property in accesssibility APIs
3. displayed when the image is not rendered. (in some browsers)


There is NO difference in how the content is conveyed to AT users between
the following:

<img src="x.jpg" alt="poot">

<img src="x.jpg" title="poot">

in MSAA for example:
via title:
Role:image
name: poot

via alt:
Role:image
name: poot

So what has been gained by forbidding user agents from displaying alt as a
tooltip while then blessing the use of title in place of alt?

regards
stevef


On 7 May 2011 01:45, Maciej Stachowiak <mjs@apple.com> wrote:

>
> On May 5, 2011, at 2:26 AM, Steve Faulkner wrote:
>
> Hi all,
>
> I originally requested feedback on April 19th, since the 2 vendors have
> indicated that they have no plans to implement device independent access to
> the title attribute.
>
> Can it be taken that the lack of response from Apple and Opera that they
> also have no plans?
>
>
> Apple does not generally give specific details regarding future product
> plans. I can tell you that in general we are interested in accessibility and
> strive to improve it over time.
>
> I can also tell you that, as far as current products go, Safari+VoiceOver
> on Mac OS X makes the title attribute very broadly accessible, including to
> blind or visually impaired users, and to users who have difficulties with
> using a pointing device. We will give consideration to how the experience
> can be improved when VoiceOver is not in use.
>
>
> FYI
> I published some data on title attribute usage on a few web pages,
> http://www.html5accessibility.com/tests/title-usage.html
>
> Of the pages checked approximatley 90% of title attribute content was a
> duplicate or similar to the text content of the element the title attribute
> was associated with.
>
> *A further question:*
>
> Do any vendors have plans to follow webkit's lead and display the title
> attribute content in place of an image when the image is not rendered?
>
>
> I'm not sure if this is intentional behavior or a bug. It definitely is
> intentional that we expose title to assistive technologies, and that
> consequently VoiceOver will use it when present for images that lack an alt
> attribute. It is also intentional that alt does not create a tooltip, which
> I believe is the primary intent of the HTML5 requirement that title and alt
> should not be displayed in the same way. Historically, some older browsers
> displayed alt text as a tooltip. This led to authors choosing alt text which
> was advisory in nature and suitable for use in a tooltip, rather than alt
> text which could act as a textual equivalent for the image. By this
> standard, it's not necessarily wrong to show the title text on a missing
> image when alt is missing, though it does seem the letter of the spec would
> forbid this behavior.
>
> I think the spec requirement should be changed to say something like "User
> agents must not present the contents of the alt attribute as if they were
> advisory information, e.g. as a tooltip." The requirement as stated seems
> wrong, because the spec does allow using title as a effectively a textual
> replacement when alt is not available.
>
>
> *Note:* if so the HTML5 spec will require updating as it currently forbids
> alt and title to be displayed in the same way :
>
> "The alt attribute does not represent advisory information. User agents
> must not present the contents of the alt attribute in the same way as
> content of the title attribute."
> http://dev.w3.org/html5/spec/embedded-content-1.html#the-img-element
>
> Details of  support in 2010 for title and alt display on images is
> available:
>
> alt and title content display in popular browsers
> http://www.paciellogroup.com/blog/2010/01/alt-and-title-content-display-in-popular-browsers/
> results:
> http://www.paciellogroup.com/blog/misc/HTML5/alt-tests/alt-examples.html
> screenshots:
> http://www.paciellogroup.com/blog/misc/HTML5/alt-tests/screenshots.html
>
> regards
> Stevef
>
>
> On 19 April 2011 09:37, Steve Faulkner <faulkner.steve@gmail.com> wrote:
>
>> Hi all,
>>
>> A recent decision by the HTML working group makes it conforming to
>> provide caption content for images whilst omitting the alt attribute.
>> This is problematic because while alt is designed to be presented to
>> users when the image cannot be viewed, and it is implemented as such.
>> The title attribute is for advisory information that should be
>> available to all users at any time. This is not the case and has never
>> been the case in any graphical browser.
>>
>> Can any of the representatives from browser vendors provide
>> information as to when the title attribute will be implemented so:
>>
>> * keyboard only users are aware that a title attribute is present on an
>> element?
>> * keyboard only users are able to access the title attribute content
>> on an element using the keyboard?
>> * The display of the title attribute content is configurable so that
>> users of screen magnifiers are able view title attribute content
>> within the viewport?
>> * access to title attribute content will be available on mobile and
>> touch browsers?
>>
>>
>>
>> --
>> with regards
>>
>> Steve Faulkner
>>
>
>
>
> --
> with regards
>
> Steve Faulkner
> Technical Director - TPG
>
> www.paciellogroup.com | www.HTML5accessibility.com |
> www.twitter.com/stevefaulkner
> HTML5: Techniques for providing useful text alternatives -
> dev.w3.org/html5/alt-techniques/
> Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
>
>
>
>


-- 
with regards

Steve Faulkner
Technical Director - TPG

www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
Received on Sunday, 8 May 2011 11:19:31 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:24 UTC