- From: <bugzilla@jessica.w3.org>
- Date: Wed, 08 Sep 2010 10:32:01 +0000
- To: public-html-bugzilla@w3.org
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 the QA contact for the bug.
Received on Wednesday, 8 September 2010 10:32:02 UTC