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

Hi Jonas,

I have also argued that what ARIA roles can be applied on interactive
elements should be limited which is clearly reflected in:
http://www.paciellogroup.com/blog/misc/HTML5/aria-html5-proposal.html

The ARIA spec does not prohibit the use of any roles on structural
elements such as headings, but it is
unequivocal about role=presentation in this case:

"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."

best regards
stevef

On 24 December 2010 02:12, Jonas Sicking <jonas@sicking.cc> wrote:
> Hi Steve,
>
> In other threads I know that you have argued that many ARIA roles show
> be allowed since scripts and CSS could produce the same behavior for
> non-AT users. For example in bug 10449 it is argued that role=checkbox
> should be allowed on <h1> since you can use CSS and script to make a
> <h1> look and act like a checkbox.
>
> However isn't that true in this case too? For example
>
> <input onfocus="blur()">
>
> is purely presentational since you can't interact with it to enter
> text. Shouldn't then role=presentation be allowed?
>
> Or do you simply disagree with both and think that bug 10449 should be
> WONTFIXed?
>
> / Jonas
>
> On Wed, Dec 22, 2010 at 2:13 AM, Steve Faulkner
> <faulkner.steve@gmail.com> 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?
>> --
>> with regards
>>
>> Steve Faulkner
>> Technical Director - TPG
>>
>> www.paciellogroup.com | 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 |
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

Received on Friday, 24 December 2010 07:14:36 UTC