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

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

From: Steven Faulkner <faulkner.steve@gmail.com>
Date: Tue, 14 Sep 2010 09:53:31 +0100
Message-ID: <AANLkTi=Of-fTjCysq38FAS=FwN0VUoxnNgSX3M7U_XeW@mail.gmail.com>
To: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
Cc: public-html-a11y@w3.org
Hi Ben,
 you wrote:
"The elephant is still in the room!"
I have no problem with the use of CSS to display images, if the UI is still
understandable and usable by people who cannot access or understand those
images. What a do have a problem with is making the default role of <img>
something other than img, because in many cases it is an image, and users
should be given the opportunity to have that information provided to them.

Can't the same thing can be argued for table/tr/td elements? Table
structures are widely used for purposes other than marking up data therefore
they should not be mapped to the corresponding roles in accessibility APIs

Now if HTML5 were to define a set for classifications for images that could
be passed through to accessibility APIs as a property of the img I would see
that as a step forward.

example:
 <img type="photograph" alt="president obama sitting in the Oval office
havinga cup of tea">
 <img type="logo" alt="W3C">

accessibility API info:

name= president obama sitting in the Oval office havinga cup of tea
role="img"
type="photograph"

Then AT could provide the user with preferences to filter images based on
type.


you wrote:
"From an end-user perspective what is the difference between these two
cases?"

there is no difference if you are using a user agent that supports CSS.

you wrote:
"In an editing scenario, might not the user also want access to the
following presentational "img", even though ARIA excludes it from the
accessible tree?"
i would imagine so.

regards
stevef

On 14 September 2010 08:48, Benjamin Hawkes-Lewis <
bhawkeslewis@googlemail.com> wrote:

> On 13 Sep 2010, at 13:42, Steven Faulkner wrote:
> > No, because an inline <img> element is being used in the other example,
> in this example it's not.
>
> The elephant is still in the room!
>
> From an end-user perspective what is the difference between these two
> cases? In both scenarios, there's an image button with a text equivalent.
> That one case uses "img" and another CSS is, from their perspective, a mere
> implementation detail. If we're saying users need access to UI images, how
> do users get access to that CSS generated image?
>
> > An example where it would be useful:
> >
> >
> > <button contenteditable="true"><img src="cross.gif" alt="wrong"
> width="94" height="85" border="0" ></button>
> >
> > In IE for example when contenteditable="true" it is recognised as a
> graphic by JAWS and the img object information is provided to the user.
> >
> > Any html editor that provides a preview mode or wysywig editor.
>
> Thank you - that's an interesting use case.
>
> In an editing scenario, might not the user also want access to the
> following presentational "img", even though ARIA excludes it from the
> accessible tree?
>
>   <button contenteditable="true">
>       <img role="presentation" src="cross.gif" alt="">
>       Wrong
>   </button>
>
> ARIA may need some additions to cover this use case.
>
> However, I'm not sure editable DOM trees are a safe guide to how normal DOM
> trees should be mapped to the accessible tree.
>
> --
> 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
Received on Tuesday, 14 September 2010 08:54:26 UTC

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