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 12:25:53 -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: <20160526163756.4431AB2046@b01ledav03.gho.pok.ibm.com>
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       
                                                              






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)

                              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
                  <0E203729.gif>
                  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
                  <0E211030.gif>Oracle is committed to developing practices
                  and products that help protect the environment

      --
      Regards, James
      <0E203729.gif>
      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
      <0E211030.gif>Oracle is committed to developing practices and
      products that help protect the environment






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

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

Received on Thursday, 26 May 2016 16:38:30 UTC

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