W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > March 2010

[Bug 9214] Allow role="presentation" on img

From: <bugzilla@wiggum.w3.org>
Date: Wed, 24 Mar 2010 01:25:47 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1NuFLv-0007ch-EC@wiggum.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9214


Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xn--mlform-iua@xn--mlform-
                   |                            |iua.no




--- Comment #6 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>  2010-03-24 01:25:46 ---
(In reply to comment #4)

> The spec allows any role="" value to be specified when
> on <img> elements, unless the alt="" value is empty, in which case it is
> required to be role="presentation".)

I believe the bug is about ensuring that all the following minimum variants are
allowed ("at least one of the following is true"): 

    1) <img role="presentation" alt="" src="img" > 
    2) <img role="presentation" src="img" >
    3) <img alt="" src="img" >

Ian: Is it your view that all the above are already permitted?

The HTML5 spec text currently says, that there is an exception w.r.t. what
roles that are allowed, when a HTML feature has "strong native semantics", but
it doesn't clearly say (could be clearer at least), that the consequense of the
exception is that only the exact role  that is listed in the table, is
permitted:

]]
Authors may use the ARIA role and aria-* attributes on HTML elements, in
accordance with the requirements described in the ARIA specifications, except
where these conflict with the strong native semantics described below.
[[

When I say "except where", then I would also expect a "then such an such rules
applies".  I think the quote above could be made cleared by adding something
like this:

]]
When an element/feature has strong native semantics, then the only that role
which is in line with the strong native semantics is permitted.
[[

Or perhaps by changing the title of the second column in that table to say
"implicit and permitted role values" instead of only "implicit". 

May be this solves parts of Laura's issue. 

As to your question about whether another role than presentation is thinkable:
perhaps CAPTCHAs is a situation where one could potentially use another role
than "presentation", even if the alt is emtpy. What is it that permits you to
not use whether @role or the alt attribute in the CAPTCHA example in the spec?
At the very least, a role="captcha" is something that has been put forward:

http://www.w3.org/mid/9B88E254-B0C5-4024-BF7E-F42A4EB5FF6E@adobe.com

(Another way to solve this bug could be to list the forbidden role values,
instead of listning the permitted role values. )


-- 
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, 24 March 2010 01:25:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 24 March 2010 01:25:50 GMT