Should all roles participate in the name calculation of ancestors in name from content (Step 2H)

[joanmarie]

A real-world use case: https://nakup.itesco.cz/groceries/

If you examine the menubar at the top in Chrome's Accessibility dev tool, you'll see the menubar has the following children:

• menuitem "Register"
• menuitem "#"
• menuitem
• menuitem "Help"

The third, nameless menuitem has the following markup (much of which I've simplified or removed, leaving the use case):

<li role="menuitem">
    <form method="post">
        <input type="hidden" name="requestedLang" value="cs-CZ">
        <input type="hidden" name="returnUrl" value="/groceries/en-GB">
        <button type="submit"><span>Česky</span><svg aria-hidden="true">...</svg></button>
     </form>
</li>

I am not an author, but that doesn't seem like an unreasonable thing to do.

And looking at the AccName spec, it appears to be allowed: We're doing name from contents on the menuitem. When the current node is the form, none of the steps apply until we get to 2H, which says:

Otherwise, if the current node is a descendant of an element whose Accessible Name or Accessible Description is being computed, and contains descendants, proceed to 2F.i.

That is the case for the form, so the algorithm says we descend that form and wind up with Česky as the menuitem's name.

But as I stated above, that's not the case for Chrome. Firefox has the same results (three named menuitems; one unnamed). While I've not confirmed it in the Firefox code, not descending the form is intentional in the Chromium code. Only a subset of the roles which do not support name from content participate in Chromium's name calculation of ancestors in name from content. If you're curious, see this code.

My proposed CL moves the form role to the subset of other roles which do contribute to name from content of ancestors. My gut tells me that's safe and the right thing to do. But I'm less sure about other roles. Like should it really descend an alert or a dialog or a document or a feed or .... On the one hand, I'd hope authors wouldn't give a name-from-content role a descendant feed; on the other hand, authors.... Hence the question: Should all roles participate in the name calculation of ancestors in name from content (Step 2H).

In Aaron's review of my CL, he said the following:

Hi Joanie, let's talk about this. I think it's a useful rule, and that AccName is missing the rule because the browser vendors never got around to adding it to AccName.

However, if we were to remove all of those roles from the switch, and allow them to contribute to ancestor names, I think it will cause issues. And I believe Firefox has some similar rules.

For example, if I build a tree view with nested <ul role=group"><li role="treeitem"> structures, I would end up with tree items that contained all of their descendants in their name.

Agree that it's not spec-conformant, but I think we should update the specs and not make the UA's less useful.

As an experiment, I suggest taking that whole group of roles and allowing them to contribute to their ancestors, and running it on a trybot, to see what changes.

So I'm going to do what he says and see what changes/breaks. In the meantime, I'm curious as to what others think. And what about the tree view with nested group+treeitem structures? That sounds like a mess....

[joanmarie]

Here's an example of the problem Aaron mentioned:

<ul role="tree">
  <li id="1" role="treeitem"><a href="#animals">Animals</a>
    <ul role="group">
      <li id="2" role="treeitem"><a href="#domesticated">Domesticated</a>
        <ul role="group">
          <li id="3" role="treeitem"><a href="#dog">Dog</a></li>
          <li id="4" role="treeitem"><a href="#cat">Cat</a></li>
        </ul>
      </li>
    </ul>
</ul>

Name of treeitem with id="1":
Current node is treeitem
2F applies: role allows name from content
Two descendants: link and group

Current node is link
2F applies: role allows name from content
Current node is text node child of link
2G applies: return "Animals"
Result for link: "Animals"
Interim accumulated text for treeitem with id="1": "Animals"

Current node is outer group.
2H applies: The current node is a descendant of an element whose name is being computed and contains descendants.
Proceed to 2F.i
One descendant: treeitem with id="2"

Current node is treeitem with id="2"
2F applies: role allows name from content
Two descendants: link and group

Current node is link
2F applies: role allows name from content
Current node is text node child of link
2G applies: return "Domesticated"
Result for link: "Domesticated"
Accumulated text for treeitem with id="2": "Domesticated"

Current node is inner group.
2H applies: The current node is a descendant of an element whose name is being computed and contains descendants.
Proceed to 2F.i
Two descendants: treeitem with id="3" and treeitem with id="4"
Each of these just have link children so I won't write it all out.
Total accumulated text for inner group: "Dog Cat"

Append that to the accumulated text for the treeitem with id="2" ("Domesticated")
Total accumulated text for treeitem with id="2": "Domesticated Dog Cat"
Total accumulated text for outer group: "Domesticated Dog Cat"
Append that to the accumulated text for the treeitem with id="1" ("Animals")

FINAL RESULT: The name of the treeitem with id="1" is "Animals Domesticated Dog Cat"

This seems really bad. But I think I'm interpreting 2H correctly. And I don't see any earlier step which would force an early return.

[JAWS-test]

I am unsure if according to the ARIA specification a menuitem may contain a form and a button. It doesn't explicitly say that it is forbidden, but in my opinion a menuitem should not contain other elements with a role. However, according to Accname, the entire text content should be used as the Accessible Name for the menuitem.

For the tree structure: This is a special case that is currently not covered by Accname. Of course, only the current item and not the nested items should be used as the name. For this, Accname would have to be adapted or the ARIA specification (e.g. by allowing treeitem only Name from Author or by not nesting the child elements of the treeitems inside them, but in the source code behind them).

[aleventhal]

I don't think we should be overly concerned about what the spec says for this one When we wrote the acc name spec, we neglected to write up this rule, which was necessary in to Firefox in order to get the tree examples being developed to work. Then Blink/Chrome added the rule in order to also work with these types of nested trees. I think the spec might need to be updated rather than the implementations, at least for the tree examples. If there are parts where the Chrome implementation doesn't make sense, I'm happy to update it. But, I'm not sure that a form inside of a menuitem is a good example of that.

[jnurthen]

How about in these cases we only descend into subtrees if the accessible name is empty? Returning something is always better than nothing. Wouldn't that resolve these issues?

[accdc]

I agree that some roles may benefit if allowed to fetch name from content, but also that we need to be really careful which ones and in which circumstances.

I personally am not a fan of the form within menuitem example, because it's the same concept of doing the same within a role=tab, or role=treeitem, or role=option, or role=radio, or role=checkbox, or role=link, or role=button, none of which will work there either. Plus, if we make it okay here, why not everywhere else?

As a pet peeve, I can't tell you how many times I've tried to interact with an active element widget role only to realize that it was misapplied and it was impossible to do because the scripting for activating the widget was actually on an element inside the element with the widget role, instead of on it as it needs to be to work correctly.

E.G. Such as having role=button on a div surrounding a form with a submit button, when only clicking the submit button will actually cause anything to happen, but keyboard focus can only be set to the div with role=button, making the form element impossible to activate.

For example, I see the following markup everywhere:

<ul role="menu">
<li role="menuitem">
<a href="#"> Profile </a>
</li>
</ul>

Or in many cases where role=menuitem is not even provided. You can see an example of this if you are running Visual ARIA
https://chrome.google.com/webstore/detail/visual-aria/lhbmajchkkmakajkjenkchhnhbadmhmk?hl=en-US

Open Twitter.com and login, then run Visual ARIA.
Below the Profile link there is a menu button named "More menu items", try opening that, and Visual ARIA will show you where roles are being misapplied.

I apologize for the rant, I guess this sort of annoys me a bit.

If the embedding of forms is allowable within such constructs, then what about the following? (Which is something I really have seen on a client site.)

<ul role="menu">
<li role="menuitem">
<form>
<label>Filter:
<input type="text">
</label>
<input type="submit">
</form>
</li>
</ul>

To conclude, I don't have a problem with including some roles within the name from content exclusion, however it is clear that by being overly permissive with antipatterns, we are minimizing the responsibility of developers to actually make these things work correctly for AT users.

[jnurthen]

Chrome's code for which roles contribute contents can be found at https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/modules/accessibility/ax_object.cc;l=5046?q=SupportsNameFromContents&sq=

[jnurthen]

Gecko rules seem to be at https://github.com/mozilla/gecko-dev/blob/1b2d6d65dfbbd4e2ac0b27a490296d13e2ebad02/accessible/base/nsTextEquivUtils.cpp#L333 with the roles defined in https://github.com/mozilla/gecko-dev/blob/8432d4fe31245ae9121231d7c0335aaa342675d2/accessible/base/RoleMap.h

[jnurthen]

and I think this is where webkit is doing this https://github.com/WebKit/WebKit/blob/d21c81a358cfbdf7df9b903cf14b55cfd2207fcd/Source/WebCore/accessibility/AccessibilityObject.cpp#L125

[jnurthen]

those who know the code better than me please correct

[joanmarie]

So the consensus seems to me to be the following: We don't like authors putting forms inside ARIA widget roles. If that is indeed the case, then I should abandon my Chromium CL and close the associated Chromium bug as WONTFIX.

But given that I'm seeing this in the wild, and apparently at least @accdc is as well, I believe we should do something in our spec(s) to cause validators to flag this sort of authoring.

In addition, I think it might be worthwhile to add language to the AccName spec so that authors have a better idea about which roles participate in the name-from-content calculation of ancestors this can be based on what is already implemented in user agents if need be.

[JAWS-test]

Related: #120

[joanmarie]

Consensus from today's ARIA meeting: We should figure out what all the user agents are currently doing and add to the AccName spec language which clarifies which roles (e.g. form) will NOT participate in the name from content calculation of an ancestor.