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

I have never seen situations where embedding an interactive item
inside another interactive item works with screen readers.
You can't e.g. put buttons inside links inside buttons.
How is a screen reader supposed to announce an interactive control
inside another interactive control to the user, and how would the user
operate the "inner" and "outer" elements using the keyboard, or on a
mobile device?
You can use aria-controls on the treenodes pointing to a structure of
controls such as links, buttons or a toolbar, that live parallel to
that tree node in the structure.
In addition, you provide a keyboard shortcut to get to those controls
from the tree node. That is similar the set-up we use for
tabs/tabppanels.


That solution would fit into existing models, using existing ARIA
attributes, and have clear keyboard operation guidance.

I can see a benefit in allowing the leaf nodes of a tree to have
embedded controls (after all the tree is fully expanded, only you need
to reserve a keyboard and mobile device accessible way to close it),
but that would require additional ARIA roles or attributes and would
live in the world of ARIA 2.0.


On 5/25/16, Fred Esch <fesch@us.ibm.com> wrote:
> Matt,
>
> I think what you would like to see is trees and treegrids used similar to
> the way tables and grids will be used. With the current definitions of
> trees and treegrids that won't happen. Until we have an understandable
> parallel structure for trees, I do not want to limit use of treeitems. When
> I have a tree of objects, I have no other structure to use.
>
> The definition of treegrid is non-intuitive and treegrids will not be
> widely used. You can't convince a developer or anyone else a treegrid is
> similar to a tree when they read the definition. The definition of treegrid
> is 'A grid whose rows can be expanded and collapsed in the same manner as
> for a tree.'  A tree has branches and can express relationships like
> parent/child. A row is usually associated with a data table where the
> values in the row are associated with a category.  I can't visualize what
> happens when you expand a row.  A grid represents a rectangular system
> where rectangles are vertically and horizontally aligned. If you expand a
> row - whatever that means what happens to the rectangles?
>
> Until we have a usable alternative to a tree for complex objects - and
> treegrid is not it. I don't want to limit use of treeitems.
>
>      Regards,
>
>     Fred Esch
>  Watson, IBM, W3C
>   Accessibility
>
>  IBM Watson       Watson Release Management and Quality
>
>
>
>
>
>
>
> From: Matt King <a11ythinker@gmail.com>
> To: "'Bryan Garaventa'" <bryan.garaventa@ssbbartgroup.com>, "'James
>             Nurthen'" <james.nurthen@oracle.com>,
>             <public-aria-admin@w3.org>
> Cc: "'Rich Schwerdtfeger'" <richschwer@gmail.com>, Fred
>             Esch/Arlington/IBM@IBMUS
> Date: 05/24/2016 07:25 PM
> Subject: RE: 48 hour Call For Consensus regarding Resolutions from the
>             May 19,   2016 ARIA Working Group meeting
>
>
>
> Fred, Rich, and James,
>
> In practice, the children of option and treeitem elements already behave as
> if they are presentational. This is true for all roles mapped as inputs
> except composite inputs and text inputs. However, composite widgets are
> mapped to desktop GUI components that have well-defined interaction models
> and text inputs have their own special accessible text interface for
> rendering the attributes of their content to assistive technologies.
>
>       ·        Options and treeitems are defined in ARIA as singular input
>       elements. In this way, they are like the other subclasses of input
>       that are not also composite or text, i.e., checkbox, radio, slider,
>       and spinbutton.
>       ·        ARIA maps options and treeitems to desktop GUI components
>       that do not have either semantic or interactive children.
>       ·        Because of the option and treeitem mappings, most assistive
>       technologies do not provide reading modes that work inside of option
>       and treitem elements. They may provide ways of extracting the text,
>       but it is stringafied.
>       ·        There are no standardized interaction models for interacting
>       with content inside of an option or treeitem. Assistive tehcnologies
>       can not provide guidance to users if focus moves inside of an option
>       or treeitem like they can if it moves inside a composite or dialog.
>
> Because option and treeitem have the above attributes but are not formally
> defined as children presentational true, there is confusion about what
> assistive technologies are capable of doing with them, how checkers should
> treat them, and consequently, what authors should be allowed to do with
> them.
>
> Net: assistive technologies treat option and treeitem the way they do in
> desktop GUIs because that is how they are mapped. Because of that, all
> content inside is effectively presentational. Changing that would mean huge
> changes to ARIA.
>
> Accepting the proposal as written would bring the spec into line with
> current real-world behaviors and limitations. It will enable us to start
> fixing problems caused by this confusion.
>
> One of the problems we can fix right away is helping Fred and James make
> their UIs accessible within the practical constraints of ARIA 1.1.
>
> Please, let’s not continue to compound the problems we already have by
> removing option and treeitem from this CFC. Including them is extremely
> valuable to the clarity, consistency, and robustness of both the
> specification and the authoring practices.
>
> BTW, Fred, one of the reasons I worked so hard on issue 633 to get more
> flexibility and clarity for grid and dialog is to make reliable
> accessibility feasible for the types of UIs you described. I think we have
> the tools we need. They may not be100% optimal, and they fall short of what
> I originally envisioned, but they are a good step forward for a 1.1 release
> of the spec.
>
> Matt King
>
> From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com]
> Sent: Tuesday, May 24, 2016 12:14 PM
> To: James Nurthen <james.nurthen@oracle.com>; public-aria-admin@w3.org
> Subject: RE: 48 hour Call For Consensus regarding Resolutions from the May
> 19, 2016 ARIA Working Group meeting
>
> Can you point to an example of this?
>
> This type of implementation causes so many accessibility issues in JAWS and
> NVDA and everywhere else that I’ve tested that I flag this as a must-fix
> author error every time I come across it.
>
> I can’t think of an instance where this is a good idea, because this maps
> to the same role type as the HTML option element.
>
>
> Bryan Garaventa
> Accessibility Fellow
> SSB BART Group, Inc.
> bryan.garaventa@ssbbartgroup.com
> 415.624.2709 (o)
> www.SSBBartGroup.com
>
> From: James Nurthen [mailto:james.nurthen@oracle.com]
> Sent: Tuesday, May 24, 2016 12:02 PM
> To: public-aria-admin@w3.org
> Subject: Re: 48 hour Call For Consensus regarding Resolutions from the May
> 19, 2016 ARIA Working Group meeting
>
>
>
> I object to option being in this list too (for similar reasons to
> treeitem).
>
>
> We currently allow people to jump in and out of an "interaction" mode in
> order to allow them to interact with the child elements. If children
> presentational is added AT users will lose that ability.
>
>
> Regards,
>
>
> james
>
> On 5/24/2016 10:47 AM, Bryan Garaventa wrote:
>       That’s fine with me, though I think we will need to have a different
>       proposal to deal with role=treeitem separately.
>
>       The problem being that currently no embedded controls within
>       treeitems are accessible, since the role=tree widget is treated as
>       one form field.
>       E.G
>       http://whatsock.com/tsg/Coding%20Arena/ARIA%20Trees/Tree%20
>       (External%20XML)/demo.htm
>       (Reproduceable in Firefox using JAWS and NVDA)
>
>       And it’s not clear how anything that is embedded within such controls
>       should be discoverable or even intuitively interacted with.
>
>
>
>       Bryan Garaventa
>       Accessibility Fellow
>       SSB BART Group, Inc.
>       bryan.garaventa@ssbbartgroup.com
>       415.624.2709 (o)
>       www.SSBBartGroup.com
>
>       From: Rich Schwerdtfeger [mailto:richschwer@gmail.com]
>       Sent: Tuesday, May 24, 2016 9:47 AM
>       To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
>       Cc: Fred Esch <fesch@us.ibm.com>; ARIA Working Group
>       <public-aria-admin@w3.org>
>       Subject: Re: 48 hour Call For Consensus regarding Resolutions from
>       the May 19, 2016 ARIA Working Group meeting
>
>       I agree. I sent out what was resolved at the meeting and had the same
>       thoughts but I was not on the call and was going to raise the same
>       exception. We will have the same issues we have with options and
>       lists.
>
>       +1 to keeping the proposal minus treeitem.
>
>       Rich
>
>
>
>       Rich Schwerdtfeger
>
>
>
>             On May 24, 2016, at 10:53 AM, Bryan Garaventa <
>             bryan.garaventa@ssbbartgroup.com> wrote:
>
>             Currently role=treeitem is not a composite widget, and as such
>             nothing rendered within these containers is accessible. So not
>             including role=treeitem in this list will not solve this
>             problem.
>
>
>             Bryan Garaventa
>             Accessibility Fellow
>             SSB BART Group, Inc.
>             bryan.garaventa@ssbbartgroup.com
>             415.624.2709 (o)
>             www.SSBBartGroup.com
>
>             From: Fred Esch [mailto:fesch@us.ibm.com]
>             Sent: Tuesday, May 24, 2016 4:21 AM
>             To: Rich Schwerdtfeger <richschwer@gmail.com>
>             Cc: ARIA Working Group <public-aria-admin@w3.org>
>             Subject: Re: 48 hour Call For Consensus regarding Resolutions
>             from the May 19, 2016 ARIA Working Group meeting
>
>             Rich,
>
>             I would like to see treeitem dropped from the list. No one
>             wants to use treegrid and we see UIs with trees of complex
>             widgets which should naturally use tree style navigation
>             between the them. If we include treeitem in the list then you
>             would not be able to call something a tree, that looks like a
>             tree and you want it to navigate like a tree, if the leaves
>             were complex controls that a user could choose to leave
>             visible. Again, no one will ever call a tree of complex widgets
>             a treegrid when where there is no concept of rows in the
>             layout.
>
>             Suggested solutions for a tree that are compatible with
>             treeitem only having presentational children are work arounds
>             such as having the widget appear in a dialog when you click the
>             treeitem. These 'solutions' are not be practical when you have
>             flows, card layouts, or block chains that have branching. We
>             are seeing lots of card layouts, block chains and relationships
>             expressed in web apps that would be negatively impacted by this
>             restriction.
>
>
>
>      Regards,
>
>     Fred Esch
>  Watson, IBM, W3C
>   Accessibility
>
>  <image001.png>   Watson Release Management and Quality
>
>
>
>
>
>             <image002.gif>Rich Schwerdtfeger ---05/23/2016 04:06:45
>             PM---This is a Call for Consensus (CfC) to the Accessible Rich
>             Internet Applications (ARIA) Working Group
>
>             From: Rich Schwerdtfeger <richschwer@gmail.com>
>             To: ARIA Working Group <public-aria-admin@w3.org>
>             Date: 05/23/2016 04:06 PM
>             Subject: 48 hour Call For Consensus regarding Resolutions from
>             the May 19, 2016 ARIA Working Group meeting
>
>
>
>
>             This is a Call for Consensus (CfC) to the Accessible Rich
>             Internet Applications (ARIA) Working Group regarding the
>             following resolutions of the ARIA Working group.
>
>             1. Add children presentational true to checkbox, menuitem,
>             menuitemcheckbox, menuitemradio, option, radio, spinbutton,
>             switch, tab, and treeitem in response to Issue 1006
>             The meeting minutes are here:
>             https://www.w3.org/2016/05/19-aria-minutes.html
>
>             If you object to this proposal, or have comments concerning it,
>             please respond by replying on list to this message no later
>             than 23:49 (midnight) Boston Time,  Wednesday, May 25, 2016.
>
>             Regards,
>
>             Rich
>
>             —
>             Rich Schwerdtfeger,   Email: richschwer@gmail.com
>             CTO Accessibility IBM Software: http://www.ibm.com.able
>
>             The World Wide Web Consortium (W3C), Web Accessibility
>             Initiative (WAI)
>             Chair, Accessible Rich Internet Applications
>             https://www.w3.org/WAI/ARIA
>
>             Rich Schwerdtfeger
>
>
>
>
>
>
>
>
>
> --
> Regards, James
>
>
> Oracle
> James Nurthen | Principal Engineer, Accessibility
> Phone: +1 650 506 6781 | Mobile: +1 415 987 1918 | Video:
> james.nurthen@oracle.com
> Oracle Corporate Architecture
> 500 Oracle Parkway | Redwood Cty, CA 94065
> Green
>             OracleOracle is committed to developing practices and
> products that help protect the environment
>
>
>
>
>
>


-- 
Birkir R. Gunnarsson
Senior Accessibility Subject Matter Expert | Deque Systems
2121 Cooperative Way, Suite 210
Herndon, VA, 20171

Ph: (919) 607-27 53
Twitter: @birkir_gun

Received on Wednesday, 25 May 2016 13:53:31 UTC