- From: James Nurthen <james.nurthen@oracle.com>
- Date: Thu, 26 May 2016 09:35:07 -0700
- To: public-aria@w3.org
- Message-ID: <21d0c2c1-fb87-f496-9c9c-dedee35944bf@oracle.com>
Rich, This is not my argument - I think you have me mixed up with others on this thread. Regards, james On 5/26/2016 8:44 AM, Rich Schwerdtfeger wrote: > I agree, that is the problem. We only have a tree widget structure. > Saying that you can’t go into a treeitem is as much a non-start as not > being able to go into a grid cell. > > I also don’t agree with James Nurthen’s statement that putting a > button inside a tree item “will not work”. > > - You can give it a tab index of “-1” and you can have a keyboard > shortcut to activate it. > - You could have a mode that puts you in the tree item (like we do > with grids) and navigate in the tree item. > > This is all JavaScript and it is completely doable. > > Sorry, I don’t buy the arguments requiring the descendants to be > presentational. > > Rich > > Rich Schwerdtfeger > > > > >> On May 26, 2016, at 7:35 AM, Fred Esch <fesch@us.ibm.com >> <mailto:fesch@us.ibm.com>> wrote: >> >> Matt, >> >> Trees are the only structure we have for trees. Treegrids are tables >> with twisties, not a tree. Here are some examples of treegrids (from >> googling treegrid). >> http://www.treegrid.com/Grid >> http://dev.sencha.com/deploy/ext-4.0.1/examples/tree/treegrid.html >> http://maxazan.github.io/jquery-treegrid/ >> https://dojotoolkit.org/reference-guide/1.10/dojox/grid/TreeGrid.html#dojox-grid-treegrid >> >> If I need a tree of widgets (and I don't want them laid out like a >> table) what do I use? >> >> Regards, >> >> Fred Esch >> Watson, IBM, W3C Accessibility >> <0E748335.gif> Watson Release Management and Quality >> >> >> >> <graycol.gif>Matt King ---05/25/2016 09:54:21 PM---James, I tested a >> listbox with 2 options, each option containing a link, a heading, a >> paragraph, and >> >> From:Matt King <a11ythinker@gmail.com <mailto:a11ythinker@gmail.com>> >> To:"'Bryan Garaventa'" <bryan.garaventa@ssbbartgroup.com >> <mailto:bryan.garaventa@ssbbartgroup.com>>, "'James Nurthen'" >> <james.nurthen@oracle.com <mailto:james.nurthen@oracle.com>>, >> <public-aria-admin@w3.org <mailto:public-aria-admin@w3.org>> >> Cc:"'Rich Schwerdtfeger'" <richschwer@gmail.com >> <mailto:richschwer@gmail.com>>, Fred Esch/Arlington/IBM@IBMUS >> Date:05/25/2016 09:54 PM >> Subject:RE: 48 hour Call For Consensus regarding Resolutions from the >> May 19, 2016 ARIA Working Group meeting >> >> ------------------------------------------------------------------------ >> >> >> >> James, I tested a listbox with 2 options, each option containing a >> link, a heading, a paragraph, and a toolbar with 2 buttons. >> >> I tested in Firefox, IE, Chrome, and Safari with JAWS, NVDA, and >> VoiceOver. >> >> We have about 80+% presentational implementation. The 20% that is not >> presentational is a screen reader disaster. Test result details below. >> >> No one should consider putting semantic elements inside options or >> treeitems and expect them to be presented as anything other than >> text, even if focus moves inside the option. And moving focus inside >> an option is an author error because option is not a composite and >> the allowed content for option is text. >> >> By design, chilcren of options and treeitems are already >> presentational. This is how ARIA 1.0 set them up. And, we should >> finish the job so we can clean up the 20% mess. >> >> The good news is, that if you do a 1/1 switch out to grid roles, it >> works on all platforms in all browsers. Screen readers that do >> automatic mode switching don’t yet switch modes exactly right all the >> time, but we can get that fixed. So, we have a robust solution for >> the use cases that James and Fred have raised. >> >> In the long term, I would not support changing treeitem and option to >> composites. That could really mess up their current use cases. If >> people are somehow not satisfied with the grid approaches, which do >> work very well, I would instead propose that we add listview and >> treeview roles that have composite child elements. That way, the >> screen readers will be able to render them in a manner completely >> different from listbox and tree-- more like grid and treegrid. >> >> Test Results: >> >> Chrom/Mac/VO: >> When reading, no semantics revealed. When interacting with the >> option, the text is readable but it is stringified. >> When tabbing to contained link and buttons: No semantics revealed. >> Focusable elements are silent. The ffirst time focus enters the >> option, the entire option is read instead of the label of the focused >> element. Current focus reports the text of the option for all >> contained elements. >> >> Safari/Mac/VO: >> When reading, no semantics revealed. When interacting with the >> option, the text is not present. >> When tabbing to contained link and buttons: No semantics revealed. >> Focusable elements are silent. The ffirst time focus enters the >> option, the entire option is read instead of the label of the focused >> element. Current focus reports the text of the option for all >> contained elements. >> >> Chrome/Win/JAWS/NVDA: >> When reading, no semantics revealed. Stringified text of the selected >> option is revealed. Selected state is revealed. >> When tabbing to contained link and buttons: No semantics revealed. >> Focusable elements are silent. The ffirst time focus enters the >> option, the entire option is read instead of the label of the focused >> element. Current focus reports the text of the option for all >> contained elements. >> >> Firefox/Win/JAWS: >> When reading before listbox has contained focus, The link, heading , >> and paragraph text are stringified for the selected option and the >> selected state is revealed. The button labels are omitted. >> When reading after listbox has contained focus, sometimes it is >> different: the link is revealed as a link. The heading and paragraph >> are stringified on a separate line. The select state is revealed. The >> button labels are omitted. >> When tabbing to the link and buttons, The link is read as a link but >> its label is replaced with the listbox label. The buttons are read as >> buttons. >> >> Firefox/Win/NVDA: >> When reading in document review, nothing is read; NVDA just says list. >> When reading in object review, it is possible to dig into the >> document hierarchy and find the semantic elements. >> When tabbing to the link and buttons: the elements are read with >> their labels and roles, but the listbox context is not announced. >> >> IE/JAWS: >> when reading, the link, heading, and paragraph are stringified, but >> the toolbar is revealed normally except that the buttons are read >> with “listbox item selected” at the beginning of each label. >> When tabbing to the link and buttons, The link is read as a link but >> its label is replaced with the listbox label. The buttons are read as >> buttons. >> >> IE/NVDA: none of the ARIA is recognized; read as HTML. >> >> Except for the odd Firefox behavior, which is technically a bug, This >> all makes sense. Given the mappings, it is exactly how it should be. >> >> Matt >> >> *From:*Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com]* >> Sent:*Wednesday, May 25, 2016 3:04 PM* >> To:*James Nurthen <james.nurthen@oracle.com >> <mailto:james.nurthen@oracle.com>>; Matt King <a11ythinker@gmail.com >> <mailto:a11ythinker@gmail.com>>; public-aria-admin@w3.org >> <mailto:public-aria-admin@w3.org>* >> Cc:*'Rich Schwerdtfeger' <richschwer@gmail.com >> <mailto:richschwer@gmail.com>>; 'Fred Esch' <fesch@us.ibm.com >> <mailto:fesch@us.ibm.com>>* >> Subject:*RE: 48 hour Call For Consensus regarding Resolutions from >> the May 19, 2016 ARIA Working Group meeting >> >> By this logic, it is also acceptable to put sliders inside of >> role=option nodes too, as well as tablist containers with dynamic >> tabs, radio buttons, links, checkboxes, trees, nested Listboxes, and >> comboboxes. And yes, I’ve seen developers do these things. >> >> The option role is not a composite widget, this is what it says in >> the spec. It does not support focusable children. >> >> So why is this acceptable or desirable when it goes against the spec >> and it causes unlimited accessibility issues? >> >> >> 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:*Wednesday, May 25, 2016 12:41 PM* >> To:*Bryan Garaventa <_bryan.garaventa@ssbbartgroup.com_ >> <mailto:bryan.garaventa@ssbbartgroup.com>>; Matt King >> <_a11ythinker@gmail.com_ >> <mailto:a11ythinker@gmail.com>>;_public-aria-admin@w3.org_ >> <mailto:public-aria-admin@w3.org>* >> Cc:*'Rich Schwerdtfeger' <_richschwer@gmail.com_ >> <mailto:richschwer@gmail.com>>; 'Fred Esch' <_fesch@us.ibm.com_ >> <mailto:fesch@us.ibm.com>>* >> Subject:*Re: 48 hour Call For Consensus regarding Resolutions from >> the May 19, 2016 ARIA Working Group meeting >> >> I disagree that this is how they currently work. >> >> Currently all the child nodes of option are exposed into the >> accessibility tree so, if navigation is allowed to them (via a >> keyboard switch for example), it is still possible for their correct >> role/state information to be accessed by AT. >> >> I fear that adding children are presentational to option will >> encorage browsers to remove these nodes from the accessibility tree >> which will break all kinds of things. Can someone clarify if child >> nodes of something with children presenational = true would still be >> in the accessibility tree as they are today? If these children are >> not in the accessibility tree then I object to this change in ARIA >> 1.1. I am happy to revisit it in the ARIA 2.0 timeline. >> >> Regards, >> >> James >> >> On 5/25/2016 12:16 PM, Bryan Garaventa wrote: >> >> +1 >> >> I am in favor of leaving role=option and role=treeitem in >> this list for the same reasons that Matt outlined here. This >> is literally how they already work in ATs and in browsers, so >> the change is editorial. >> >> If some want to expand role=option and/or role=treeitem in >> the future to be composite, then that could be a 2.0 proposal. >> >> >> 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:*Matt King [_mailto:a11ythinker@gmail.com_]* >> Sent:*Tuesday, May 24, 2016 4:25 PM* >> To:*Bryan Garaventa_<bryan.garaventa@ssbbartgroup.com>_ >> <mailto:bryan.garaventa@ssbbartgroup.com>; 'James >> Nurthen'_<james.nurthen@oracle.com>_ >> <mailto:james.nurthen@oracle.com>;_public-aria-admin@w3.org_ >> <mailto:public-aria-admin@w3.org>* >> Cc:*'Rich Schwerdtfeger'_<richschwer@gmail.com>_ >> <mailto:richschwer@gmail.com>; 'Fred >> Esch'_<fesch@us.ibm.com>_ <mailto:fesch@us.ibm.com>* >> Subject:*RE: 48 hour Call For Consensus regarding Resolutions >> from the May 19, 2016 ARIA Working Group meeting >> >> 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 >> Applications_https://www.w3.org/WAI/ARIA_ >> >> Rich Schwerdtfeger >> >> >> >> >> >> >> -- >> Regards, James >> >> <0E203729.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_ >> _<0E211030.gif> <http://www.oracle.com/commitment>Oracle is >> committed to developing practices and products that help >> protect the environment >> >> >> -- >> Regards, James >> >> <0E203729.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_ >> _<0E211030.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 Thursday, 26 May 2016 16:35:47 UTC