Fwd: clarifications to issue 31 title as conforming when alt is omitted

Can we add this to the agenda for next week, I have filed a formal
objection to this title attribute as conforming part of the the
decision on issue 80/31
(http://lists.w3.org/Archives/Public/public-html/2011Apr/0451.html).

I think that this aspect of the decision in particular is seriously
flawed, I knwo other have serious concerns about other parts of the
decision so it may be appropriate to have a a11y taskforce endorsed
position (not that it means anything) on the various issues

regards
steve

---------- Forwarded message ----------
From: Steve Faulkner <faulkner.steve@gmail.com>
Date: 19 April 2011 11:01
Subject: clarifications to issue 31 title as conforming when alt is omitted
To: HTMLWG WG <public-html@w3.org>, Sam Ruby <rubys@intertwingly.net>,
Maciej Stachowiak <mjs@apple.com>, Paul Cotton
<Paul.Cotton@microsoft.com>


"Though somewhat tricky to follow, the following passage implies that
in at least some
assistive technologies, the contents of the title attribute *are*
exposed, in an accessible way:"

All browsers that I know of treat these 2 cases the same in regards to
accessibility API mapping:


example 1
<img src="2421.png" title="Image 640 by 100, filename 'banner.gif'">


example 2
<img src="2421.png" alt="Image 640 by 100, filename 'banner.gif'">

in the cases above both title and alt are mapped to the accessible
name property in accessibility APIs, this has always been the case and
as there is no practical alternative will continue to be the case.

So for a screen reader user there is no difference in how the two are
presented to the user.

The only difference in the HTML5 specification are normative rules
about what each attribute can contain, the alt attribute rules are
precisiely described, the title attribute rules are not.
Authoring as in example 2 is non conforming authoring 1 is not, quite
the opposite it is encouraged in cases where a text alternative is not
known.

"Not much evidence was provided that this cannot or will not change,
however. At least one product is already known to expose title in an
accessible way, and others were reported to do so as an option. Thus,
this was also taken as a weak objection."

No graphical browser supports title attribute display in an accessible
way. Now graphical browser maps title to accessibility APIs
differently from how it maps alt when alt is not present.
of the graphical browsers only webkit displays title content when
images are not viewable or disabled, but only if the title content is
a few words:
(refer to the follwoing test/results
http://www.paciellogroup.com/blog/misc/HTML5/alt-tests/alt-examples.html)

The fact that webkit displays title attribute content in the same way
as alt when images are not displayed, is not an argument for its
accessibility as it requires keyboard only users to turn images of in
order to view titles. there is no equivalency in the method of access
between keyboard and mouse users.


Note: webkits behaviour is also non conforming as per the HTML5 spec:

"The alt attribute does not represent advisory information. User
agents must not present the contents of the alt attribute in the same
way as content of the title attribute." [1]


"One might wonder: since the use cases for omitting alt when title is
specified are described as being served by either title or figcaption,
is it necessary to allow omitting alt in both cases, or only for one
of these constructs? "

There is a clear distinction between the two, use of figcaption
provides accessible display of the caption content, to all users at
all times.
Use of title does not and thus discriminates against a range of users
as it is not implemented in a device independent way in any  browser
although it has been in HTML for 10+ years.
these users include:
those who cannot use a pointing device.
screen magnifier software users. (at higher magnifications tooltips
are not displayed in the viewport and as they are tied to mouse
position the user can never read all the tooltips of more than a few
words)
users of built in browser magnification (tootlips are not magnified).
users with cognitive impairments (in most browsers tooltips only apear
on hover for a short time, around 5 seconds, so ).


[1] http://dev.w3.org/html5/spec/embedded-content-1.html#the-img-element

--
with regards

Steve Faulkner

Received on Tuesday, 19 April 2011 10:16:02 UTC