W3C home > Mailing lists > Public > public-aria@w3.org > July 2019

Re: AccName exclusion of groups and menus from content when calculating treeitem and menuitem names

From: Scott O'Hara <sohara@paciellogroup.com>
Date: Tue, 09 Jul 2019 18:47:25 -0400
To: Bryan Garaventa <bryan.garaventa@levelaccess.com>, Matt King <a11ythinker@gmail.com>, 'Aaron Leventhal' <aleventhal@google.com>
CC: 'Simon Pieters' <simon@bocoup.com>, 'ARIA Working Group' <public-aria@w3.org>
Message-ID: <0AFED283-8C1C-487D-A1C2-4FCB3BE9B780@paciellogroup.com>
FWIW I’d also strongly agree that it’s an author error to include a role=group inside a focuable element.

 

 

From: Bryan Garaventa <bryan.garaventa@levelaccess.com>
Date: Tuesday, July 9, 2019 at 6:19 PM
To: Matt King <a11ythinker@gmail.com>, 'Aaron Leventhal' <aleventhal@google.com>
Cc: 'Simon Pieters' <simon@bocoup.com>, 'ARIA Working Group' <public-aria@w3.org>
Subject: RE: AccName exclusion of groups and menus from content when calculating treeitem and menuitem names
Resent-From: <public-aria@w3.org>
Resent-Date: Tue, 09 Jul 2019 22:18:49 +0000

 

Hi Matt,

I’ve been going through the proposed exception list from earlier, and I think it still makes sense.

 

I don’t think we can rely on any current browser implementations of this at present, because we as yet have no consensus on what exceptions are or where, and how these apply within the spec as it is going to be added in the future. So we are dealing with the chicken and egg thing at the moment.

 

Personally I’m leaning towards Aaron’s interpretation about having role=group never be traversed recursively, no matter what element is the root node above it.

 

The reason being, we need this to be true for ARIA Tree constructs with subgroups, especially if setting role=treeitem on a li where the subgroup is included within the same li, so that all the contents of that group are not automatically included in the name for the currently focusable treeitem node.

 

I would say it’s an author error to include role=group inside of a focusable active element or other construct like a heading, because the role is meant to enclose a collection of interactive controls, neither of which should really be applicable in a link or a heading. An informative heading for instance, should be an informative name, and not a bunch of nonsensical radio button or checkbox control values as should be listed within a group role. The same is true here for role=radiogroup as well.

 

So, I’d recommend just making it a blanket rule that content within a group role should not be traversed recursively when computing the name of a parent root node. Typically groups like this should be explicitly named anyway as well using aria-label or aria-labelledby, and these actually would be returned as the name for that node during the recursive processing just like all other non-widget elements that don’t have a value.

 

Would that work?

 

All the best,

Bryan

 

Bryan Garaventa

Principal Accessibility Architect

Level Access, Inc.

Bryan.Garaventa@LevelAccess.com

415.624.2709 (o)

www.LevelAccess.com

 

From: Matt King <a11ythinker@gmail.com> 
Sent: Monday, July 08, 2019 11:55 PM
To: 'Aaron Leventhal' <aleventhal@google.com>
Cc: Bryan Garaventa <bryan.garaventa@levelaccess.com>; 'Simon Pieters' <simon@bocoup.com>; 'ARIA Working Group' <public-aria@w3.org>
Subject: RE: AccName exclusion of groups and menus from content when calculating treeitem and menuitem names

 

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

 

Sort of … going off of current ehavior of chrome and ff, whether or not the descendant content of an element that is named by author gets walked when recursively calculating name from content seems like it might depend on whether the parent has children presentational true. I only checked a few roles. So, this is not definitive.

 

Label on this button is “1 2 3”:

<button>1 2 3 <div role=”group”>4 5 6</div></button>

Whereas the name of this link is “1 2 3 4 5 6”:

<a href=”/”>1 2 3 <div role=”group”>4 5 6</div></a>

 

Obviously, these are pretty contrived examples; they are just the first thing that came to mind for testing this theory.

 

Regardless, we have a potential problem … menuitem and treeitem do not have children presentational true. So, why would descendant walking stop at the group for them if it doesn’t for link? It doesn’t stop if the parent is a heading either. Are both browsers wrong when calculating the names of links and headings but right for menuitems and treeitems?

 

Matt

 

From: Aaron Leventhal <aleventhal@google.com> 
Sent: Monday, July 8, 2019 10:27 AM
To: Matt King <a11ythinker@gmail.com>
Cc: Bryan Garaventa <bryan.garaventa@levelaccess.com>; Simon Pieters <simon@bocoup.com>; ARIA Working Group <public-aria@w3.org>
Subject: Re: AccName exclusion of groups and menus from content when calculating treeitem and menuitem names

 

I believe they would not get walked for the name calculation. The name calc is recursive, and the name rule for each item walked is consulted. If the rule for a role says that names do not come from descendants, there is no need to recurse into the descendants.

 

On Mon, Jul 8, 2019 at 1:23 PM Matt King <a11ythinker@gmail.com> wrote:

Hmmm… does that mean that if someone put a group inside a link or button that the group descendants would not get walked? Or is that different because they have children presentational. If so, then  how is that difference covered?

 

From: Aaron Leventhal <aleventhal@google.com> 
Sent: Monday, July 8, 2019 7:08 AM
To: Bryan Garaventa <bryan.garaventa@levelaccess.com>
Cc: Matthew King <mck@fb.com>; Simon Pieters <simon@bocoup.com>; ARIA Working Group <public-aria@w3.org>
Subject: Re: AccName exclusion of groups and menus from content when calculating treeitem and menuitem names

 

I think it's accounted for by the fact that as the browser looks at descendants for contributions to a name, and it runs across the group, the rule is that a group can get  name from author but not from contents.

 

On Fri, Jun 28, 2019 at 12:55 PM Bryan Garaventa <bryan.garaventa@levelaccess.com> wrote:

Hi Matt,

I’m including the ARIA WG on this thread as well since it’s important for AccName understanding in general.

 

As a quick answer, yes this is accounted for in the prototype, but no this isn’t documented anywhere in the spec as yet.

 

This is however included within the draft outline I sent through some weeks back, which is meant to account for these types of exclusions and subtree logic when parsing child node structures. The outline is important because it includes concepts and additions that don’t appear as spec text as yet, yet does reflect decisions we have already agreed to when these were previously discussed.

 

I need to get some help to setup a wiki page on the AccName repo where I can post this outline and then it will be easier to refer people to this instead.

 

Since it’s the end of the quarter, my time is limited at the moment, but I’ll be able to dedicate more time to getting this organized soon I hope.

 

All the best,

Bryan

 

 

 

 

Bryan Garaventa

Principal Accessibility Architect

Level Access, Inc.

Bryan.Garaventa@LevelAccess.com

415.624.2709 (o)

www.LevelAccess.com

 

From: Matthew King <mck@fb.com> 
Sent: Tuesday, June 25, 2019 5:34 PM
To: Aaron Leventhal (aleventhal@google.com) <aleventhal@google.com>; Bryan Garaventa <bryan.garaventa@levelaccess.com>
Cc: Simon Pieters <simon@bocoup.com>
Subject: AccName exclusion of groups and menus from content when calculating treeitem and menuitem names

 

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

 

Aaron,

 

I learned from you that accname is supposed to ignore descendant groups, and I think menus, when calculating the name of a treeitem or menuitem from content. However, Simon has been looking for where this is documented (he is helping me develop a new APG section on naming and describing).

 

For example, it is my understanding that when calculating the name of the parent tree item in the following, the group is ignored and the name is “Fruits”:

 

<ul role="tree">

  <li role="treeitem">Fruits

    <ul role="group">

      <li role="treeitem">Apples</li>

      <li role="treeitem">Bananas</li>

      <li role="treeitem">Oranges</li>

    </ul>

  </li>

</ul>

 

Similarly, I also have been under the impression that when calculating the name of the following parent menuitem from content, the submenu items are supposed to be ignored to also come up with a name of “Fruits”:

 

<ul role="menu">

  <li role="menuitem">Fruits

    <ul role="menu">

      <li role="menuitem">Apples</li>

      <li role="menuitem">Bananas</li>

      <li role="menuitem">Oranges</li>

    </ul>

  </li>

</ul>

 

Bryan, do you account for this in your implementation of the algorithm? Do you know where it is documented? If it is not, should I raise an issue against accname?

 

Thanks,

Matt
Received on Tuesday, 9 July 2019 22:47:53 UTC

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