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: Tue, 31 May 2016 10:00:12 -0400
To: James Nurthen <james.nurthen@oracle.com>
Cc: public-aria@w3.org
Message-Id: <20160531140052.89538BE05B@b03ledav005.gho.boulder.ibm.com>
+1

Providing an attribute to tell whether an element is presentational or not
is a good idea.  It is better to have user agents handle complexity rather
than have scripts and authors handle complexity. User agent behavior will
be tested. Toggling a property on an element that's content changes is much
easier on a author and script than finding the tree root and changing a
treeful of roles when the content of one leaf in the tree changes. For
authors and scripts the alternative would be to always use the roles for
interactive content even when the content is presentational. ARIA should
not be a burden for authors and scripts.

                                                              
     Regards,                                                 
                                                              
    Fred Esch                                                 
 Watson, IBM, W3C                                             
  Accessibility                                               
                                                              
 IBM Watson       Watson Release Management and Quality       
                                                              






From:	James Nurthen <james.nurthen@oracle.com>
To:	public-aria@w3.org
Date:	05/27/2016 06:54 PM
Subject:	Re: 48 hour Call For Consensus regarding Resolutions from the
            May 19,  2016 ARIA Working Group meeting



As I said previously - in the implementation there was a help message to
tell the user what to do to interact with the option. It certainly would
not be intuitive without that.
IMO if we want to go down this path in the ARIA 2.0 timeframe an attribute
on an element to tell a user they can interact with its children would be a
good path forward. If a user chose to do this then they would essentially
end up in a modal where they interact only with the children of that
element until they choose to escape out of that. This could (theoretically)
support multiple levels of this type of interaction, although in practice
this could end up being pretty painful to use.

Regards,
James



On 5/27/2016 3:35 PM, Birkir Gunnarsson wrote:
      The <option> element’s default implicit ARIA semantic is
      role=”option” according to http://www.w3.org/TR/html-aria/
      HTML does not allow focusable elements inside the option element.
      If we are to start allowing focusable elements inside ARIA option
      role we either have to:
            ·       Change the mapping of the HTML option element to a
            different ARIA role (if so, what)?
            Or
            ·       Make the ARIA option role different (i.e., creat a new
            role), or tell user that it is different from the HTML option
            tag (create a new attribute).

      We recently defended ARIA tabs in an article exchange by explaining
      that users use affordance to interact with elements they are familiar
      with.
      Applying that logic to this situation, if I am in a listbox on a
      webpage and I hear my screen reader say “option” I fall back on my
      years of interaction with options on webpages, which has taught me
      that the only thing you can do with them is navigate between them, or
      use keyboard shortcuts to select and de-select them.



      From: Matt King [mailto:a11ythinker@gmail.com]
      Sent: Friday, May 27, 2016 4:05 PM
      To: 'Bryan Garaventa' <bryan.garaventa@ssbbartgroup.com>; 'Schnabel,
      Stefan' <stefan.schnabel@sap.com>; 'Rich Schwerdtfeger'
      <richschwer@gmail.com>
      Cc: 'Fred Esch' <fesch@us.ibm.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

      Stefan,

      The fact that ARIA does not support nesting focusable elements and
      semantic structures inside treeitem and option elements is not a
      showstopper. We can still make the UIs you have described accessible.

      Earlier in the 1.1 cycle, with this problem in mind, we made changes
      to the grid description, that are also inherited by treegrid, that
      help in the situations you describe. In some cases, it is as simple
      as a 1/1 swap of grid for listbox and gridcell for option, putting
      row on an intervening element, and you are done. However, if you had
      wanted to include multiple focusable elements in an option, you can
      make a simpler interaction model if you break the option into a row
      with multiple gridcells.

      I commited the APG task force to addressing these patterns, with
      examples, in the next 8 weeks. It is a priority for us to have
      reference implementations, especially so screen reader developers
      have a resource for ironing out glitches. There are definitely some
      issues with screen reader support for treegrid.

      Those are glitches we can resolve. The lack of accessibility that you
      get when putting focusable elements and semantic structures inside
      options and treeitems are problems that we can not resolve because,
      as Bryan so well described, they are not accessible by definition.

      We moved the CFC forward, including treeitem and option, in light of
      the constraints ARIA has already placed on them, with an
      understanding of the way that browsers and assistive technologies
      render them, and with the knowledge that we have ways of addressing
      the needs that you expressed.

      The APg TF will share examples as soon as we have them available and
      solicit feedback to ensure we have addressed the needs that people
      have.

      Matt

      From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com]
      Sent: Friday, May 27, 2016 10:38 AM
      To: Schnabel, Stefan <stefan.schnabel@sap.com>; Rich Schwerdtfeger
      <richschwer@gmail.com>
      Cc: Fred Esch <fesch@us.ibm.com>; 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

      “True. Options MAY contain interactive subelements such as two
      different links. This is the reason why ARIA and keyboard support by
      JS must always go together in  patterns.
      Same as for tree nodes.
      Simply forbidding it is not the solution since developers do this as
      result of interaction designs that have often good reasons to be as
      such.”

      Actually no, because this is not supported in the ARIA spec. If
      developers do something that goes against what is documented in the
      ARIA specification, it should be no surprise that it results in
      inaccessible software when used by people who require the use of
      assistive technologies.

      If the desire is to do something like this, then the rules cannot
      just be changed on the fly like this, but it needs to be put into the
      specification so that user agents and assistive technologies can
      properly support it. Otherwise, this practice results in inaccessible
      software.

      By the way, Rich agreed yesturday during the call as did we all that
      this change should go forward, and that we should work on the role of
      treegrid with user agent and AT support to ensure this is working for
      the embedding of active elements because this role with gridcell is a
      composite.

      At present role=option and role=treeitem cannot support focusable
      children as active elements accessibly, because neither of these
      roles is composite according to the spec.

      Bryan Garaventa
      Accessibility Fellow
      SSB BART Group, Inc.
      bryan.garaventa@ssbbartgroup.com
      415.624.2709 (o)
      www.SSBBartGroup.com

      From: Schnabel, Stefan [mailto:stefan.schnabel@sap.com]
      Sent: Thursday, May 26, 2016 11:34 PM
      To: Rich Schwerdtfeger <richschwer@gmail.com>
      Cc: Fred Esch <fesch@us.ibm.com>; 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


            Sorry, I don’t buy the arguments requiring the descendants to
            be presentational.

      True. Options MAY contain interactive subelements such as two
      different links. This is the reason why ARIA and keyboard support by
      JS must always go together in  patterns.

      Same as for tree nodes.

      Simply forbidding it is not the solution since developers do this as
      result of interaction designs that have often good reasons to be as
      such.

      Instead, a standard keyboard navigation pattern has to be defined to
      access the inner content in such cases.

      For instance, an ARIA grid cell is focusable and contains 2
      interactive but readonly elements (same story).
      We defined arrow navigation between grid cells. Entering cells
      requires TAB  that does not leave the grid but will focus the first
      cell element inside, next Tab second element.  Coming back on cell
      level by shift+tab as reverse action. From there, arrowing again, and
      so on. This requires of course context-aware JS keyboard code,
      knowing that focus is Inside a cell or ON a cell. More complicated
      but doable.

      Regards
      Stefan

      Sent from my iPad

      On 26.05.2016, at 17:46, Rich Schwerdtfeger <richschwer@gmail.com>
      wrote:
            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







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






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

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

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

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

Received on Tuesday, 31 May 2016 14:01:59 UTC

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