W3C home > Mailing lists > Public > public-aria@w3.org > January 2016

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

From: James Craig <jcraig@apple.com>
Date: Wed, 20 Jan 2016 00:59:37 -0800
Cc: Accessible Rich Internet Applications Working Group <public-aria@w3.org>
Message-Id: <10C4466D-C5D9-4418-9513-F0BE0DB8215F@apple.com>
To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>

> 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 Wednesday, 20 January 2016 09:00:13 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:23:18 UTC