W3C home > Mailing lists > Public > public-html-a11y@w3.org > March 2011

[Bug 11956] restrict use of role=presentation

From: <bugzilla@jessica.w3.org>
Date: Sat, 05 Mar 2011 03:34:19 +0000
To: public-html-a11y@w3.org
Message-Id: <E1PviG3-0004i3-Nh@jessica.w3.org>

--- 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 on the CC list for the bug.
Received on Saturday, 5 March 2011 03:34:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:55:53 UTC