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:20:47 +0100
Message-ID: <BANLkTik7+rfGzEboG7NFswASZX2BYs2xsw@mail.gmail.com>
To: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Cc: Maciej Stachowiak <mjs@apple.com>, 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 Leif,

>Opera does not automatically display @title when @alt is lacking, but
>it is, via CSS, possible to make it do so.

it may be possible to display any part of the DOM via CSS, that does not
mean the user agent provides device independent access to such content.


On 7 May 2011 22:08, Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>wrote:

> Maciej Stachowiak, Fri, 06 May 2011 17:45:46 -0700:
> > On May 5, 2011, at 2:26 AM, Steve Faulkner wrote:
> Hi Steve and Maciej,
> >> 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.
> Webkit is not alone: the text browsers Links, Elinks, W3m and Lynx all
> display @title when @alt is lacking.
> Opera does not automatically display @title when @alt is lacking, but
> it is, via CSS, possible to make it do so.
> > 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,
> More details, VoiceOver vs @title vs @alt:
>        1) for normal <a> (anchor) element links, then if @title +
>    link text are 100% equal (from a 'plain text' perspective), then
>    VoiceOver does not not read the @title attribute.
>        2) if @title and link text differ w.r.t. characters (white
>    -space doesn't matter, it seems), then both @title and link text
>    is read.
>        Due to 1) and 2), VoiceOver reads each of the following 5 links
>    as 'foo. Foo.':
>          <a href title=" foo. Foo. "></a>
>          <a href title=" foo. Foo. "><img alt=" foo. Foo. "></a>
>          <a href title=" foo. Foo. "       ><i> foo. Foo. </i></a>
>          <a href title=" foo. "     ><img alt=" Foo. "></a>
>          <a href title=" foo. "            ><i> Foo. </i></a>
>    3), for  <area> (area) element links, then a bug in VoiceOver
>    or in Webkit cause @alt to be ignored so that only @title is
>    read. When there is no @title, then VoiceOver "repairs" for
>    lack of link text (by starting to read the @href content).
> ARIA vs VoiceOver:
>        From ARIA 1.0's perspective, then @title is completely ignored,
> unless
> there is no alternative to using it. Thus, from an ARIA supporting AT's
> perspective, it does not seem correct to assume that @title isn't used.
> But from the other angle: when both @title and @alt are present, then
> @title seems to be completely ignored in ARIA.
> ARIA's approach and VoiceOver's approach lead to same result when:
>    1. @title and link text are present and are identical;
>    2. or when @title is present but link text isn't present;
> ARIA's approach and VoiceOver's approach lead to different result when:
>   * there is a link text and a @title that differs from the link text.
> Which means that it is - roughly speaking - only when @title is used
> according to HTML5's rules about "advisory content" that there actually
> is any difference between VoiceOver and ARIA.
> --
> Leif Halvard Silli

with regards

Steve Faulkner
Technical Director - TPG

www.paciellogroup.com | www.HTML5accessibility.com |
HTML5: Techniques for providing useful text alternatives -
Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
Received on Sunday, 8 May 2011 11:21:34 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:37 UTC