W3C home > Mailing lists > Public > public-html-a11y@w3.org > September 2010

Re: Default role of <IMG> should be "img"

From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
Date: Sun, 12 Sep 2010 10:47:06 +0100
Cc: public-html-a11y@w3.org
Message-Id: <3680255A-BBEA-40DD-A893-2C9ABC966C51@googlemail.com>
To: Steven Faulkner <faulkner.steve@gmail.com>
On 12 Sep 2010, at 08:26, Steven Faulkner wrote:
> "As a user, I personally think it's highly suboptimal if to consume a webpage I
> need to view UI images (e.g. icons) or even be notified of their existence.
> More generally, I think it's a real failure that a purportedly media
> independent, user-formattable markup language requires this."
> 
> There is NO requirement, it is up to AT whether they report and how they report role information provided via an accessibility API for any element.

I'm not just talking about AT here, but about what "img" represents to all users. What AT reports should ideally match what "img" represents to all users, because that's the meaning that is being communicated. My point is it's very hard to build a user agent that discards UI images, because it's difficult to distinguish them from significant images, much like it's difficult to distinguish layout and data tables.

> But there SHOULD be a requirement that all HTML elements, where they can be mapped to accessibility APIs are mapped and that mapping reflects the objects they represent.

Everyone agrees accessibility mappings should reflect what elements represent. (There's some disagreement about what they represent.)

> I asked this question on twitter the other day:
> "Do vision impaired users want to know an image on a web page is an image? or should the information be always hidden from them?"

Again, my concern isn't *just* about people with disabilities: it's about media independence and user-formattability for every user of the web. More critically, your question didn't single out UI images, but also includes photos, charts, diagrams, etc, so it's a radically different question. I think only one of the three responses (Everett Zufelt's) could be interpreted as saying the user wants to know a UI image is an image. Better questions for getting screen reader user views on UI images might be:

   * "Assuming photos and illustrations were still called out as graphics, would you prefer to hear/read 'button graphic edit button graphic delete button graphic copy', or 'button edit button delete button copy'?"

   * "Assuming photos and illustrations were still called out as graphics, would you prefer to hear/read 'heading level two graphic introduction' or 'heading level two introduction'?"

   * "Assuming photos and illustrations were still called out as graphics, would you prefer to hear/read 'link graphic home link graphic prices link graphic about link graphic contact' or 'link home link prices link about link contact'?"

If we're serious about saying the accessibility tree must expose graphical UI components as graphics, then we must confront an elephant in the room: the UI graphics people see are increasing added by CSS.

Consider the icon for an "Edit" button (typically a pencil). Today there are two common patterns for icons:

Pattern 1: "img" element

   <button><img alt="Edit" src="pencil.png"></button>

Pattern 2: CSS text replacement hacks

   <button><span>Edit</span></button>

   button { background-image: pencil.png; width: 16px; height: 16px; }
 
   button span { position: absolute; left: -99999px; }

Current CSS text replacement hacks are not very robust, and I don't generally recommend their use, although usage has shifted dramatically in their favour, because of the performance advantages of spriting and the ease of reskinning.

Future CSS3 implementations may allow us to use more robust content replacement features:

   http://www.w3.org/TR/css3-ui/#icon-property

   http://www.w3.org/TR/css3-content/#inserting3

Assuming replaced text is still exposed to AT (Opera's implementation failed at this), would you argue that developers should be discouraged from using these future features for icons, because the button text would be represented as just button text in the accessibility tree rather than as an image with a text alternative?

Or would you argue that mappings to image roles should be based on CSS as well as markup?

Or would you argue that ATs should dig into other APIs to grab the CSSOM, work out that the text has been replaced with an image, and (potentially) report it as a graphic?

> it is not for HTML5 to dictate that <img> or any other element must not be mapped to an appropriate role in accessibility APIs.

Everyone agrees "appropriate" mappings should not be forbidden. (There's some disagreement about what is appropriate.)

--
Benjamin Hawkes-Lewis
Received on Sunday, 12 September 2010 09:47:42 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:14 UTC