[whatwg] alt and title attribute exception

[Steve Faulkner]

Hi Leif,

There is a distinction between what browsers should do to provide fallback
and what should be promoted in the spec as a desired authoring pattern.
browsers support many non conforming markup patterns.

Because webkit browsers display title attribute content if alt attribute is
not present, it is not a reason for making the markup pattern conforming.

I believe the reasoning for the must requirement for browsers not to
display alt in the same way as title, was to remove a reason for authors to
use alt to provide advisory information, if so, similarly making the use of
title without alt non conforming removes the legitimacy of the markup
pattern that results in the same thing.


Anyway this discussion is moving off the crux of the issue with allowing
title when alt is not available. It promotes the use of the title attribute
for the presentation of text content for all users at all times when due to
long running browser implementation realities it is not available to some
users when it should be.

regards

Stevef

On 31 July 2012 19:57, Leif Halvard Silli
<xn--mlform-iua at xn--mlform-iua.no>wrote:

> 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




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