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: Thu, 26 May 2016 08:35:56 -0400
To: Matt King <a11ythinker@gmail.com>
Cc: public-aria-admin@w3.org, "Accessible Rich Internet Applications Working Group" <public-aria@w3.org>
Message-Id: <20160526130557.3CE0DB2051@b01ledav03.gho.pok.ibm.com>
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                                               
                                                              
 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/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)

            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

--
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





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

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

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

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

Received on Thursday, 26 May 2016 13:06:29 UTC

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