- From: Fred Esch <fesch@us.ibm.com>
- Date: Thu, 26 May 2016 14:26:13 -0400
- To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
- Cc: Accessible Rich Internet Applications Working Group <public-aria@w3.org>, "public-aria-admin@w3.org" <public-aria-admin@w3.org>
- Message-Id: <20160526182655.1C1F5B2050@b01ledav03.gho.pok.ibm.com>
Bryan,
Thanks for looking into this. I await the promised APG pattern for
treegrid. James N. solution of adding a attribute to let AT know that the
content is a widget sounds like a good solution. It seems laborious to
duplicate patterns for static and non-static content.
Regards,
Fred Esch
Watson, IBM, W3C
Accessibility
IBM Watson Watson Release Management and Quality
From: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
To: Fred Esch/Arlington/IBM@IBMUS
Cc: Accessible Rich Internet Applications Working Group
<public-aria@w3.org>, "public-aria-admin@w3.org"
<public-aria-admin@w3.org>
Date: 05/26/2016 12:52 PM
Subject: RE: 48 hour Call For Consensus regarding Resolutions from the
May 19, 2016 ARIA Working Group meeting
At present the most accessible method for implementing a nested structure
like this that includes both active elements and static content is to use
the most recent accordion model, which is a combination of role=heading +
aria-level to indicate a nested structure plus an embedded role=button +
aria-expanded to act as the focusable triggering element. We recently did
this successfully for a client who needed a similar construct that had to
work accessibly across a wide range of devices and platforms.
Unfortunately the last I tested role=treegrid, it was totally inaccessible
in JAWS17 using IE11.
Bryan Garaventa
Accessibility Fellow
SSB BART Group, Inc.
bryan.garaventa@ssbbartgroup.com
415.624.2709 (o)
www.SSBBartGroup.com
From: Fred Esch [mailto:fesch@us.ibm.com]
Sent: Thursday, May 26, 2016 9:26 AM
To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
Cc: Accessible Rich Internet Applications Working Group
<public-aria@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
Bryan,
The problem is if we want to use a tree structure, we only have the tree to
use. Treegrid isn't like a tree, it is a table with twisties.
What structure do you recommend we use for this sample app? The app has a
simple organization tree where the nodes are people and each node contains
a picture, name, invite to chat button. The app wants the ability to have
all the nodes in the tree visible all the time as well as being able to
expand/collapse. The UX expects to navigate the tree, like a tree and enter
a node with the enter key. What structure do I use for this?
Regards,
Fred Esch
Watson, IBM, W3C
Accessibility
IBM Watson Watson Release Management and
Quality
Inactive hide details for Bryan Garaventa ---05/26/2016 12:03:02 PM---Is
role=treeitem a composite in the spec? I’m not gettinBryan Garaventa
---05/26/2016 12:03:02 PM---Is role=treeitem a composite in the spec? I’m
not getting where the difficulty here is, you can alre
From: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
To: Rich Schwerdtfeger <richschwer@gmail.com>, Fred
Esch/Arlington/IBM@IBMUS
Cc: Matt King <a11ythinker@gmail.com>, "public-aria-admin@w3.org" <
public-aria-admin@w3.org>, "Accessible Rich Internet Applications Working
Group" <public-aria@w3.org>
Date: 05/26/2016 12:03 PM
Subject: RE: 48 hour Call For Consensus regarding Resolutions from the May
19, 2016 ARIA Working Group meeting
Is role=treeitem a composite in the spec?
I’m not getting where the difficulty here is, you can already build an
accessible tree that includes spawned controls accessibly by seperating the
focusable role=treeitem node from the control being spawned, even if this
is inline.
Here is a working example that works across both desktop and mobile:
http://whatsock.com/tsg/Coding%20Arena/ARIA%20Menus/Variation%20ARIA%20Tree%20With%20Right%20Click/demo.htm
This has an attached right-click ARIA Menu attached to all of the expanded
leaf nodes, that works from the keyboard using Shift+F10 and the
Applications key, and by using the iOS long-click method by tap-and-hold
for several seconds to open the same menu.
If something is not a composite in the spec, why are user agents expected
to support focusable children in the accessibility tree?
If you look at the accessibility tree in Chrome, you won’t see anything but
treeitem nodes, every other role type is stripped out.
Bryan Garaventa
Accessibility Fellow
SSB BART Group, Inc.
bryan.garaventa@ssbbartgroup.com
415.624.2709 (o)
www.SSBBartGroup.com
From: Rich Schwerdtfeger [mailto:richschwer@gmail.com]
Sent: Thursday, May 26, 2016 8:45 AM
To: Fred Esch <fesch@us.ibm.com>
Cc: 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
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>
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>
To: "'Bryan Garaventa'" <bryan.garaventa@ssbbartgroup.com>,
"'James Nurthen'" <james.nurthen@oracle.com>, <
public-aria-admin@w3.org>
Cc: "'Rich Schwerdtfeger'" <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>; Matt King <
a11ythinker@gmail.com>; public-aria-admin@w3.org
Cc: 'Rich Schwerdtfeger' <richschwer@gmail.com>; 'Fred Esch' <
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
415.624.2709 (o)
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>; Matt
King <a11ythinker@gmail.com>; public-aria-admin@w3.org
Cc: 'Rich Schwerdtfeger' <richschwer@gmail.com>; 'Fred Esch' <
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
415.624.2709 (o)
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>;
'James Nurthen'
<james.nurthen@oracle.com>;
public-aria-admin@w3.org
Cc: 'Rich Schwerdtfeger'
<richschwer@gmail.com>; 'Fred Esch'
<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>;
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
From: James Nurthen [
mailto:james.nurthen@oracle.com]
Sent: Tuesday, May 24, 2016 12:02 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
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)
Attachments
- image/gif attachment: 07150958.gif
- image/gif attachment: graycol.gif
Received on Thursday, 26 May 2016 18:27:30 UTC