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

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

Received on Friday, 24 December 2010 09:26:31 UTC