[whatwg] alt and title attribute exception
Leif Halvard Silli
xn--mlform-iua at xn--mlform-iua.no
Tue Jul 31 11:57:21 PDT 2012
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
More information about the whatwg
mailing list