Re: ARIA role on HTML ul

Making long story short :) Adding more guessing on browser side may be nice
but makes things tricky so if we can go with something simple like
do not expose native semantics of descendant structure if the element
semantics was overriden, expose generic accessibles only for descendant
structure to avoid text jamming when needed.

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

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