- From: <bugzilla@jessica.w3.org>
- Date: Wed, 02 Feb 2011 11:16:38 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11956 Summary: restrict use of role=presentation Product: HTML WG Version: unspecified Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P2 Component: HTML5 spec (editor: Ian Hickson) AssignedTo: ian@hixie.ch ReportedBy: faulkner.steve@gmail.com QAContact: public-html-bugzilla@w3.org CC: mike@w3.org, public-html-wg-issue-tracking@w3.org, public-html@w3.org 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) and this is how it is implemented in Firefox, chrome and IE, they apply the presentation role to focusable elements. example: <p><input type="submit" role="presentation"></p> IE removes the input from the accessibility tree (Cannot get object from Focus event: [Error: AccessibleObjectFromEvent: hr=0x80004005 - Unspecified error]) but they are still focusable. In firefox the input is still focusable and exposes a role of presentation "Role: "presentation" [ BUG? State/Role should not be a string ]" (not the same behaviour as for non focusable elements) In chrome the focus is moved to the parent element the parent element role is exposed. -- 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, 2 February 2011 11:16:40 UTC