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

Stefan,

 

I think Bryan said it pretty well.

 

Another way of thinking about this is that no matter what we do with ARIA,
you always have the choice between following the spec so that we can make
things work in practice or building your own path that might sort of work in
some circumstances for some users on some devices if they have the right
information that is unique to your application. When you choose your own
path, please don't ask the assistive technology developers to bend to fit
it.

 

I believe we have made huge steps forward with ARIA 1.1 that can help with
just the problems you describe. In some cases, to support accessibility, the
code might not look exactly the way you dream it should ideally look. But,
the objectives of the design can still be met in a robust way. 

 

I am not saying that every idea a designer could dream up can be made
accessible. I have seen plenty of designs that are dead on arrival. Usually
they are dead for more reasons that just accessibility though. If the
designers are put on an unshakable pedestal, failure is nearly certain.
That's why good designers passionately skirt such pedestals. Instead, they
lead multi-disciplinary teams through the process of ensuring the design is
functional and implementable through every lens that is valued by the
company. One such lens should be accessibility. It should not pose needless
constraints, of course, but it does not come without constraints.
Unfortunately, very occasionally, some constraints may exist in the AX API
layer of the technology stack. I don't think you are facing that situation.

 

I am hoping you will find the APG reference implementations helpful as you
work with us on solving challenging UI accessibility problems in robust
ways. If you have a set of design objectives that proves to be impossible to
meet with ARIA 1.1 , it might be a good candidate for ARIA 2.0 issues.

 

Matt King

 

From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com] 
Sent: Wednesday, June 1, 2016 9:42 AM
To: Schnabel, Stefan <stefan.schnabel@sap.com>; Matt King
<a11ythinker@gmail.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

 

"Now you will say maybe listitems are not allowed to be focusable /
interactive but it is a fact from real world since the entire interaction
design requires this."

 

If you make static structural elements both static and sometimes
interactive, how is anybody using an AT supposed to know which is which?
Also how is an AT or user agent supposed to know what its intended purpose
is?

 

This is not scalable across both desktop and mobile for keyboard and touch,
nor is it possible for all user  agents to accurately guess at the intended
purpose of something like this.

 

It is a huge mistake to gear the ARIA specification for overly convaluted
markup structures like this, because they will never work reliably.

 

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: Tuesday, May 31, 2016 3:32 AM
To: Matt King <a11ythinker@gmail.com <mailto:a11ythinker@gmail.com> >; Bryan
Garaventa <bryan.garaventa@ssbbartgroup.com
<mailto:bryan.garaventa@ssbbartgroup.com> >; 'Rich Schwerdtfeger'
<richschwer@gmail.com <mailto:richschwer@gmail.com> >
Cc: 'Fred Esch' <fesch@us.ibm.com <mailto:fesch@us.ibm.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

 

Matt,

 

I understand but I am not 100% convinced. Turning this into focusable
listitems instead of option, how is the situation there?

 

The Problem is that we need to handle cases in current UI's like repetitive
list-like complex containers with presentational AND interactive content
that are interactive on their own because UID's define it this way and we
want NOT to change the interaction design.

 

Thinks like

 

<span role="list">

<span role="listitem" tabindex="0" onClick="javascript:doNavigate()">

This is one member, there is <a href="http://more.com">more>/a> detail on
it.
<img role="button" tabindex="0" onClick="javascript:doRate()" title="Rate
me!">

</span>     

<span role="listitem" ./>

<span role="listitem" ./>

.

</span>

 

are very very common in today's UIs. And of course we need to have here FULL
aria-level, aria-setsize and aria-posinset support for listitem role which
is currently still NOT the case for different AT/UA combinations.

 

Now you will say maybe listitems are not allowed to be focusable /
interactive but it is a fact from real world since the entire interaction
design requires this.

And yes, it IS a list with highly repetitive list items. Role redesign won't
help.

 

So, give me a listitem-like thing that allows for focusing,
non-presentational focusable content and an industry standard keyboard
access pattern. This is the requirement. And, oh yes, an API to tell AT what
to read in which sequence by the interior when focusing the entire list
item. Currently we have to use aria-label as a workaround.

 

Regards

Stefan

 

From: Matt King [mailto:a11ythinker@gmail.com] 
Sent: Freitag, 27. Mai 2016 22:05
To: 'Bryan Garaventa' <bryan.garaventa@ssbbartgroup.com
<mailto:bryan.garaventa@ssbbartgroup.com> >; Schnabel, Stefan
<stefan.schnabel@sap.com <mailto:stefan.schnabel@sap.com> >; 'Rich
Schwerdtfeger' <richschwer@gmail.com <mailto:richschwer@gmail.com> >
Cc: 'Fred Esch' <fesch@us.ibm.com <mailto:fesch@us.ibm.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

 

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
<mailto:stefan.schnabel@sap.com> >; 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

 

"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>;
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.
 <mailto:bryan.garaventa@ssbbartgroup.com> bryan.garaventa@ssbbartgroup.com
415.624.2709 (o)
 <http://www.ssbbartgroup.com/> www.SSBBartGroup.com

From: James Nurthen [ <mailto:james.nurthen@oracle.com>
mailto:james.nurthen@oracle.com] 
Sent: Wednesday, May 25, 2016 12:41 PM
To: Bryan Garaventa < <mailto:bryan.garaventa@ssbbartgroup.com>
bryan.garaventa@ssbbartgroup.com>; Matt King <
<mailto:a11ythinker@gmail.com> a11ythinker@gmail.com>;
<mailto:public-aria-admin@w3.org> public-aria-admin@w3.org
Cc: 'Rich Schwerdtfeger' < <mailto:richschwer@gmail.com>
richschwer@gmail.com>; '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

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.
 <mailto:bryan.garaventa@ssbbartgroup.com> bryan.garaventa@ssbbartgroup.com
415.624.2709 (o)
 <http://www.ssbbartgroup.com/> www.SSBBartGroup.com

From: Matt King [ <mailto:a11ythinker@gmail.com>
mailto:a11ythinker@gmail.com] 
Sent: Tuesday, May 24, 2016 4:25 PM
To: Bryan Garaventa  <mailto:bryan.garaventa@ssbbartgroup.com>
<bryan.garaventa@ssbbartgroup.com>; 'James Nurthen'
<mailto:james.nurthen@oracle.com> <james.nurthen@oracle.com>;
<mailto:public-aria-admin@w3.org> public-aria-admin@w3.org
Cc: 'Rich Schwerdtfeger'  <mailto:richschwer@gmail.com>
<richschwer@gmail.com>; '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

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>
mailto:bryan.garaventa@ssbbartgroup.com] 
Sent: Tuesday, May 24, 2016 12:14 PM
To: James Nurthen < <mailto:james.nurthen@oracle.com>
james.nurthen@oracle.com>;  <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

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.
 <mailto:bryan.garaventa@ssbbartgroup.com> bryan.garaventa@ssbbartgroup.com
415.624.2709 (o)
 <http://www.ssbbartgroup.com/> 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:  <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 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(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.
 <mailto:bryan.garaventa@ssbbartgroup.com> bryan.garaventa@ssbbartgroup.com
415.624.2709 (o)
 <http://www.ssbbartgroup.com/> 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.
 <mailto:bryan.garaventa@ssbbartgroup.com> bryan.garaventa@ssbbartgroup.com
415.624.2709 (o)
 <http://www.ssbbartgroup.com/> www.SSBBartGroup.com

From: Fred Esch [ <mailto:fesch@us.ibm.com> mailto:fesch@us.ibm.com] 
Sent: Tuesday, May 24, 2016 4:21 AM
To: Rich Schwerdtfeger < <mailto:richschwer@gmail.com> richschwer@gmail.com>
Cc: 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

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 < <mailto:richschwer@gmail.com>
richschwer@gmail.com>
To: ARIA Working Group < <mailto:public-aria-admin@w3.org>
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/> <0E203729.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:
<mailto:james.nurthen@oracle.com> james.nurthen@oracle.com 
Oracle Corporate Architecture
500 Oracle Parkway | Redwood Cty, CA 94065 
 <http://www.oracle.com/commitment> <0E211030.gif>Oracle is committed to
developing practices and products that help protect the environment


-- 
Regards, James  

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