RE: AccName exclusion of groups and menus from content when calculating treeitem and menuitem names from Matt King on 2019-07-09 (public-aria@w3.org from July 2019)

From: Matt King <a11ythinker@gmail.com>
Date: Tue, 9 Jul 2019 16:35:13 -0700
To: "'Scott O'Hara'" <sohara@paciellogroup.com>, "'Bryan Garaventa'" <bryan.garaventa@levelaccess.com>, "'Aaron Leventhal'" <aleventhal@google.com>
Cc: "'Simon Pieters'" <simon@bocoup.com>, "'ARIA Working Group'" <public-aria@w3.org>
Message-ID: <005301d536ae$f5817890$e08469b0$@gmail.com>
Scott said:

>FWIW I’d also strongly agree that it’s an author error to include a role=group inside a focuable element.

 

I assume you mean with the one exception of group inside treeitem.

 

Bryan said:

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

 

Bryan, So would the rule exclude just groups, or any element that gets its name from author? We certainly need to exclude menu as well. It might be simpler and have fewer potentially harmful side effects if it were just groups and menus and if that exception applied only inside treeitems and menuitems.

 

So often people have no idea what the side effects of overlooking the presence of a supposedly harmless little role attribute, like “group” might be. With a rule like this, the side effect is that the group role will work like aria-hidden in some situations. Currently it only has that effect inside a few specific elements. So, if we have a rule like this we should think hard about whether those are desirable side effects. 

 

Another way to think about this … should we think about limiting the scope of such exceptions for the express purpose of avoiding really bad side effects from otherwise harmless author errors, e.g., accidentally putting a group inside a link for instance.

 

Best,

Matt

 

From: Scott O'Hara <sohara@paciellogroup.com> 
Sent: Tuesday, July 9, 2019 3:47 PM
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>
Subject: Re: AccName exclusion of groups and menus from content when calculating treeitem and menuitem names

 

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 <mailto:bryan.garaventa@levelaccess.com> >
Date: Tuesday, July 9, 2019 at 6:19 PM
To: Matt King <a11ythinker@gmail.com <mailto:a11ythinker@gmail.com> >, 'Aaron Leventhal' <aleventhal@google.com <mailto:aleventhal@google.com> >
Cc: 'Simon Pieters' <simon@bocoup.com <mailto:simon@bocoup.com> >, 'ARIA Working Group' <public-aria@w3.org <mailto: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 <mailto: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 <mailto:Bryan.Garaventa@LevelAccess.com> 

415.624.2709 (o)

 <http://www.levelaccess.com/> www.LevelAccess.com

 

From: Matt King <a11ythinker@gmail.com <mailto:a11ythinker@gmail.com> > 
Sent: Monday, July 08, 2019 11:55 PM
To: 'Aaron Leventhal' <aleventhal@google.com <mailto:aleventhal@google.com> >
Cc: Bryan Garaventa <bryan.garaventa@levelaccess.com <mailto:bryan.garaventa@levelaccess.com> >; 'Simon Pieters' <simon@bocoup.com <mailto:simon@bocoup.com> >; 'ARIA Working Group' <public-aria@w3.org <mailto: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 <mailto:aleventhal@google.com> > 
Sent: Monday, July 8, 2019 10:27 AM
To: Matt King <a11ythinker@gmail.com <mailto:a11ythinker@gmail.com> >
Cc: Bryan Garaventa <bryan.garaventa@levelaccess.com <mailto:bryan.garaventa@levelaccess.com> >; Simon Pieters <simon@bocoup.com <mailto:simon@bocoup.com> >; ARIA Working Group <public-aria@w3.org <mailto: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 <mailto: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 <mailto:aleventhal@google.com> > 
Sent: Monday, July 8, 2019 7:08 AM
To: Bryan Garaventa <bryan.garaventa@levelaccess.com <mailto:bryan.garaventa@levelaccess.com> >
Cc: Matthew King <mck@fb.com <mailto:mck@fb.com> >; Simon Pieters <simon@bocoup.com <mailto:simon@bocoup.com> >; ARIA Working Group <public-aria@w3.org <mailto: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 <mailto: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 <mailto:Bryan.Garaventa@LevelAccess.com> 

415.624.2709 (o)

 <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.levelaccess.com_&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=O5KcpICX8LHGtRJi41yDlw&m=dNhcM0HAGmN0k1jBT2L-4ZZxvSGqAzKSD-c0CnzLskw&s=GwB8g_FKiGiv0GII9xH7xjrQR6R58fPv4bywmkCXIrU&e=> www.LevelAccess.com

 

From: Matthew King <mck@fb.com <mailto:mck@fb.com> > 
Sent: Tuesday, June 25, 2019 5:34 PM
To: Aaron Leventhal (aleventhal@google.com <mailto:aleventhal@google.com> ) <aleventhal@google.com <mailto:aleventhal@google.com> >; Bryan Garaventa <bryan.garaventa@levelaccess.com <mailto:bryan.garaventa@levelaccess.com> >
Cc: Simon Pieters <simon@bocoup.com <mailto: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 23:35:39 UTC