RE: 48 hour Call For Consensus regarding Resolutions from the May 19, 2016 ARIA Working Group meeting

James,

 

In that case, when you go into that “edit” mode with F2, you created an option element that behaves like a different role. It sounds like you made a gridcell so why not use gridcell?

 

With option as a container, none of the contained content will be readable with a reading cursor. It might work on focus, but the reading view will be ugly. Again, that is because we made ARIA option map like HTML option which is like option in a desktop GUI.

 

For example, if using NVDA, the only way to read it would be with object review. With JAWS, it would probably be either unintelligible with the VC or not present.

 

You could get robust accessibility that works with all screen readers in both reading mode and interaction mode if you used gridcell as the container.

 

Or, if the content appears dynamically when the F2 mode is invoked, it could open into a dialog. Again, it would be readable and the assistive tech would be able to communicate an unambiguous interaction model.

 

What would be a good reason to use listbox or tree where grid or treegrid will work better?

 

It is about the same amount of markup either way. The keyboard scripting is just as simple either way.

 

Matt

 

From: James Nurthen [mailto:james.nurthen@oracle.com] 
Sent: Tuesday, May 24, 2016 6:50 PM
To: public-aria-admin@w3.org
Subject: Re: 48 hour Call For Consensus regarding Resolutions from the May 19, 2016 ARIA Working Group meeting

 

 

 

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  <mailto:a11ythinker@gmail.com> <a11ythinker@gmail.com>
Cc: Bryan Garaventa  <mailto:bryan.garaventa@ssbbartgroup.com> <bryan.garaventa@ssbbartgroup.com>; James Nurthen  <mailto:james.nurthen@oracle.com> <james.nurthen@oracle.com>; public-aria-admin@w3.org <mailto:public-aria-admin@w3.org> ; Fred Esch  <mailto:fesch@us.ibm.com> <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

415.624.2709 (o)

www.SSBBartGroup.com <http://www.SSBBartGroup.com> 

 

From: James Nurthen [ <mailto:james.nurthen@oracle.com> 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

(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> mailto:richschwer@gmail.com] 
Sent: Tuesday, May 24, 2016 9:47 AM
To: Bryan Garaventa  <mailto:bryan.garaventa@ssbbartgroup.com> <bryan.garaventa@ssbbartgroup.com>
Cc: Fred Esch  <mailto:fesch@us.ibm.com> <fesch@us.ibm.com>; ARIA Working Group  <mailto:public-aria-admin@w3.org> <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 < <mailto:bryan.garaventa@ssbbartgroup.com> 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> 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:  <mailto:richschwer@gmail.com> 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> https://www.w3.org/WAI/ARIA 

Rich Schwerdtfeger











 

 

-- 
Regards, James 

 <http://www.oracle.com/> <image001.gif>
James Nurthen | Principal Engineer, Accessibility
Phone:  <tel:+1%20650%20506%206781> +1 650 506 6781 | Mobile:  <tel:+1%20415%20987%201918> +1 415 987 1918 | Video: james.nurthen@oracle.com <mailto:james.nurthen@oracle.com>  
Oracle Corporate Architecture
500 Oracle Parkway | Redwood Cty, CA 94065 
 <http://www.oracle.com/commitment> <image002.gif>Oracle is committed to developing practices and products that help protect the environment

 

 

-- 
Regards, James 

 <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>  
Oracle Corporate Architecture
500 Oracle Parkway | Redwood Cty, CA 94065 
 <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment