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

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

Received on Tuesday, 19 April 2011 12:36:44 UTC