Re: ARIA role on HTML ul

> 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.

I think the first issue is:  If an author uses an ARIA role on the 
<table> element, what happens to the roles of other <table> related 
elements, e.g., the <tr> elements?

Partial answer part 1:  The spec. doesn't say specifically how to handle 
an override of a table with another role, except in the case of 
@role="presentation" (or @role="none") [1].  In that case, the table's 
descendant elements ( <tbody>, <thead>, <tfoot>, <th>, <tr>, <td>, and 
<caption>) inherit the "presentation/none" role, unless the author 
provides an explicit @role for one of these elements.

Partial answer part 2:  There is a general rule about roles stated in 
the section on native host semantics [2].  Generally, the @role 
overrides the native host semantic:

"When a WAI-ARIA role is provided, user agents MUST use the semantic of 
the WAI-ARIA role for processing, not the native semantic, unless the 
role requires WAI-ARIA states and properties whose attributes are 
explicitly forbidden on the native element by the host language."

Given '<table role="dialog">', are there any states and properties of 
@role="dialog" [3] that are forbidden by the <table> element?  I don't 
see any.

I think the spec needs to speak to this issue.  The following is 
brainstorming and is a possible path forward.

Why is the author re-purposing the <table> element as a dialog?  There 
are two uses of <table>:  data tables and layout tables.  I think it's 
highly doubtful that the author is making a "dialog-data table".  It's 
more likely they are capitalizing on the layout provided by <table> for 
displaying their components of their dialog.  In that case, the 
situation relates to "partial answer 1", and is equivalent to:

<div role="table>
   <table role="presentation> ... </table>
</div>

That is, if the author's rational for re-purposing a table as a dialog 
for layout purposes, then the <table> semantics are those of a layout 
table.  The <table> descendant elements inherit the presentation role.

However, some caution is required.  If the author further re-purposes a 
<tr> of the table as a toolbar, again capitalizing on the layout of 
table rows, then that row has a role of toolbar, not the inherited 
presentation role.  For example:

<table role="dialog" aria-labelledby="title">
  <tr><th id="title">Preferences</th></tr>
  <tr role="toolbar"><td role="button">General</td><td 
role="button">Tabs</td><td role="button">Content</td><td 
role="button">Startup</td></tr>
...
</table>

This is consistent with the spec with respect to an inherited 
presentation role being overridden by an explicit @role.

> A second issue is how we should proceed structural children of 
> elements having ARIA role of "close" semantics

The issue here is the author has re-purposed a container element without 
providing the required descendant structure. At face value, that's an 
author error.  Unfortunately, it's dangerous to make inferences about 
what the author meant if they leave out that descendant structure.

> (examples)
> <table role="grid">
>   <tr><td>grid cell</td>/tr>
> </table>
> <ul role="menu">
>   <li>menu item</li>
> </ul>

The grid role is much "closer" semantically to a <table> than a menu 
role is to an unordered list.  A grid is defined as (my emphasis), " An 
interactive control which contains cells of *tabular* data arranged in 
*rows and columns* ..." [4].  Not providing the roles for the <tr> and 
the <td> is not an error since the mapping of <tr> and <td> is already 
"row" and "cell" [5], [6].

In the case the <ul role="menu">, the author must provide a 
@role="menuitem" if the <li> elements are to be re-purposed as 
menuitems. Adding the ARIA semantics is the least of the author's 
worries here.  They also have to have added the CSS and scripts to make 
the unordered list look and behave like a menu.  If the author did all 
that but left out the required descendant roles, a browser inferring 
which elements are the menuitems is a  risky gamble, since it depends on 
how the author has programmed the situation.  They could have used 
<div>s within the <li>s for the menuitems, for example.
> 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).

Regarding "tablist is supposed to contain tabs only".  ARIA doesn't 
state that.  It states that a tablist must have tabs as descendants, but 
it doesn't say that's the only thing tablists can contain.  For example, 
an author could include all the tab panels as descendants of the tablist 
container, or the tabs themselves could have "close buttons" as 
descendants, and still other descendant markup might be used for layout, 
and have @role="presentation".  It's just that if the author has 
declared a tablist, it must tab children either as DOM children, or via 
@aria-owns.

> 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.

Can you explain why the text collapses into one blob?  Even making an 
unordered list entirely presentational does not do that, e.g.,
<ul role="presentation">
  <li>Some text</li>
  <li>Some more text</li>
</ul>

The list items have an implicit @role="presentation", but the strings 
"Some text" and "Some more text" are separate nodes in the accessibility 
tree.  This is reminiscent of bugzilla 945435 [7], where placing 
role="presentation" on a table caused FF merge all the text, but that 
was later fixed.  Why wouldn't the same fix apply here?  And also apply 
to the case of the unordered list menu example?  The author mistakenly 
did not supply menutitems, but the text of the <li>s are still separate 
text nodes.


[1] http://rawgit.com/w3c/aria/master/aria/aria.html#presentation
[2] http://rawgit.com/w3c/aria/master/aria/aria.html#host_general_conflict
[3] http://rawgit.com/w3c/aria/master/aria/aria.html#dialog
[4] http://rawgit.com/w3c/aria/master/aria/aria.html#grid
[5] http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#el-tr
[6] http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#el-td
[7] https://bugzilla.mozilla.org/show_bug.cgi?id=945435

-- 
;;;;joseph.

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

Received on Thursday, 16 October 2014 13:19:41 UTC