- From: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
- Date: Thu, 23 Jun 2016 16:08:23 +0000
- To: Birkir Gunnarsson <birkir.gunnarsson@deque.com>, Richard Schwerdtfeger <richschwer@gmail.com>
- CC: ARIA Working Group <public-aria@w3.org>
I agree, this is actually how I've been recommending developers build trees and menus for years, and it always works reliably. I understand the difficulty with backwards compatibility, so hopefully we can discuss a design pattern going forward that presents the least amount of problems in the future. Bryan Garaventa Accessibility Fellow SSB BART Group, Inc. bryan.garaventa@ssbbartgroup.com 415.624.2709 (o) www.SSBBartGroup.com -----Original Message----- From: Birkir Gunnarsson [mailto:birkir.gunnarsson@deque.com] Sent: Thursday, June 23, 2016 6:48 AM To: Richard Schwerdtfeger <richschwer@gmail.com> Cc: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>; ARIA Working Group <public-aria@w3.org> Subject: Re: Regarding children presentational in prep: Agenda: June 23, 2016 WAI-ARIA Working Group It depends where authors put the ARIA roles. Taking the example of a tree item (I think we can insert any of the others). If role="treeitem" is put on the <li> tags directly, then this is a problem. But what if role="treeitem" is put on an element inside the <li> element, and the <li> element is marked as presentational? That way the element with role="treeitem" does not own anything. Compare: <ul role="tree"> <li role="treeitem">item 1</li> <li id="item2" role="treeitem" aria-expanded="false">item 2 <ul role="group" aria-labelledby="item2"> <!-- owned by tree item 2 --> <li role="treeitem">Sub item 1</li> </ul> <!-- end of owned stuff -> </li> </ul> and <ul role="tree"> <li role="presentation"><span role="treeitem">item 1</span></li> <li role="presentation"><span id="item2" role="treeitem" aria-expanded="false">Tree item 2</span> <ul role="group" aria-labelledby="item2"> <!-- not owned by treeitem 2 --> <li role="presentation"><span role="treeitem">Sub item 1</span></li> </ul> </li> </ul> Is my understanding correct here, that this implementation allows children of treeitem to be presentational while still using the list structure as the basis for the tree? Granted, this may not solve the problem, at least not the problem of backwards compatibility, but I believe it is an implementation that does not conflict with presentational children of treeitems. On 6/23/16, Richard Schwerdtfeger <richschwer@gmail.com> wrote: > Great summary Bryan. Thank you for pulling that together. > > I think the difficult problem we are having with treeitem, menuitem, > menuitemcheckbox, and menuitemradio is that developers are using HTML > lists as the basis for contstructing these so that they also have the > subtree or submenu as descendants. Making the descendants > presentational means that you are not able to navigate to these descendants - even in a virtual buffer. > The problem we have is that we cannot say that they are not navigable > when people are building these times of widgets as they get structure > from the HTML lists for free. > > In this instance, what I mean by navigable is that we can’t get access > to the discrete objects (keyboard, virtual buffer, etc.). > > I understand that people overload these items but I know of no good > way of making the descendants presentational without breaking > something else. Even if we said the descendants were separate entities > (treated not as children) we will most certainly run into problems. trees are one example. > > Rich > >> On Jun 22, 2016, at 6:47 PM, Bryan Garaventa >> <bryan.garaventa@ssbbartgroup.com> wrote: >> >> Hi, >> In prep for the Caucus call tomorrow, I wanted to summarize what is >> being proposed here regarding children presentational, because some >> side threads seem to have derailed what the intent is for this. >> >> Firstly, this is being proposed for single focus non-composite >> widgets, and is meant to more accurately reflect what is already >> happening by assistive technologies when interacting with these >> controls. Moreover children presentational applies to implicit roles >> too and not just explicit ARIA roles. >> >> A simple example of this is role="button", since this is already >> children presentational in the spec. Such a container may include any >> type of markup, including headings, tables, lists, and so on. >> Nevertheless, when an assistive technology interfaces with this >> control type by focusing to it, it is a button, and not a heading, >> not a table, not a list, and it is not all of these things at the same time. It is simply a button. >> >> The same concept should be true for the roles checkbox, option, >> radio, switch, and tab. >> >> The option role was brought up as a possible exception early on due >> to the need to extend this in the future, but this would need to be >> done in 2.0 because the current mappings don't support this. However >> children presentational does need to be declared explicitly here too >> for 1.1 in order to match what the present mappings to the HTML >> option element currently reflect. >> >> There are four other roles also in the proposal for children >> presentational, these are treeitem, menuitem, menuitemcheckbox, and >> menuitemradio. >> >> The only reason why these are problematic at present is because >> technically treeitem roles may include child treeitem roles, and >> menuitem roles may include relevant menuitem roles. >> >> So to address these last four, children presentational would need to >> include specific caveats to allow for allowed child roles, which we >> need to talk about. >> >> Nevertheless, not having children presentational set on these four >> roles is causing issues across many ATs where the addition of native >> structural markup is bleeding through to AT users and causing these >> control types to behave unreliably for those that need to use them, >> which is making these controls confusing in some cases and impossible >> to use in others. So we do need to find a solution to this. >> >> The spinbutton role was removed from this proposal because there is a >> desire to make it composite. Currently the spec is not written to >> support this and changes would be needed to do this, because it's not >> clear where and what attributes are needed and how focus should be >> handled, but this should be broken out into another action item. >> >> The goal here is to make these controls work more reliably and to >> clear up ambiguities that are causing issues all across the web by >> authors and AT venders about how these controls are supposed to work. >> >> This will also set the stage for extending these controls for ARIA >> 2.0 by using this as a platform from which to add upon, such as >> adding composite capability where needed in the future. >> >> Hopefully this clears up what is actually being discussed. >> >> Kind regards, >> Bryan >> >> >> Bryan Garaventa >> Accessibility Fellow >> SSB BART Group, Inc. >> bryan.garaventa@ssbbartgroup.com >> <mailto:bryan.garaventa@ssbbartgroup.com> >> 415.624.2709 (o) >> www.SSBBartGroup.com <http://www.ssbbartgroup.com/> >> >> From: Richard Schwerdtfeger [mailto:richschwer@gmail.com >> <mailto:richschwer@gmail.com>] >> Sent: Tuesday, June 21, 2016 1:27 PM >> To: ARIA Working Group <public-aria@w3.org >> <mailto:public-aria@w3.org>> >> Subject: Agenda: June 23, 2016 WAI-ARIA Working Group >> >> Agenda: June 23, 2016 WAI-ARIA Working Group >> >> Time of meeting is 12:30PM EST, 9:30AM PST, 16:30 UTC, duration is >> 1.5 hours >> >> Webex: >> https://mit.webex.com/mit/j.php?MTID=m5d67b552441a72bd1f52d696ad273d2 >> e >> <https://mit.webex.com/mit/j.php?MTID=m5d67b552441a72bd1f52d696ad273d >> 2e> US Toll Number: +1-617-324-0000 Access code:640 582 571 (Mobile >> Auto Dial: >> +1-617-324-0000,,,640582571#) >> >> IRC: server: http://irc.w3.org/ <http://irc.w3.org/> , port: 6665, >> channel: #aria. >> Agenda: >> >> Remaining items needed addressing to go to a “pseudo last call draft” >> 1. CFC Results: >> Action 2067 aria-owns >> - CFC: >> https://lists.w3.org/Archives/Public/public-aria-admin/2016Jun/0043.h >> tml >> <https://lists.w3.org/Archives/Public/public-aria-admin/2016Jun/0043.html> >> - https://www.w3.org/WAI/ARIA/track/actions/2067 >> <https://www.w3.org/WAI/ARIA/track/actions/2067> >> Action 2080 Password role restriction regarding read-only elements: >> - CFC: >> https://lists.w3.org/Archives/Public/public-aria-admin/2016Jun/0029.h >> tml >> <https://lists.w3.org/Archives/Public/public-aria-admin/2016Jun/0029.html> >> - https://www.w3.org/WAI/ARIA/track/actions/2080 >> <https://www.w3.org/WAI/ARIA/track/actions/2080> >> Action 2084: presentational children: CFC: >> https://lists.w3.org/Archives/Public/public-aria-admin/2016Jun/0028.h >> tml >> <https://lists.w3.org/Archives/Public/public-aria-admin/2016Jun/0028.html> >> - CFC: >> https://lists.w3.org/Archives/Public/public-aria-admin/2016Jun/0028.h >> tml >> <https://lists.w3.org/Archives/Public/public-aria-admin/2016Jun/0028.html> >> - https://www.w3.org/WAI/ARIA/track/actions/2084 >> <https://www.w3.org/WAI/ARIA/track/actions/2084> >> - A lot of discussion - no consensus Action 2085: Spin Button >> Composite Widget >> - CFC: >> https://lists.w3.org/Archives/Public/public-aria-admin/2016Jun/0044.h >> tml >> <https://lists.w3.org/Archives/Public/public-aria-admin/2016Jun/0044. >> html> >> >> - https://www.w3.org/WAI/ARIA/track/actions/2085 >> <https://www.w3.org/WAI/ARIA/track/actions/2085> >> 2. Action 2069: Changes to Separator role >> - https://www.w3.org/WAI/ARIA/track/actions/2069 >> <https://www.w3.org/WAI/ARIA/track/actions/2069> >> - >> http://rawgit.com/w3c/aria/action2069-separator/aria/aria.html#separa >> tor >> <http://rawgit.com/w3c/aria/action2069-separator/aria/aria.html#separ >> ator> >> Note: I had approved Matt’s changes to him prior to vacation so I am >> not the hold up. >> 3. Action 2082: links to APG >> - https://www.w3.org/WAI/ARIA/track/actions/2082 >> <https://www.w3.org/WAI/ARIA/track/actions/2082> >> - Recommend this be moved to an ARIA 1.2. APG will not be >> done until the fall and we need to wrap 4. Wrapping up Password role >> - Use cases have been provided >> - See discussion on list June 21: >> https://lists.w3.org/Archives/Public/public-aria/2016Jun/ >> <https://lists.w3.org/Archives/Public/public-aria/2016Jun/> >> 5. Review Open Action Items and Issues (Many overdue items - need to >> get new dates and determine if must reassign) >> - http://www.w3.org/WAI/ARIA/track/products/17 >> <http://www.w3.org/WAI/ARIA/track/products/17> >> References: >> >> >> ARIA Test Plan Action Items: >> >> http://www.w3.org/WAI/PF/Group/track/products/5 >> <http://www.w3.org/WAI/PF/Group/track/products/5> >> >> ARIA Implementation Guide: >> >> http://www.w3.org/WAI/ARIA/track/products/23 >> <http://www.w3.org/WAI/ARIA/track/products/23> >> ARIA Name Computation Issues and Actions: >> >> http://www.w3.org/WAI/ARIA/track/products/26 >> <http://www.w3.org/WAI/ARIA/track/products/26> >> >> ARIA Test Report: >> >> https://www.w3.org/WAI/PF/testharness/testreport?testsuite_id=1 >> <https://www.w3.org/WAI/PF/testharness/testreport?testsuite_id=1> >> >> ARIA 1.1 Test Plan Issues and Actions: >> >> http://www.w3.org/WAI/ARIA/track/products/25 >> <http://www.w3.org/WAI/ARIA/track/products/25> >> >> ARIA 1.1 Test Harness: >> >> https://www.w3.org/WAI/PF/testharness/testcases?testsuite_id=4 >> <https://www.w3.org/WAI/PF/testharness/testcases?testsuite_id=4> >> >> WAI-ARIA Extension Process: >> >> https://www.w3.org/WAI/PF/wiki/ARIAExtensions >> <https://www.w3.org/WAI/PF/wiki/ARIAExtensions> >> >> ARIA Working Group Decision Policy >> >> https://www.w3.org/WAI/ARIA/decision-policy >> <https://www.w3.org/WAI/ARIA/decision-policy> >> >> Minutes Last Meeting: >> https://www.w3.org/2016/06/16-aria-minutes.html >> <https://www.w3.org/2016/06/16-aria-minutes.html> > -- Birkir Gunnarsson, CPACC Senior Accessibility Subject Matter Expert | Deque Systems 2121 Cooperative Way, Suite 210 Herndon, VA, 20171 Ph: (919) 607-27 53 Twitter: @birkir_gun
Received on Thursday, 23 June 2016 16:08:58 UTC