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

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.

regards
stevef


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 |
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