- From: <bugzilla@jessica.w3.org>
- Date: Sat, 05 Mar 2011 03:34:20 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11956 --- Comment #10 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> 2011-03-05 03:34:19 UTC --- (In reply to comment #0) > s per the ARIA spec [1] and implementaion guide [2] > > "If an element with a role of presentation is focusable, user agents > MUST ignore the normal effect of the role and expose the element with > implicit native semantics, in order to ensure that the element is both > understandable and operable." > > [1]http://www.w3.org/WAI/PF/aria/roles#presentation > [2] http://www.w3.org/TR/wai-aria-implementation/#mapping_role > > I agree with the above, but currently the HTML5 spec allows > role="presentation" on any element (including focusable elements) You seem to to think that *ARIA 1.0* says that role=presentation should not be added to focusable elements. The way I read ARIA 1.0, it only says that role=presentation on focusable element simply leads to a different result on focusable elements. I think the ARIA spec text that you quoted above, is mostly related to inheritance. E.g. if we do this: <div role=presentation><a href=link>text</a></div> Then the <a> would also get a presentation role - inherited from the parent, but without loosing its "implicit native semantics". If HTML5 were to say anything about my example above, then what should it say? That authors in this case must apply a non-presentational role to the anchor element - for instance role=link ? -- 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, 5 March 2011 03:34:21 UTC