- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Mon, 9 Apr 2012 15:40:45 +0200
- To: Alexander Surkov <surkov.alexander@gmail.com>
- Cc: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>, Steve Faulkner <faulkner.steve@gmail.com>, wai-xtech <wai-xtech@w3.org>
Alexander Surkov, Mon, 9 Apr 2012 11:51:48 +0900: > <a role=img href> is a real edge case and it doesn't sound a good ARIA > use case. See > http://www.w3.org/WAI/PF/aria-implementation/#mapping_conflicts > "WAI-ARIA roles, states, and properties are intended to add semantic > information when native host language elements with these semantics > are not available, and are generally used on elements that have no > native semantics of their own." Question: Are you sure that <a role=img href> is something HTML has - without role=img? (See below.) > Also look at: > "user agents MUST use the semantic of the WAI-ARIA role for > processing, not the native semantic, unless the role requires WAI-ARIA > states and properties whose attributes are explicitly forbidden on the > native element by the host language" So what this text says is, that in the case of <a role=img href>, then there is no "MUST use the semantic of the WAI-ARIA role". Why is there no MUST? Answer: Because HTML5 - currently - explicitly disallows role="img" for the <a> element. > <a role="img" href> is not described case but the most interesting > part that ARIA doesn't require to ignore the native semantics blindly. Yes, it *does* require to ignore the native semantics "blindly" (as in "MUST), *if* the host language permits it. HTML5 already permits the following roles for the <a> element: Role must be either link, button, checkbox, menuitem, menuitemcheckbox, menuitemradio, tab, or treeitem. See: http://www.w3.org/TR/html5/wai-aria.html#table-aria-weak Also note that HTML5 says: "In addition, any element may be given the presentation role, regardless of the restrictions below." > It sounds reasonable with me if ARIA would add or extend native > semantics rather than completely remove it. From the user/web author > point of view I don't see any benefits that AT users see an image but > sighted users see a normal link. HTML5 already disagrees with you: It allows role=presentation on both <a> and <img>. Also, when a link wraps around an image, then sighted users don't see "a normal link" — they see an image. Only when they hover around - or click - the image, do they see the link. Example: Om CNN.com today, each news story is presented like this: <div><a href="LinkURL"><img src="URL" alt=""></a> <a href="LinkURL">Veteran reporter Wallace remembered</a></div> Question: Why - in your opinion - do the AT user need to perceive the first link above as a link? Already today, HTML5 permits us make the link presentational. And so, what is the difference between making it presentational and making it a an image? For example, imagine that the above <img> did not have an empty @alt but one which said "Studio photo of a slightly younger Mike Walace." In fact John Foliot discusses a similar case here: <http://john.foliot.ca/aria-hidden>. Though John only discusses it from a duplicate links perspective. Like I described above, the image might be good in itself, but unclear as a "link image". In which case *one way* to remove the confusion can be through doing <a role=img>. -- Leif Halvard Silli
Received on Monday, 9 April 2012 13:41:19 UTC