Re: [whatwg] alt and title attribute exception

Steve Faulkner on Tue, 31 Jul 2012 13:03:02 +0100, wrote,
in reply to Philip Jägenstedt:
>> but I'm confused -- is falling back to title a Good Thing that people want
>> browsers to implement, or is it just a quirk that some legacy browser had?
> 
> Given that there is a semantic distinction in the spec between what alt
> content is and what title content is and a swathe of normative
> requirements/advice based on this distinction it would appear unwise to
> promote the use of title as fallback without providing normative
> requirements on provision of a method to distinguish between the two.

So, it is bad that the Webkittens fall back to using @title? 

I must admit that I don't understand how you reason. Because, when 
@title is used as fallback, then we _want_ @title to be treated as 
@alt. So why do need a method to distinguish the two, then?

> *Note:* in terms of the accessible name calculation for an img element, if
> the image does not have aria-label or an aria-labelledby or an alt
> attribute, but does have a title attribute, then the title attribute is
> used as the accessible name. From an accessibility API perspective, no
> distinction is indicated as to the source of the accessible name (apart
> from in the Mac AX API).

On the old mac I have at hand, right now, then AXImage (of 
Accessibility Inspector) renders the @title content, when the @alt is 
lacking. There is no info about the fact that the AXImage stems from 
@title. But perhaps that has changed so that AT users are informed when 
the accessible name stems from the @title?
 
> The last point is another reason why making the title attribute on images
> (without alt) conforming is that the semantics, for all users, are
> ambiguous.

And another place in the same letter you say:

>> User agents must not present the contents of the alt attribute
>> in the same way as content of the title attribute.
> 
> As there is no way visual distinction between title content 
> being displayed and of alt content in this case.

Comments:

(1) It does not follow, from the fact that the spec forbids @alt from 
being rendered as a tooltip, that a tooltip cannot be rendered as an 
@alt.

(2) If the spec did not forbid @alt from render as a tooltip, then 
authors would be confused to write @alt texts that were excellent as 
tooltips but <del>bad</del> <ins>sub optimal</ins> as @alt content. 
(Thus, it is based on the respect for how the two features are 
distinct.) Conversely, if @title render as @alt, then authors would 
perhaps write tooltips that served OK as @alt. If that is bad, then why 
is it bad? 

(3) The fact that @title is used as last resort when calculating the 
accessible name is because an accessible name is so important that even 
a tooltip can be useful for that purpose, when need be. So why would it 
be a big no no that a lacking @alt causes the @title to be rendered as 
@alt content? 

I think the spec's motivation for the current "exception" might be 
similar to the generator exception: It is done to not triggers authors 
to e.g. create empty @alt or repeated, meaningless @alt text of the 
kind alt="image" - just in order to validate. I disagree strongly with 
the generator exception. But I cannot say I strongly disagree with the 
@title exception. With the introduction of ARIA, it has become even 
less critical to remove this exception, since ARIA includes the @title 
as a last resort anyhow.

I'm uncertain about how lack of keyboard access to @title can be used 
against this exception, when both Webkittens and ARIA give them access 
to it.
-- 
Leif Halvard Silli

Received on Tuesday, 31 July 2012 18:58:00 UTC