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

Hi Ben,

> Hmm … thinking about it, that provision is rather dangerous.

I don't understand where the issue is,

if you have

> <ul>
>    <li><a href="foo">Foo</a></li>
>    <li>Bar</li>
>    <li>Baz</li>
> </ul>

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

regards
stevef

On 24 December 2010 08:18, Benjamin Hawkes-Lewis
<bhawkeslewis@googlemail.com> wrote:
> On Fri, Dec 24, 2010 at 7:13 AM, Steve Faulkner
> <faulkner.steve@gmail.com> wrote:
>> 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."
>
> Hmm … thinking about it, that provision is rather dangerous.
>
> In some UAs it would lead to role="presentation" being ignored on
> structural elements because they allow the structural elements to
> receive some sort of focus.
>
> Opera Mini 3 introduced "content folding".
>
> http://www.opera.com/press/releases/2006/11/28/
>
> http://www.youtube.com/watch?v=lzTlmedXAlo
>
> To reduce the amount of scrolling, it rolled up long lists of links
> and provided a focusable button with a plus symbol for unrolling them.
> For example:
>
> <ul>
>    <li><a href="foo">Foo</a></li>
>    <li>Bar</li>
>    <li>Baz</li>
> </ul>
>
> Would be rolled up into a presentation like:
>
>    Foo [+]
>
> Move focus to the [+] and activate it, and you get:
>
>    Foo
>    Bar
>    Baz
>
> UC Browser provides a similar feature in it's adaptive view:
>
> http://www.ucweb.com/English/UCbrowser/OperatingSkills.html#4
>
> UAs are free to build focusable UIs on top of structural elements and
> will then be required to ignore role="presentation".
>
> This means authors cannot rely on role="presentation" being applied.
> For interoperability, we should arguably discourage them using it.
>
> Perhaps role="presentation" should be restricted to the "table"
> element, as this is the element most widely abused for its
> presentational qualities? 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) but at least
> restricts it to one element.
>
> ARIA could try to mandate that UAs apply formatting and ignore
> semantics for all elements with role="presentation". Defining
> "formatting" here could be problematic though.
>
> --
> 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:05:39 UTC