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

thanks for you feedback dave,
While I don't agree this it is desirable behaviour to allow form
controls to have their role removed while still being focusable and
able to be interacted with, (another example: checkbox still exposes
the checked state) if other implementors feel likewise, then it would
suggest that the ARIA spec and implementaion guide will need to change
at some point to allow role="presentation" to overide native roles on
form controls.

> I find the Chrome behavior interesting... to move
> focus to the parent. Does this happen even when not launched in accessible
> mode?

am not really able to check since inspect tools only work when chrome
is in accessible mode.

best regards
steve

On 22 December 2010 14:49, David Bolter <dbolter@mozilla.com> wrote:
> Right or wrong, exposing a role string (BSTR) for roles that don't have any
> fathomable MSAA role mapping is a FF tradition that AT now expects. As for
> exposure of the object, I don't expect we will change our heuristic of
> always exposing focusable elements (except I'm still mulling this over for
> aria-hidden subtrees). I find the Chrome behavior interesting... to move
> focus to the parent. Does this happen even when not launched in accessible
> mode?
>
> Cheers,
> David
>
> On 22/12/10 5:13 AM, Steve Faulkner wrote:
>>
>> In firefox the input is still focusable and exposes a role of
>> presentation "Role: "presentation" [ BUG? State/Role should not be a
>> string ]"
>
>



-- 
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 Wednesday, 22 December 2010 15:02:25 UTC