Re: role=presentation must not be applied to focusable elements

On Dec 22, 2010, at 3:13 AM, Steve Faulkner wrote:

> Hi all,
> as 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.
> 
> I think bugs need to be filed on the browsers and on the HTML5 spec,
> anybody disagree?

In Safari on Mac, the set of elements that is actually focusable depends on user preferences. There are at least three different modes:

1) System "Full Keyboard Access" preference is set to "Text Boxes and Lists Only", and Safari "Press Tab to highlight each item on a webpage" preference is unchecked. In this case, only text fields, list boxes and pop-up menus are in the tab cycle.

2) System "Full Keyboard Access" preference is set to "All Controls", and Safari "Press Tab to highlight each item on a webpage" preference is unchecked. In this case, in addition to 2, all other controls (including buttons, checkboxes, etc) are in the tab cycle, but links are not.

3) Safari "Press Tab to highlight each item on a webpage" preference is checked (regardless of the system setting). In this case, in addition to the items in 2, links are also in the tab cycle.

In Safari on iOS, these settings don't exist, and there is no cycle, but some controls can be focused by tapping on them (I think closely matching the set that is keyboard-focusabkle in #1).

It would certainly be possible to ignore role="presentation" on any element that is focusable for any reason, and a bug to that effect would be welcome at <http://bugs.webkit.org/>. As for the HTML5 validity rules, I am not sure what the right thing is. The set of elements that is focusable can vary between platforms, between browsers, and between different modes of the same browser. The validator cannot predict what will be focusable in the actual operating environment. Thus, I think perhaps it is best to make role="presentation" valid on anything, but require browsers to ignore it when the actual element would be focusable. The problem with this is that it then becomes unpredictable what your accessibility tree would look like. But I don't think we can fix that without either changing ARIA, or changing browsers to make the same elements focusable under all circumstances all the time (something I expect the Safari team is not willing to do).

Regards,
Maciej

Received on Thursday, 23 December 2010 07:39:50 UTC