- From: Fred Esch <fesch@us.ibm.com>
- Date: Wed, 25 May 2016 09:13:03 -0400
- To: Matt King <a11ythinker@gmail.com>
- Cc: "Accessible Rich Internet Applications Working Group" <public-aria@w3.org>, public-aria-admin@w3.org
- Message-Id: <20160525132427.73CA6AE04B@b01ledav005.gho.pok.ibm.com>
Matt,
I think what you would like to see is trees and treegrids used similar to
the way tables and grids will be used. With the current definitions of
trees and treegrids that won't happen. Until we have an understandable
parallel structure for trees, I do not want to limit use of treeitems. When
I have a tree of objects, I have no other structure to use.
The definition of treegrid is non-intuitive and treegrids will not be
widely used. You can't convince a developer or anyone else a treegrid is
similar to a tree when they read the definition. The definition of treegrid
is 'A grid whose rows can be expanded and collapsed in the same manner as
for a tree.' A tree has branches and can express relationships like
parent/child. A row is usually associated with a data table where the
values in the row are associated with a category. I can't visualize what
happens when you expand a row. A grid represents a rectangular system
where rectangles are vertically and horizontally aligned. If you expand a
row - whatever that means what happens to the rectangles?
Until we have a usable alternative to a tree for complex objects - and
treegrid is not it. I don't want to limit use of treeitems.
Regards,
Fred Esch
Watson, IBM, W3C
Accessibility
IBM Watson Watson Release Management and Quality
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/24/2016 07:25 PM
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)
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
415.624.2709 (o)
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>
Cc: Fred Esch <fesch@us.ibm.com>; ARIA Working Group
<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> 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
415.624.2709 (o)
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>
Cc: ARIA Working Group <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>
To: ARIA Working Group <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
CTO Accessibility IBM Software: http://www.ibm.com.able
The World Wide Web Consortium (W3C), Web Accessibility
Initiative (WAI)
Chair, Accessible Rich Internet Applications
https://www.w3.org/WAI/ARIA
Rich Schwerdtfeger
--
Regards, James
Oracle
James Nurthen | Principal Engineer, Accessibility
Phone: +1 650 506 6781 | Mobile: +1 415 987 1918 | Video:
james.nurthen@oracle.com
Oracle Corporate Architecture
500 Oracle Parkway | Redwood Cty, CA 94065
Green
OracleOracle is committed to developing practices and
products that help protect the environment
Attachments
- image/gif attachment: 0A701761.gif
- image/gif attachment: graycol.gif
- image/gif attachment: 0A948870.gif
- image/gif attachment: 0A718978.gif
Received on Wednesday, 25 May 2016 13:25:32 UTC