W3C home > Mailing lists > Public > www-archive@w3.org > April 2011

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

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 19 Apr 2011 06:03:45 -0700
Message-ID: <BANLkTint-S765P9KWcvN5=L3KPR1Pucg0Q@mail.gmail.com>
To: Steve Faulkner <faulkner.steve@gmail.com>
Cc: Sam Ruby <rubys@intertwingly.net>, www-archive <www-archive@w3.org>
Thank you Steve! It's greatly appreciated.

/ Jonas

On Tue, Apr 19, 2011 at 5:39 AM, Steve Faulkner
<faulkner.steve@gmail.com> wrote:
> Apologies Jonas, will take your feedback into account.
> regards
> steve
> On 19 April 2011 13:35, Jonas Sicking <jonas@sicking.cc> wrote:
>> Hi Steve,
>> When discussing topics that have existing threads, it would be greatly
>> appreciated if you reply using those existing threads rather than
>> starting new ones. Starting new ones makes following discussions hard,
>> as well as makes it hard to keep threads as "read later" since I'll
>> end up having to mark a large number of threads as "read later" and
>> try to sort of which belong together. It also makes it harder to skip
>> topics which I do not have time to follow.
>> This holds especially true for topics which we have a formal working
>> group decision on and where discussion is supposed to be kept to a
>> minimum.
>> It so happens that I agree with most of the issues you are raising
>> with regards to when the @alt requirement is supposed to be required.
>> (I unfortunately did not have time to respond to the survey as it
>> largely overlapped with a big work event). But it's getting very hard
>> to keep the discussion focused when such a large number of new threads
>> are being created. At this point I've given up any hope of tracking
>> your feedback to the WG decision, much less tracking it together with
>> the other @alt discussions.
>> / Jonas
>> On Tue, Apr 19, 2011 at 3:01 AM, Steve Faulkner
>> <faulkner.steve@gmail.com> wrote:
>>> "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
> --
> 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
Received on Tuesday, 19 April 2011 13:04:46 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:43:46 UTC