- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 19 Apr 2011 06:03:45 -0700
- 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