- From: James Nurthen <james.nurthen@oracle.com>
- Date: Fri, 27 May 2016 15:53:29 -0700
- To: public-aria@w3.org
- Message-ID: <628f4957-1aa4-8ed1-914e-21aa0d645a6b@oracle.com>
As I said previously - in the implementation there was a help message to tell the user what to do to interact with the option. It certainly would not be intuitive without that. IMO if we want to go down this path in the ARIA 2.0 timeframe an attribute on an element to tell a user they can interact with its children would be a good path forward. If a user chose to do this then they would essentially end up in a modal where they interact only with the children of that element until they choose to escape out of that. This could (theoretically) support multiple levels of this type of interaction, although in practice this could end up being pretty painful to use. Regards, James On 5/27/2016 3:35 PM, Birkir Gunnarsson wrote: > > The <option> element’s default implicit ARIA semantic is role=”option” > according to http://www.w3.org/TR/html-aria/ > > HTML does not allow focusable elements inside the option element. > > If we are to start allowing focusable elements inside ARIA option role > we either have to: > > ·Change the mapping of the HTML option element to a different ARIA > role (if so, what)? > > Or > > ·Make the ARIA option role different (i.e., creat a new role), or tell > user that it is different from the HTML option tag (create a new > attribute). > > We recently defended ARIA tabs in an article exchange by explaining > that users use affordance to interact with elements they are familiar > with. > > Applying that logic to this situation, if I am in a listbox on a > webpage and I hear my screen reader say “option” I fall back on my > years of interaction with options on webpages, which has taught me > that the only thing you can do with them is navigate between them, or > use keyboard shortcuts to select and de-select them. > > *From:*Matt King [mailto:a11ythinker@gmail.com] > *Sent:* Friday, May 27, 2016 4:05 PM > *To:* 'Bryan Garaventa' <bryan.garaventa@ssbbartgroup.com>; 'Schnabel, > Stefan' <stefan.schnabel@sap.com>; 'Rich Schwerdtfeger' > <richschwer@gmail.com> > *Cc:* 'Fred Esch' <fesch@us.ibm.com>; public-aria-admin@w3.org; > 'Accessible Rich Internet Applications Working Group' <public-aria@w3.org> > *Subject:* RE: 48 hour Call For Consensus regarding Resolutions from > the May 19, 2016 ARIA Working Group meeting > > Stefan, > > The fact that ARIA does not support nesting focusable elements and > semantic structures inside treeitem and option elements is not a > showstopper. We can still make the UIs you have described accessible. > > Earlier in the 1.1 cycle, with this problem in mind, we made changes > to the grid description, that are also inherited by treegrid, that > help in the situations you describe. In some cases, it is as simple as > a 1/1 swap of grid for listbox and gridcell for option, putting row on > an intervening element, and you are done. However, if you had wanted > to include multiple focusable elements in an option, you can make a > simpler interaction model if you break the option into a row with > multiple gridcells. > > I commited the APG task force to addressing these patterns, with > examples, in the next 8 weeks. It is a priority for us to have > reference implementations, especially so screen reader developers have > a resource for ironing out glitches. There are definitely some issues > with screen reader support for treegrid. > > Those are glitches we can resolve. The lack of accessibility that you > get when putting focusable elements and semantic structures inside > options and treeitems are problems that we can not resolve because, as > Bryan so well described, they are not accessible by definition. > > We moved the CFC forward, including treeitem and option, in light of > the constraints ARIA has already placed on them, with an understanding > of the way that browsers and assistive technologies render them, and > with the knowledge that we have ways of addressing the needs that you > expressed. > > The APg TF will share examples as soon as we have them available and > solicit feedback to ensure we have addressed the needs that people have. > > Matt > > *From:*Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com] > *Sent:* Friday, May 27, 2016 10:38 AM > *To:* Schnabel, Stefan <stefan.schnabel@sap.com>; Rich Schwerdtfeger > <richschwer@gmail.com> > *Cc:* Fred Esch <fesch@us.ibm.com>; Matt King <a11ythinker@gmail.com>; > public-aria-admin@w3.org; Accessible Rich Internet Applications > Working Group <public-aria@w3.org> > *Subject:* RE: 48 hour Call For Consensus regarding Resolutions from > the May 19, 2016 ARIA Working Group meeting > > “True. Options MAY contain interactive subelements such as two > different links. This is the reason why ARIA and keyboard support by > JS must always go together in patterns. > > Same as for tree nodes. > > Simply forbidding it is not the solution since developers do this as > result of interaction designs that have often good reasons to be as such.” > > Actually no, because this is not supported in the ARIA spec. If > developers do something that goes against what is documented in the > ARIA specification, it should be no surprise that it results in > inaccessible software when used by people who require the use of > assistive technologies. > > If the desire is to do something like this, then the rules cannot just > be changed on the fly like this, but it needs to be put into the > specification so that user agents and assistive technologies can > properly support it. Otherwise, this practice results in inaccessible > software. > > By the way, Rich agreed yesturday during the call as did we all that > this change should go forward, and that we should work on the role of > treegrid with user agent and AT support to ensure this is working for > the embedding of active elements because this role with gridcell is a > composite. > > At present role=option and role=treeitem cannot support focusable > children as active elements accessibly, because neither of these roles > is composite according to the spec. > > 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:*Schnabel, Stefan [mailto:stefan.schnabel@sap.com] > *Sent:* Thursday, May 26, 2016 11:34 PM > *To:* Rich Schwerdtfeger <richschwer@gmail.com > <mailto:richschwer@gmail.com>> > *Cc:* Fred Esch <fesch@us.ibm.com <mailto:fesch@us.ibm.com>>; Matt > King <a11ythinker@gmail.com <mailto:a11ythinker@gmail.com>>; > public-aria-admin@w3.org <mailto:public-aria-admin@w3.org>; Accessible > Rich Internet Applications Working Group <public-aria@w3.org > <mailto:public-aria@w3.org>> > *Subject:* Re: 48 hour Call For Consensus regarding Resolutions from > the May 19, 2016 ARIA Working Group meeting > > Sorry, I don’t buy the arguments requiring the descendants to be > presentational. > > True. Options MAY contain interactive subelements such as two > different links. This is the reason why ARIA and keyboard support by > JS must always go together in patterns. > > Same as for tree nodes. > > Simply forbidding it is not the solution since developers do this as > result of interaction designs that have often good reasons to be as such. > > Instead, a standard keyboard navigation pattern has to be defined to > access the inner content in such cases. > > For instance, an ARIA grid cell is focusable and contains 2 > interactive but readonly elements (same story). > > We defined arrow navigation between grid cells. Entering cells > requires TAB that does not leave the grid but will focus the first > cell element inside, next Tab second element. Coming back on cell > level by shift+tab as reverse action. From there, arrowing again, and > so on. This requires of course context-aware JS keyboard code, knowing > that focus is Inside a cell or ON a cell. More complicated but doable. > > Regards > > Stefan > > > Sent from my iPad > > > On 26.05.2016, at 17:46, Rich Schwerdtfeger <richschwer@gmail.com > <mailto:richschwer@gmail.com>> 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 > Applicationshttps://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 Friday, 27 May 2016 22:54:05 UTC