W3C home > Mailing lists > Public > public-pfwg@w3.org > October 2014

Re: ARIA role on HTML ul

From: Alexander Surkov <surkov.alexander@gmail.com>
Date: Thu, 9 Oct 2014 10:47:29 -0400
Message-ID: <CA+epNscokahTQA9Bi+8d_mfwMhWEgqodhV5iL=m21R23ihemFQ@mail.gmail.com>
To: Joseph Scheuhammer <clown@alum.mit.edu>
Cc: 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>, "W3C WAI Protocols & Formats" <public-pfwg@w3.org>
Right, the table element in accessible tree was supposed to have role
button.

Ok, role="button" wasn't a good example because of presentational children
thing but we could replace it on any other ARIA role delivering different
semantics, for example, role="dialog" would work. In that case, it'd be
useful to figure out wanted behavior for children elements. That's first
issue.

A second issue is how we should proceed structural children of elements
having ARIA role of "close" semantics
(examples)
<table role="grid">
  <tr><td>grid cell</td>/tr>
</table>
<ul role="menu">
  <li>menu item</li>
</ul>
Iirc generic accessibles (neutral role accessibles) in trees of compound
elements are not allowed by ARIA in general (for example tablist is
supposed to contain tabs only). Having no accessible for children means the
text will be jammed by screen reader. So, making assumptions about role for
structural children elements sounds a bit scary but safe alternatives have
seemingly no sense.

Thanks.
Alexander.

On Thu, Oct 9, 2014 at 9:49 AM, Joseph Scheuhammer <clown@alum.mit.edu>
wrote:

> 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 14:47:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:45:09 UTC