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

Apologies Jonas, will take your feedback into account.


On 19 April 2011 13:35, Jonas Sicking <> 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
> <> 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
>> 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]
>> --
>> with regards
>> Steve Faulkner

with regards

Steve Faulkner
Technical Director - TPG | |
HTML5: Techniques for providing useful text alternatives -
Web Accessibility Toolbar -

Received on Tuesday, 19 April 2011 12:39:59 UTC