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

HI Rich,

I do think browser bugs should be created as the current behaviour causes
problems for screen readers at the moment (if role="presentation") is on an
input (for example).
and I do think that the HTML5 spec should not allow role="presentation" to
be conforming on interactive controls and form controls.


regards
steve

On 22 December 2010 14:29, Richard Schwerdtfeger <schwer@us.ibm.com> wrote:

>  Hi Steve,
>
> Being pragmatic, we are not going to be able to validate a document based
> on what is focusable because due to support for tabindex="-1". This is
> simply something the browser needs to handle in their API mapping guide.
> That is how we addressed this in the ARIA implementation guide.
>
> So, I don't think a bug needs to be generated. The ARIA spec. is clear. We
> absolutely need to create a normative implementation guide for HTML 5 and
> ARIA. It will include things like this.
>
> Rich
>
>
> Rich Schwerdtfeger
> CTO Accessibility Software Group
>
> [image: Inactive hide details for Steve Faulkner ---12/22/2010 04:14:18
> AM---Hi all, as per the ARIA spec [1] and implementaion guide []Steve
> Faulkner ---12/22/2010 04:14:18 AM---Hi all, as per the ARIA spec [1] and
> implementaion guide [2]
>
> From: Steve Faulkner <faulkner.steve@gmail.com>
> To: HTMLWG WG <public-html@w3.org>, HTML Accessibility Task Force <
> public-html-a11y@w3.org>
> Cc: David Bolter <dbolter@mozilla.com>, Marco Zehe <
> marco.zehe@googlemail.com>, Richard Schwerdtfeger/Austin/IBM@IBMUS,
> Cynthia Shelly <cyns@microsoft.com>
> Date: 12/22/2010 04:14 AM
> Subject: role=presentation must not be applied to focusable elements
> ------------------------------
>
>
>
> 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?
> --
> with regards
>
> Steve Faulkner
> Technical Director - TPG
>
> www.paciellogroup.com | www.HTML5accessibility.com<http://www.html5accessibility.com/>|
> www.twitter.com/stevefaulkner
> HTML5: Techniques for providing useful text alternatives -
> dev.w3.org/html5/alt-techniques/
> Web Accessibility Toolbar -
> www.paciellogroup.com/resources/wat-ie-about.html
>
>


-- 
with regards

Steve Faulkner
Technical Director - TPG

www.paciellogroup.com |
www.HTML5accessibility.com<http://www.html5accessibility.com/>|
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html