Re: ARIA role on HTML ul

> If I understand right Thierry's idea was that such ARIA role should 
> result in role="presentation" applied to structure elements (like tr, 
> td or li elements). That means no accessible should be created for 
> them. I find this reasonable for tr, however td and li I'd say should 
> have some generic accessible (perhaps no nothing role) to avoid text 
> collapsing contained by li and td. 

This is a very important point. When presentation is inherited whether 
from the presentation role or from a role with children presentational is 
true, if text from all child elements are collapsed together, the content 
may become unreadable, depending on the type of child elements. 

A few versions of Firefox, I think between 18 and 24,  once had that 
problem with tables. Layout tables just became one giant string for screen 
reader users so a screen reader user could not distinguish among the 
various elements of the table. 

The way I read section 5.1.1 and 5.4.1 in the 1.0 UAIG,  Firefox was 
actually interpreting the specification correctly when it made the 
presentational table unreadable. Of course, I am now happy for the more 
"practical" implementation we have today. 


Matt King
IBM Senior Technical Staff Member
I/T Chief Accessibility Strategist
IBM BT/CIO - Global Workforce and Web Process Enablement 
Phone: (503) 578-2329, Tie line: 731-7398
mattking@us.ibm.com



From:   Joseph Scheuhammer <clown@alum.mit.edu>
To:     Alexander Surkov <surkov.alexander@gmail.com>, Thierry Koblentz 
<thierry.koblentz@gmail.com>, Marco Zehe <marco.zehe@gmail.com>, Léonie 
Watson <lwatson@paciellogroup.com>, Steve Faulkner 
<sfaulkner@paciellogroup.com>, Jason Kiss <jason@accessibleculture.org>, 
Joseph Scheuhammer <clown@alum.mit.edu>, 
Cc:     W3C WAI Protocols & Formats <public-pfwg@w3.org>
Date:   10/09/2014 06:49 AM
Subject:        Re: ARIA role on HTML ul



Hi Alex,

(Note:  I am cc'ing the public-pfwg list as Alex suggested):

Alex wrote:

> Hi, guys. Moving twitter discussion to email (maybe that should be 
> part of ARIA mail list).
>
> So, when you apply strong role to HTML table or HTML ul elements that 
> has different semantics than these elements then underlying structure 
> is not exposed but generic accessible with no role are created. That's 
> how it works in Firefox, I verified it by automated test we have [1]. 
> Example
>
> <table role="button">
>   <tr><td>content</td></tr>
> </table>
>
> accessible tree is:
> table (for table)
>   nothing (for tr)
>     nothing (for td)
>       text leaf (for text node)

If you look at the characteristics table for the button role 
(http://rawgit.com/w3c/aria/master/aria/aria.html#button), you will see 
an entry at the bottom labelled "Children Presentational" with the value 
"true".  The children of a button are all implicitly presentational. 
The element used, be it <table> or <ul>, doesn't matter; it's the button 
role that defines this. The definition of "Presentational Children" 
states that user agents SHOULD NOT expose the descendants of a role 
whose children are presentational 
(
http://rawgit.com/w3c/aria/master/aria/aria.html#childrenArePresentational
). 
Using your example,  the <tr>, <td>, all have a presentation role, and 
are effectively:

<table role="button">
   <tr role="presentation"><td role="presentation">content</td></tr>
</table>

I have a question about your accessible tree, though.  The button role 
has not been exposed anywhere.  Is this a typo?  Otherwise, the "nothing 
(for tr)", and "nothing (for td)"  is as expected with those descendants 
as presentational.


>
> Same is for HTML UL element I believe.
>
> If I understand right Thierry's idea was that such ARIA role should 
> result in role="presentation" applied to structure elements (like tr, 
> td or li elements). That means no accessible should be created for 
> them. I find this reasonable for tr, however td and li I'd say should 
> have some generic accessible (perhaps no nothing role) to avoid text 
> collapsing contained by li and td.
>
> Futhermore, Thierry's case was role="tablist" on UL. I'm not sure 
> whether this role overrides native semantics of HTML ul, I'd say it 
> rather enhance it. So maybe it would be more reasonable if HTML li 
> elements got role="tab" accessible automatically. At least no 
> accessible approach seems unpractical in this case.

It's an interesting idea that the <li> elements of a <ul role="tablist"> 
implicitly have the role="tab".  But, how dangerous is that assumption? 
What if the author puts an explicit role="tab" on some other element? 
As far as the current spec is concerned, putting role="tablist" on an 
element does not automatically propagate role="tab" to any of the 
tablist's descendants (nor role="tabpanel" for that matter).

>
> These are some general observations, I didn't check that with ARIA 
> spec. So cc'ing Joseph for ARIA spec wording interpretations :)
>
> Thanks.
> Alexander.
>
> [1] 
> 
http://mxr.mozilla.org/mozilla-central/source/accessible/tests/mochitest/tree/test_brokencontext.html?force=1


Hope that helps.

-- 
;;;;joseph.

'Array(16).join("wat" - 1) + " Batman!"'
            - G. Bernhardt -