W3C home > Mailing lists > Public > public-aria@w3.org > May 2016

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

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: <20160525132426.6EC786A03C@b03ledav003.gho.boulder.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





0A701761.gif
(image/gif attachment: 0A701761.gif)

graycol.gif
(image/gif attachment: graycol.gif)

0A948870.gif
(image/gif attachment: 0A948870.gif)

0A718978.gif
(image/gif attachment: 0A718978.gif)

Received on Wednesday, 25 May 2016 13:25:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:58:27 UTC