- From: James Nurthen <james.nurthen@oracle.com>
- Date: Tue, 24 May 2016 18:49:40 -0700
- To: public-aria-admin@w3.org
- Message-ID: <dc529028-dd05-ceda-f561-27174307e1bd@oracle.com>
On 5/24/2016 6:31 PM, Matt King wrote: > > Rich,please read .. I know it’s long, but it is important. > > Rich wrote: > > >People do create expandable trees and put interactive content within > treeitems. > > >Example: You could have a treeitem with a “more” button to show more > of the tree item. > > >The same for options. > > Yes, they can put a more button inside an option, but it is a bad > practice because, by definition, it will not work. There are ways > that do work, but putting the button inside the option is not one of them. > > The more button will get flattened because of how ARIA defines and > maps the option role. ARIA maps option the same way HTML option gets > mapped. The allowed content in HTML option is text. See: > > https://www.w3.org/TR/html5/forms.html#the-option-element > > The mapping for treeitem has the same effect. > Flattening the children for the accessible name is absolutely fine. We want a simple text string to be presented when we navigate through the options. However, we need the child elements to be available in the accessibility tree. When there are child elements available we provide a hint that the user can press a keystroke (F2, like in grids, or sometimes enter, depending if there is a default action or not) to switch to a mode where they can navigate amongst the child elements. They then use escape to exit that mode (just like in grids). If this children are presentational were introduced I am concerned that browsers would flatten the accessibility tree at this point so this no longer works > > Setting aside the mapping issue that hides the button role, how do you > propose the more button would receive focus and get activated within > the confines of the keyboard interaction models associated with > listbox and tree? Would it be focusable? The section of the ARIA spec > on focus management says that listbox and tree should manage focus and > that tab should move focus outside of the listbox or tree. The arrow > keys already perform other functions within listbox and tree. And, an > option or treeitem is not a composite so does not have its own focus > management scheme if focus were to move inside. > > Rich wrote: > > >I am concerned that we are closing the door shut on this too early > > >when it was not the case for ARIA 1.0. > > ARIA 1.0 closed the door, but it left off the tred that prevents the > cold from slipping underneath it. > > With all this said, I am not saying it is absolutely essential we make > the children presentational. We can address these design patterns and > issues in the APG and just tell people what works. But that leaves the > spec ambiguous. It does not make it clear why the things that do not > work do not work. It puts the APG on less clear footing. And, it > prevents conformance checkers from flagging code we know fails it > multiple ways. > > It is also important to note that with the changes to the grid role, > we solve the immediate issue of how to build some of these widgets. It > is very easy to turn a UL into a grid and make it work with a screen > reader. All the semantics are exposed and we have well defined focus > management and keyboard interaction models. We already have > implementations that are working. > > You can do the same for trees as well with treegrid, and it is > actually quite simple as long as you wrap each interactive element in > its own gridcell. It works with all the AX APIs and has interaction > expectations that AT could support. What we are missing in the case of > treegrud but will soon have are solid reference implementations that > theAT vendors can use to build support. > > Fixing the authoring problem you are talking about was exactly, > precisely, unequivocally the aim of issue 633 and its associated > actions. That is how we ended up with the changes to grid. Changing > grid was not the original path, but we ended up there and it has > already proven effective. > > Rich wrote: > > >Matt, we shattered the "well-defined interaction model" with combobox. > > If this were true, it would be irrelevant because that is a different > topic. It also would not reflect well on the group’s decision to > accept the proposals related to combobox. > > Specific reasons for regarding this claim about the interaction model > for ARIA 1.1 combobox as false are: > > 1.The same keyboard interactions for managing focus and selection in > combobox still work: > > a.The popup element still opens and closes using the same keyboard and > mouse mechanisms. > > b.A value is still set using the same keyboard/focus model. > > c.All the popup elements have well-defined interaction models and > their role is exposed through the AX API so that model can be exposed > to assistive technologies. > > 2.Very importantly: all mappings still work and the information > assistive technologies need is all there. > > 3.Bonus: No major tweeking is required for 1.1 combos to work in > practice. The most significant issue is the very special case > processing that some screen readers do for the escape key when focus > is inside a tree or grid that opens from a combo. > > Hth, > > Matt King > > *From:*Rich Schwerdtfeger [mailto:richschwer@gmail.com] > *Sent:* Tuesday, May 24, 2016 4:31 PM > *To:* Matt King <a11ythinker@gmail.com> > *Cc:* Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>; James > Nurthen <james.nurthen@oracle.com>; public-aria-admin@w3.org; Fred > Esch <fesch@us.ibm.com> > *Subject:* Re: 48 hour Call For Consensus regarding Resolutions from > the May 19, 2016 ARIA Working Group meeting > > Matt, we shattered the "well-defined interaction model" with combobox. > > People do create expandable trees and put interactive content within > treeitems. I am concerned that we are closing the door shut on this > too early when it was not the case for ARIA 1.0. > > Example: You could have a treeitem with a “more” button to show more > of the tree item. The same for options. > > Rich > > Rich Schwerdtfeger > > On May 24, 2016, at 6:24 PM, Matt King <a11ythinker@gmail.com > <mailto:a11ythinker@gmail.com>> wrote: > > Fred, Rich, and James, > > In practice, the children of option and treeitem elements already > behave as if they are presentational. This is true for all roles > mapped as inputs except composite inputs and text inputs. However, > composite widgets are mapped to desktop GUI components that have > well-defined interaction models and text inputs have their own > special accessible text interface for rendering the attributes of > their content to assistive technologies. > > ·Options and treeitems are defined in ARIA as singular input > elements. In this way, they are like the other subclasses of input > that are not also composite or text, i.e., checkbox, radio, > slider, and spinbutton. > > ·ARIA maps options and treeitems to desktop GUI components that do > not have either semantic or interactive children. > > ·Because of the option and treeitem mappings, most assistive > technologies do not provide reading modes that work inside of > option and treitem elements. They may provide ways of extracting > the text, but it is stringafied. > > ·There are no standardized interaction models for interacting with > content inside of an option or treeitem. Assistive tehcnologies > can not provide guidance to users if focus moves inside of an > option or treeitem like they can if it moves inside a composite or > dialog. > > Because option and treeitem have the above attributes but are not > formally defined as children presentational true, there is > confusion about what assistive technologies are capable of doing > with them, how checkers should treat them, and consequently, what > authors should be allowed to do with them. > > Net: assistive technologies treat option and treeitem the way they > do in desktop GUIs because that is how they are mapped. Because of > that, all content inside is effectively presentational. Changing > that would mean huge changes to ARIA. > > Accepting the proposal as written would bring the spec into line > with current real-world behaviors and limitations. It will enable > us to start fixing problems caused by this confusion. > > One of the problems we can fix right away is helping Fred and > James make their UIs accessible within the practical constraints > of ARIA 1.1. > > Please, let’s not continue to compound the problems we already > have by removing option and treeitem from this CFC. Including them > is extremely valuable to the clarity, consistency, and robustness > of both the specification and the authoring practices. > > BTW, Fred, one of the reasons I worked so hard on issue 633 to get > more flexibility and clarity for grid and dialog is to make > reliable accessibility feasible for the types of UIs you > described. I think we have the tools we need. They may not be100% > optimal, and they fall short of what I originally envisioned, but > they are a good step forward for a 1.1 release of the spec. > > Matt King > > *From:*Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com] > *Sent:*Tuesday, May 24, 2016 12:14 PM > *To:*James Nurthen <james.nurthen@oracle.com > <mailto:james.nurthen@oracle.com>>; public-aria-admin@w3.org > <mailto:public-aria-admin@w3.org> > *Subject:*RE: 48 hour Call For Consensus regarding Resolutions > from the May 19, 2016 ARIA Working Group meeting > > Can you point to an example of this? > > This type of implementation causes so many accessibility issues in > JAWS and NVDA and everywhere else that I’ve tested that I flag > this as a must-fix author error every time I come across it. > > I can’t think of an instance where this is a good idea, because > this maps to the same role type as the HTML option element. > > 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:*James Nurthen [mailto:james.nurthen@oracle.com] > *Sent:*Tuesday, May 24, 2016 12:02 PM > *To:*public-aria-admin@w3.org <mailto:public-aria-admin@w3.org> > *Subject:*Re: 48 hour Call For Consensus regarding Resolutions > from the May 19, 2016 ARIA Working Group meeting > > I object to option being in this list too (for similar reasons to > treeitem). > > We currently allow people to jump in and out of an "interaction" > mode in order to allow them to interact with the child elements. > If children presentational is added AT users will lose that ability. > > Regards, > > james > > On 5/24/2016 10:47 AM, Bryan Garaventa wrote: > > That’s fine with me, though I think we will need to have a > different proposal to deal with role=treeitem separately. > > The problem being that currently no embedded controls within > treeitems are accessible, since the role=tree widget is > treated as one form field. > > E.G > > http://whatsock.com/tsg/Coding%20Arena/ARIA%20Trees/Tree%20(External%20XML)/demo.htm > <http://whatsock.com/tsg/Coding%20Arena/ARIA%20Trees/Tree%20%28External%20XML%29/demo.htm> > > (Reproduceable in Firefox using JAWS and NVDA) > > And it’s not clear how anything that is embedded within such > controls should be discoverable or even intuitively interacted > with. > > 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:*Rich Schwerdtfeger [mailto:richschwer@gmail.com] > *Sent:*Tuesday, May 24, 2016 9:47 AM > *To:*Bryan Garaventa<bryan.garaventa@ssbbartgroup.com> > <mailto:bryan.garaventa@ssbbartgroup.com> > *Cc:*Fred Esch<fesch@us.ibm.com> <mailto:fesch@us.ibm.com>; > ARIA Working Group<public-aria-admin@w3.org> > <mailto:public-aria-admin@w3.org> > *Subject:*Re: 48 hour Call For Consensus regarding Resolutions > from the May 19, 2016 ARIA Working Group meeting > > I agree. I sent out what was resolved at the meeting and had > the same thoughts but I was not on the call and was going to > raise the same exception. We will have the same issues we have > with options and lists. > > +1 to keeping the proposal minus treeitem. > > Rich > > Rich Schwerdtfeger > > On May 24, 2016, at 10:53 AM, Bryan Garaventa > <bryan.garaventa@ssbbartgroup.com > <mailto:bryan.garaventa@ssbbartgroup.com>> wrote: > > Currently role=treeitem is not a composite widget, and as > such nothing rendered within these containers is > accessible. So not including role=treeitem in this list > will not solve this problem. > > 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:*Fred Esch [mailto:fesch@us.ibm.com] > *Sent:*Tuesday, May 24, 2016 4:21 AM > *To:*Rich Schwerdtfeger <richschwer@gmail.com > <mailto:richschwer@gmail.com>> > *Cc:*ARIA Working Group <public-aria-admin@w3.org > <mailto:public-aria-admin@w3.org>> > *Subject:*Re: 48 hour Call For Consensus regarding > Resolutions from the May 19, 2016 ARIA Working Group meeting > > Rich, > > I would like to see treeitem dropped from the list. No one > wants to use treegrid and we see UIs with trees of complex > widgets which should naturally use tree style navigation > between the them. If we include treeitem in the list then > you would not be able to call something a tree, that looks > like a tree and you want it to navigate like a tree, if > the leaves were complex controls that a user could choose > to leave visible. Again, no one will ever call a tree of > complex widgets a treegrid when where there is no concept > of rows in the layout. > > Suggested solutions for a tree that are compatible with > treeitem only having presentational children are work > arounds such as having the widget appear in a dialog when > you click the treeitem. These 'solutions' are not be > practical when you have flows, card layouts, or block > chains that have branching. We are seeing lots of card > layouts, block chains and relationships expressed in web > apps that would be negatively impacted by this restriction. > > Regards, > > Fred Esch > Watson, IBM, W3C Accessibility > > <image001.png> > > > > Watson Release Management and Quality > > > > <image002.gif>Rich Schwerdtfeger ---05/23/2016 04:06:45 > PM---This is a Call for Consensus (CfC) to the Accessible > Rich Internet Applications (ARIA) Working Group > > From:Rich Schwerdtfeger <richschwer@gmail.com > <mailto:richschwer@gmail.com>> > To:ARIA Working Group <public-aria-admin@w3.org > <mailto:public-aria-admin@w3.org>> > Date:05/23/2016 04:06 PM > Subject:48 hour Call For Consensus regarding Resolutions > from the May 19, 2016 ARIA Working Group meeting > > ------------------------------------------------------------------------ > > > > > This is a Call for Consensus (CfC) to the Accessible Rich > Internet Applications (ARIA) Working Group regarding the > following resolutions of the ARIA Working group. > > 1. Add children presentational true to checkbox, menuitem, > menuitemcheckbox, menuitemradio, option, radio, > spinbutton, switch, tab, and treeitem in response to Issue > 1006 > The meeting minutes are > here:https://www.w3.org/2016/05/19-aria-minutes.html > > If you object to this proposal, or have comments > concerning it, please respond by replying on list to this > message no later than 23:49 (midnight) Boston Time, > Wednesday, May 25, 2016. > > Regards, > > Rich > > — > Rich Schwerdtfeger, Email:richschwer@gmail.com > <mailto:richschwer@gmail.com> > CTO Accessibility IBM Software:http://www.ibm.com.able > <http://www.ibm.com.able/> > > The World Wide Web Consortium (W3C), Web Accessibility > Initiative (WAI) > Chair, Accessible Rich Internet > Applicationshttps://www.w3.org/WAI/ARIA > > Rich Schwerdtfeger > > > > > > > > > -- > Regards, James > > <image001.gif> <http://www.oracle.com/> > James Nurthen | Principal Engineer, Accessibility > Phone:+1 650 506 6781 <tel:+1%20650%20506%206781>| Mobile:+1 415 > 987 1918 <tel:+1%20415%20987%201918>| > Video:james.nurthen@oracle.com <mailto:james.nurthen@oracle.com> > OracleCorporate Architecture > 500 Oracle Parkway | Redwood Cty, CA 94065 > <image002.gif> <http://www.oracle.com/commitment>Oracle is > committed to developing practices and products that help protect > the environment > -- Regards, James Oracle <http://www.oracle.com> James Nurthen | Principal Engineer, Accessibility Phone: +1 650 506 6781 <tel:+1%20650%20506%206781> | Mobile: +1 415 987 1918 <tel:+1%20415%20987%201918> | Video: james.nurthen@oracle.com <sip:james.nurthen@oracle.com> Oracle Corporate Architecture 500 Oracle Parkway | Redwood Cty, CA 94065 Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment
Received on Wednesday, 25 May 2016 01:50:10 UTC