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

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

From: Steve Faulkner <faulkner.steve@gmail.com>
Date: Tue, 19 Apr 2011 13:39:12 +0100
Message-ID: <BANLkTimWcMtGs41aAGYSN98MhjsD6ZT=kA@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Sam Ruby <rubys@intertwingly.net>, www-archive <www-archive@w3.org>
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 12:39:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 7 November 2012 14:18:35 GMT