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 -

Received on Thursday, 9 October 2014 13:49:34 UTC