[Bug 10481] Default role of <IMG> should be "img"

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10481


Maciej Stachowiak <mjs@apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mjs@apple.com




--- Comment #7 from Maciej Stachowiak <mjs@apple.com>  2010-09-08 10:31:59 ---
I'm puzzled by what it means for <img> to have no role by default instead of
img role, in terms of browser implementation. I would expect the effect of
role=img to cause the element it is applied to (and its contents as a unit) to
be treated like an <img> element - that is to say, in the appropriate contexts
and depending on user configuration, a screen reader might replace it entirely
with its text equivalent, might combine it as a unit with a link where it is
the sole contents, or might flag it as an image. In the case of images that are
not an <img> element, this would involve a form of text equivalent other than
alt, e.g. specified by aria-labeledby, but in WebKit's accessibility code,
those are presented to AT in the exact same way.

In brief, from the implementation perspective, I think it is factually true
that an <img> with missing or non-empty alt will be treated the same as if it
had role=img. (<img> with empty alt is exceptional and treated the same as
role=presentation, of course). In fact, as far as I can tell from our
accessibility code, <img> and role=img are treated exactly the same except in
what constitutes valid sources of text equivalents.

Given all this, I am not sure what it means to say <img> does not have img as a
default role. Is WebKit buggy? Should we be somehow treating <img> with no
explicitly specified role differently from <img role=img>?

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Wednesday, 8 September 2010 10:32:05 UTC