- From: Steve Faulkner <faulkner.steve@gmail.com>
- Date: Fri, 3 Aug 2012 09:36:07 +0100
- To: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Cc: "Michael[tm] Smith" <mike@w3.org>, public-html@w3.org, HTML Accessibility Task Force <public-html-a11y@w3.org>, John Foliot <john@foliot.ca>
Hi ben, the default beahviour for most AT under most circumstances, when no alt is present is to not inform the user that the image is present. The user has no way to discern the presence of such an image , that is problematic in cases where the image contains potentially important information, that is the same case where the flag would be used. Likewise some graphical browser do not indicate such an image when images are disabled. I can agree that the generation of a text string may be problematic , but do not agree that the presence of images "that are a key part of the content" but "whose contents are not known" ( to use HTML5 terminology [1]) should not be indicated in some way via an agreed method that allows allows user agents to flag their presence and provide users with options. [1] http://dev.w3.org/html5/spec/the-img-element.html#a-key-part-of-the-content regards stevef On 3 August 2012 09:23, Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com> wrote: > On Fri, Aug 3, 2012 at 9:12 AM, Steve Faulkner <faulkner.steve@gmail.com> wrote: >> I had a discussion with john F last night in regards to how the >> presence of a generated image, without without an alt attribute but >> with the proposed attribute, should be exposed in accessibility APIs. > > I don't get what's wrong with the existing behavior where images with > missing @alt are placed into the accessibility hierarchy either > without an accessible name or with some sort of repair? I think the > flag, should we add one, should only affect linter behaviour not user > agent/AT behaviour. > >> I think that this is a side effect that could be ameliorated by use of >> a common, agreed, text string across browsers, so such images are >> consistently identified. > > Sounds like a nightmare. I think we want to avoid that at all costs; > if we do decide that AT need to change their behavior based on this > flag it would be much better to go to ia2 and agree on an API level > flag that doesn't require polluting an existing field or syncing > localization efforts across products. > >> AT could then provide further options to the >> user if they so choose, for example later versions of JAWS include an >> OCR feature. > > Surely AT would want to give users the option to use such features for > images without either @alt or the flag? > > -- > Benjamin Hawkes-Lewis -- 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 Friday, 3 August 2012 08:37:20 UTC