RE: aria-ISSUE-1006 (children presentational = true not consistent): The roles that include children presentational = true are not consistent [ARIA 1.1]

I understand all of your points, but the nesting of interactive widget roles within many of these roles are causing accessibility issues when encountered.

I've seen implementations where people are putting regions and articles within menuitems, of people embedding radios within links, checkboxes within radios, forms within treeitems, etc.

I understand that some roles are needed as not being presentational, however the spec does not distinguish between the ones that are needed versus those that are not valid for that widget type.

As a result, the spec implies that you can put anything in there and it will just be accessible, and this is not the case when ATs encounter them, they just end up being so confusing that nobody can use them.


-----Original Message-----
From: James Craig [mailto:jcraig@apple.com] 
Sent: Wednesday, January 20, 2016 1:00 AM
To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
Cc: Accessible Rich Internet Applications Working Group <public-aria@w3.org>
Subject: Re: aria-ISSUE-1006 (children presentational = true not consistent): The roles that include children presentational = true are not consistent [ARIA 1.1]


> On Jan 19, 2016, at 12:43 PM, Accessible Rich Internet Applications Working Group Issue Tracker <sysbot+tracker@w3.org> wrote:
> 
> aria-ISSUE-1006 (children presentational = true not consistent): The roles that include children presentational = true are not consistent [ARIA 1.1]
> 
> http://www.w3.org/WAI/ARIA/track/issues/1006
> 
> Raised by: Bryan Garaventa
> On product: ARIA 1.1
> 
> Since I didn't get any information against, I'll file this as an official issue.
> 
> According to the children presentational description at http://www.w3.org/TR/wai-aria-1.1/#h-childrenarepresentational
> Embedded child roles are not exposed by the user agent, but instead a flat labelling mechanism is used instead no matter what type of content is contained within these roles.
> 
> Currently only the following roles include this property:
> button
> img

This should be corrected in the spec at some point. Not all images are chidrenPresentational.

> math

This should be corrected in the spec at some point. math != chidrenPresentational. There could be an ARIA math module to match MathML. Or the flat math role should be deprecated in favor of MathML.

The native implementation of MathML on iOS and OS X is only possible because WebKit exposes the full descendant tree.

> progressbar
> separator
> scrollbar
> slider
> 
> So this seems right, a button cannot include children with roles like link, slider, region, tablist, textbox, listbox, radio, checkbox, etc., because that wouldn't make any sense.

Clarifying: a button can include children like images, but since button is a leaf-level interactive node, the descendant semantics are flattened to a simple text label.

> So, with this logic, all of the following roles should also include children presentational = true .

I don't agree with most of the examples. Justification below. 

> checkbox
> combobox

Combobox has required descendants.

> menuitem
> menuitemcheckbox
> menuitemradio

Menuitems have optional descendants.

> option
> radio

Options/Radios have optional descendants.

> searchbox

Searchbox can have optional descendants.

> spinbutton

Spinbutton can have optional descendants.

> switch

This one is probably okay.

> tab

This one might be okay to flatten. I'd need to think about it some more.

> textbox

Textbox can have optional descendants.

> treeitem

Flattening all treeitems would prevent all subtrees from working.


> This seems logical, because none of the above roles are 'composite' widgets.
> https://www.w3.org/TR/wai-aria-1.1/#composite
> 
> There is one widget exception that is not clear, role=link, which I'm not certain if this is a good idea to do or not for this role.
> 
> E.G On one side, some roles such as heading may be useful, but at the same time, embedding child widget roles is problematic as is the embedding of structural roles such as list, table, region, etc., which is confusing when encountered.
> 
> A question was raised about treeitem too, but I don't know of any markup examples where embedding roles within this widget type is a good idea.

treeitem > group > treeitem is the expected way to nest trees in the DOM.

Received on Thursday, 21 January 2016 16:51:32 UTC