- From: James Craig <jcraig@apple.com>
- Date: Wed, 20 Jan 2016 00:59:37 -0800
- To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
- Cc: Accessible Rich Internet Applications Working Group <public-aria@w3.org>
> 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