[Bug 10482] New: Should @usemap affect the default role of an IMG element?

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

           Summary: Should @usemap affect the default role of an IMG
                    element?
           Product: HTML WG
           Version: unspecified
          Platform: PC
               URL: http://dev.w3.org/html5/spec/content-models#annotation
                    s-for-assistive-technology-products-aria
        OS/Version: All
            Status: NEW
          Keywords: a11y, aria
          Severity: normal
          Priority: P2
         Component: HTML5 spec (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: xn--mlform-iua@xn--mlform-iua.no
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html@w3.org
        Depends on: 10446,10481


(This bug depens on bug 10481 - default @role for img elements should be "img")

Question: Should  the presence of @usemap change the default role of img
elements?
Assumption: My assumption is that presence of @usemap shoud not affect the
@role of an img element.

Background:

Opera and Webkit fails to render the @alt whenever an img element has the
@usemap attribute. That is: Unlike for IMG elements without the @usemap
attribute, blocking access to the @src URL, does not lead these browsers to
display the alt text instead.)

Also,  at least in Webkit's case, the role changes  from its default
(role="img") to something else – which again causes VoiceOver to not read the
@alt attribute. (If one adds role="img" to it, _then_ Webkit will read the @alt
attribute.)

In contrast, Firefox and IE will display the @alt text – I don't know what they
do with the ARIA @role.

Sub-question, depening of the solving of the primary question: Even if @usemap
would change the @role of an IMG element, should such a thing impact on the
presentation of the @alt attribute?

-- 
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 Saturday, 28 August 2010 20:12:35 UTC