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

hi ben,

"Better questions for getting screen reader user views on UI images might
be:..."

yes many better questions could be asked, but I am fairly certain the screen
reader users who responded (included a screen reader developer, yahoo
accessibility evangelist, a developer working on drupal accessibility),
 understood the intent of the question.

"<button><img alt="Edit" src="pencil.png"></button>"
"because the button text would be represented as just button text in the
accessibility tree rather than as an image with a text alternative?"

NO I would argue for the current behaviour:
The accessible tree (can be viewed using firefox DOM inspector) looks like
this:

- pushbutton > name > bottle
-- graphic > name > bottle
When an AT such as JAWS encounters the button announces the button role and
its accessble name value (from the image alt text) it does not announce the
image. BUT the image is not removed by the browser from the accessible tree.

 regards
Stevef


On 12 September 2010 10:47, Benjamin Hawkes-Lewis <
bhawkeslewis@googlemail.com> 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.
>
> > 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




-- 
with regards

Steve Faulkner
Technical Director - TPG Europe
Director - Web Accessibility Tools Consortium

www.paciellogroup.com | www.wat-c.org
Web Accessibility Toolbar -
http://www.paciellogroup.com/resources/wat-ie-about.html