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

Hi Matt,
Unfortunately I can’t see a way of this working without either ignoring restrictions in all cases, or following a single guiding principle for all of them based on a documented definable characteristic. In this case, the characteristic is the lack of support for ‘name from content’ for that role.

Unfortunately this does not hold true in every single case equally a cross the board, so we will need to define a logic tree for this purpose to make this interoperable going forward.

I’ve done extensive testing using Aaron’s original algorithm for this purpose, and have tweaked it in some minor ways as documented below, but it does appear to provide the most accessible name computation results in the widest range of cases that I’ve attempted.

If we throw this out and go back to where anything goes without a defining characteristic to bind them, in the long run, this will only impair the viability of future implementations that require a more stable structure to work from.

Here is the copy from my current logic tree outline document for reference.

Name From Content: Any element with an ARIA role mapping that supports 'name from content' as part of its role definition within the ARIA specification.

Exceptions Rule Checklist: A checklist that determines when to process name from contents as part of the recursion algorithm, which is necessary to differentiate names computed on focusable roles, as opposed to parsing name from contents of the same roles when embedded within different roles. To understand the background of this, please read the discussion thread:   https://lists.w3.org/Archives/Public/public-aria/2017Jun/0057.html


    // Always include name from content when the referenced node matches list1, as well as when child nodes match those within list3
    // Note: gridcell was added to list1 to account for focusable gridcells that match the ARIA 1.0 paradigm for interactive grids.
    // So too was row to match 'name from author' and 'name from content' in accordance with the spec.
var list1 = {
roles: ["button", "checkbox", "link", "option", "radio", "switch", "tab", "treeitem", "menuitem", "menuitemcheckbox", "menuitemradio", "row", "cell", "gridcell", "columnheader", "rowheader", "tooltip", "heading"],
tags: ["a", "button", "summary", "input", "h1", "h2", "h3", "h4", "h5", "h6", "menuitem", "option", "tr", "td", "th"]
};

    // Never include name from content when current node matches list2
    // The rowgroup role was added to prevent 'name from content' in accordance with relevant ARIA 1.1 spec changes.
    // The fieldset element and group role was added to account for implicit mappings where name from content is not supported.
var list2 = {
roles: ["application", "alert", "log", "marquee", "timer", "alertdialog", "dialog", "banner", "complementary", "form", "main", "navigation", "region", "search", "article", "document", "feed", "figure", "img", "math", "toolbar", "menu", "menubar", "grid", "listbox", "radiogroup", "textbox", "searchbox", "spinbutton", "scrollbar", "slider", "tablist", "tabpanel", "tree", "treegrid", "separator", "rowgroup", "group"],
tags: ["article", "aside", "body", "select", "datalist", "optgroup", "dialog", "figure", "footer", "form", "header", "hr", "img", "textarea", "input", "main", "math", "menu", "nav", "section", "thead", "tbody", "tfoot", "fieldset"]
};

    // As an override of list2, conditionally include name from content if current node is focusable, or if the current node matches list3 while the referenced parent node (root node) matches list1.
var list3 = {
roles: ["term", "definition", "directory", "list", "note", "status", "table", "contentinfo"],
tags: ["dl", "ul", "ol", "dd", "details", "output", "table"]
};

    // Subsequent roles added as part of the Role Parity project for ARIA 1.2.
    // Tracks roles that don't specifically belong within the prior process lists, but shouldn't have any impact on name from content processing.
    // More need to be added …
var list4 = {
roles: ["legend"],
tags: ["legend"]
};


Bryan Garaventa
Principal Accessibility Architect
Level Access, Inc.
Bryan.Garaventa@LevelAccess.com
415.624.2709 (o)
www.LevelAccess.com<http://www.levelaccess.com/>

From: Matt King <a11ythinker@gmail.com>
Sent: Tuesday, July 09, 2019 4:35 PM
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>
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.

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<mailto:sohara@paciellogroup.com>>
Sent: Tuesday, July 9, 2019 3:47 PM
To: Bryan Garaventa <bryan.garaventa@levelaccess.com<mailto:bryan.garaventa@levelaccess.com>>; 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

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)
www.LevelAccess.com<http://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)
www.LevelAccess.com<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=>

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