- From: Steve Faulkner <faulkner.steve@gmail.com>
- Date: Tue, 19 Apr 2011 13:39:12 +0100
- 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 UTC