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

(unknown charset) Re: device independent title attribute support in browsers and follow up question

From: (unknown charset) Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Mon, 9 May 2011 04:24:10 +0200
To: (unknown charset) Steve Faulkner <faulkner.steve@gmail.com>
Cc: (unknown charset) 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>
Message-ID: <20110509042410085345.8dd01046@xn--mlform-iua.no>
Steve Faulkner, Sun, 8 May 2011 12:23:33 +0100:
> This may be a method that implementors use to display title attribute 
> content to keyboard users, the possibility that it can be displayed 
> using CSS does not mean that user agents provided access to via a 
> device indepndent means.

It gives authors a means to make pages more device independently 
accessible. 

Steve Faulkner, Sun, 8 May 2011 12:20:47 +0100:
>>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.

It might, to quote the Decision, make Opera: "[...]able to expose it in 
an accessible way".  If the issue can be given a good direction by a 
style rule in HTML5's Rendering section, then we should put it there.

You say that <abbr title="abbreviation">ABBR</abbr> is 'not useful' 
and/or 'of limited use'. [1] Not because screen readers don't support 
it, but  because keyboard access to it is bad. You give advice about 
providing the same functionality in plain text. That's an authoring 
advice. My authoring advice is to consider CSS generated content - like 
the CSS working draft itself hints: 
http://www.w3.org/TR/css3-content/#inserting It would be right, because 
keyboard access is important, to show how such use can be given access 
via CSS.

Btw, there is at least one Firefox project that seems work on keyboard 
access to @title. [2] (It does provide keyboard access to @alt inside 
links already.)

When it comes to what you say about display of @title and @alt in 
popular browsers in 2010 [3], then you don't mention that ARIA provides 
access to @title when nothing else is available. (Naturally, since you 
looked at *display*.) Clearly there are some issues to solve w.r.t 
@title. But I am not sure that lack of @alt in combination with 
presence of @title is the best best example since ARIA in that 
situation does make use of @title.

Before the Decision, then - according to HTML5, am IMG which serves as 
a link must have a non-empty @alt. Apparently, after the @title 
Decision has been applied, this remains the same. So, for IMG elements 
that act as links, there is no @title exception.

In your CP, are you considering saying that validators should issue a 
warning when there is @title but no @alt? As an author, I would like to 
be made aware of such an issue - I don't want to a failure to provide 
@alt be silently ignored. (This is similar to the generator exception - 
it can silence the validator so that authors becomes unaware of what's 
they've done.) Of course, it can also be an error - but at least there 
should be a warning.

[1] 
http://www.paciellogroup.com/blog/2010/11/using-the-html-title-attribute/
[2] http://code.google.com/p/dactyl/issues/detail?id=200
[3] 
http://www.paciellogroup.com/blog/2010/01/alt-and-title-content-display-in-popular-browsers/
-- 
Leif H Silli
Received on Monday, 9 May 2011 02:24:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:31 GMT