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 14:26:13 -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: <20160526182656.9D9AA124037@b01ledav002.gho.pok.ibm.com>
Bryan,

Thanks for looking into this.  I await the promised APG pattern for
treegrid. James N. solution of adding a attribute to let AT know that the
content is a widget sounds like a good solution. It seems laborious to
duplicate patterns for static and non-static content.

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






From:	Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
To:	Fred Esch/Arlington/IBM@IBMUS
Cc:	Accessible Rich Internet Applications Working Group
            <public-aria@w3.org>, "public-aria-admin@w3.org"
            <public-aria-admin@w3.org>
Date:	05/26/2016 12:52 PM
Subject:	RE: 48 hour Call For Consensus regarding Resolutions from the
            May 19,  2016   ARIA Working Group meeting



At present the most accessible method for implementing a nested structure
like this that includes both active elements and static content is to use
the most recent accordion model, which is a combination of role=heading +
aria-level to indicate a nested structure plus an embedded role=button +
aria-expanded to act as the focusable triggering element. We recently did
this successfully for a client who needed a similar construct that had to
work accessibly across a wide range of devices and platforms.

Unfortunately the last I tested role=treegrid, it was totally inaccessible
in JAWS17 using IE11.


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: Thursday, May 26, 2016 9:26 AM
To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
Cc: Accessible Rich Internet Applications Working Group
<public-aria@w3.org>; public-aria-admin@w3.org
Subject: RE: 48 hour Call For Consensus regarding Resolutions from the May
19, 2016 ARIA Working Group meeting



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                            
                                                     






Inactive hide details for Bryan Garaventa ---05/26/2016 12:03:02 PM---Is
role=treeitem a composite in the spec? I’m not gettinBryan Garaventa
---05/26/2016 12:03:02 PM---Is role=treeitem a composite in the spec? I’m
not getting where the difficulty here is, you can alre

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)


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

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

Received on Thursday, 26 May 2016 18:27:28 UTC

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