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

On Sep 12, 2010, at 2:47 AM, Benjamin Hawkes-Lewis wrote:

> 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.

ARIA roles only affect what is reported to AT, so opening this broader question isn't particularly relevant to the default role of the <img> element (if any).

It's important to realize that the ARIA role is a construct that exists solely for assistive technologies.

> 
> 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.

The fact that particular elements are graphics does need to be exposed to assistive technologies so they can make the right choice in context. However, many will treat specially the case of an image that is the sole content of an <a> element or <button>, since in that case it's clearly a graphical UI component. WebKit will go so far as to detect "click" event listeners and will treat things that have them as buttons if they are not already interactive and don't have a more specific role.

In some other cases, it's impossible to distinguish content images from UI components. That's unfortunate, but a little excess identification of graphics is probably better than failing to identify content images as such. Or at least, users should have that option.

If the spec requires not identifying images as such through accessibility APIs, then the spec is simply wrong, and that aspect will not be implemented. (It's not clear to me what results from the somewhat convoluted definition of what an image represents, but if it's meant to lead to this conclusion it is wrong.)

> 
> 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>

Is this pattern actually common? I don't see it very often when debugging web pages. I see buttons that are CSS styled in various ways a lot though.

> 
> 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; }

This is more plausible, though sadly often a <div> is used for this purpose instead of a <button>. :-(

> 
> 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.)

Is there really? Does anyone sincerely think that it's wrong to map an <img> element to the image role in native accessibility APIs by default? It seems obviously correct to do this, and it's up to the specific assistive technology to decide whether to specifically identify the image as such, depending on context. Certainly we wouldn't want to encode the appropriate heuristics in the spec.

Regards,
Maciej