W3C home > Mailing lists > Public > public-html-a11y@w3.org > December 2010

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

From: Steve Faulkner <faulkner.steve@gmail.com>
Date: Fri, 24 Dec 2010 09:37:22 +0000
Message-ID: <AANLkTim8LKAF7gJ54pcoNMC5QazPMgnKxqVMRnDBu_hw@mail.gmail.com>
To: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
Cc: Jonas Sicking <jonas@sicking.cc>, HTMLWG WG <public-html@w3.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>, David Bolter <dbolter@mozilla.com>, Marco Zehe <marco.zehe@googlemail.com>, Richard Schwerdtfeger <schwer@us.ibm.com>, Cynthia Shelly <cyns@microsoft.com>
Hi Ben, I still don't see the issue, if the user agent is adding
interactivity, its up to the user agent to provide the expose the
appropriate role, name and state info, regardless of what the author
has done.

> This makes the results of applying role="presentation" highly non-determined.

when the user agent add stuff not provided by the author, then i would
suggest it makes the results of the use of any native element or ARIA
role 'highly non-determined'

best regards
Stevef


On 24 December 2010 09:24, Benjamin Hawkes-Lewis
<bhawkeslewis@googlemail.com> wrote:
> On Fri, Dec 24, 2010 at 9:03 AM, Steve Faulkner
> <faulkner.steve@gmail.com> wrote:
>> where is the use case for adding presentation to it when you make the
>> list collapsible?
>>
>> you state:
>>
>> "and provided a focusable button with a plus symbol for unrolling them."
>>
>> so the button semantic should be exposed and the state of the list
>> (expanded/collapsed) where does the use of presentation fit into this
>> or cause an issue?
>>
>> besides it looks very much like a place to use the details element no?
>>
>>> Perhaps role="presentation" should be restricted to the "table"
>>> element, as this is the element most widely abused for its
>>> presentational qualities?
>>
>> there are good reasons to allow presentation on other elements such as lists:
>> http://www.w3.org/Bugs/Public/show_bug.cgi?id=10450#c6
>>
>>>This doesn't absolutely solve the problem
>>> (in that UAs might build focusable UIs on top of table semantics, e.g.
>>> allow column headers to be focused for native sorting)
>>
>> use grid > columheader
>
> Perhaps I wasn't clear enough: I'm talking about situations (like with
> Opera Mini and UC Browser) where the user agent *not* the author makes
> lists collapsible and generates a button to expand them. Authors
> cannot fix this situation by adding more ARIA roles, since they are
> not generating the focusable UI - the user agent is, based purely on
> the semantic of list (just as user agents generate UI for buttons
> based purely on the semantic of button).
>
> The use case in the bug assumes that authors can determine what parts
> of a page the user agent makes interactive ("Since the links are the
> interactive parts in this widget"). Ultimately, they can't. This makes
> the results of applying role="presentation" highly non-determined.
>
> --
> Benjamin Hawkes-Lewis
>



-- 
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 09:38:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:42:27 GMT