RE: Problem with AccName regarding recursively processed nodes

Regarding the recursive node issue, it looks like the browsers are treating the computation of name and description as separate tracks even though the root node is the same origin process.

E.G. This markup results in the same name and description being set separately on the same root node in both Firefox and Chrome.

<div id="bob">
<a id="test" href="foo" aria-describedby="bob">Some Text</a>
Or Other
</div>

Name: “Some Text”
Desc: “Some Text Or Other”

There isn’t anything wrong with that, and this is what I would expect to happen anyway, though the mechanism for doing this is not actually specified in the spec. I’m not sure where it would be good to do this, so suggestions are welcome.

In the meantime, I have updated the AccName Prototype code to reflect this at.
https://whatsock.github.io/w3c-alternative-text-computation/Editable%20Live%20Input%20AccName%20Test.html


Thanks,
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: Bryan Garaventa
Sent: Tuesday, March 8, 2022 3:31 PM
To: Aaron Leventhal <aleventhal@google.com>
Cc: James Nurthen <nurthen@adobe.com>; ARIA <public-aria@w3.org>
Subject: RE: Problem with AccName regarding recursively processed nodes

Okay,
I apologize it took me longer than I expected to parse all of the thread. I commented on it to get things moving hopefully soon.

However, the referenced issue doesn’t actually address my original question of this thread, which is still unclear.

Is it everyone’s understanding that nodes that are parsed more than once should be computed regardless if the same nodes are referenced separately by first the name and then the description in that order?

If yes, then I will need to make a note of that somewhere.

Thanks,
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: Aaron Leventhal <aleventhal@google.com<mailto:aleventhal@google.com>>
Sent: Saturday, February 5, 2022 8:47 AM
To: Bryan Garaventa <bryan.garaventa@levelaccess.com<mailto:bryan.garaventa@levelaccess.com>>
Cc: James Nurthen <nurthen@adobe.com<mailto:nurthen@adobe.com>>; ARIA <public-aria@w3.org<mailto:public-aria@w3.org>>
Subject: Re: Problem with AccName regarding recursively processed nodes

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.

This one: https://github.com/w3c/accname/pull/69


On Fri, Feb 4, 2022 at 8:40 PM Bryan Garaventa <bryan.garaventa@levelaccess.com<mailto:bryan.garaventa@levelaccess.com>> wrote:
My apologies, I lost track of it.

I won’t be around during our meeting time next week, but if you could please send me the link to review, it would be great for us to revisit that the week after and hopefully we can nail this down then.

Thanks,
Bryan



Bryan Garaventa
Principal Accessibility Architect
Level Access, Inc.
Bryan.Garaventa@LevelAccess.com<mailto:Bryan.Garaventa@LevelAccess.com>
415.624.2709<tel:(415)%20624-2709> (o)
www.LevelAccess.com<http://www.levelaccess.com/>

From: Aaron Leventhal <aleventhal@google.com<mailto:aleventhal@google.com>>
Sent: Friday, February 4, 2022 2:08 PM
To: James Nurthen <nurthen@adobe.com<mailto:nurthen@adobe.com>>
Cc: Bryan Garaventa <bryan.garaventa@levelaccess.com<mailto:bryan.garaventa@levelaccess.com>>; ARIA <public-aria@w3.org<mailto:public-aria@w3.org>>
Subject: Re: Problem with AccName regarding recursively processed nodes

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.

Yes, I asked for help getting it completed, and there were comments from James Craig that needed to be addressed.

On Fri, Feb 4, 2022 at 3:03 PM James Nurthen <nurthen@adobe.com<mailto:nurthen@adobe.com>> wrote:
Didn’t Aaron already have a PR in progress to separate out the description algorithm?
________________________________
From: Bryan Garaventa <bryan.garaventa@levelaccess.com<mailto:bryan.garaventa@levelaccess.com>>
Sent: Friday, February 4, 2022 10:44:55 AM
To: James Nurthen <nurthen@adobe.com<mailto:nurthen@adobe.com>>; ARIA <public-aria@w3.org<mailto:public-aria@w3.org>>
Subject: RE: Problem with AccName regarding recursively processed nodes


Okay,

I’ve been looking into this further, and have a proposal that may solve the discrepancy. I need agreement on this, so please say if this will work or if the logic of it needs tweaking.



Proposal



To specify in the spec that there are 2 iterations of the algorithm, one to compute the name, and a second to compute the description. The name is processed first, followed by the description.



This would be added to the normative section directly before the algorithm steps are documented.



Question



If this is acceptable, how should nodes be handled if both iterations reference the same nodes?



If anyone has any other ideas for solving this, please let me know.



Thanks,

Bryan











Bryan Garaventa

Principal Accessibility Architect

Level Access, Inc.

Bryan.Garaventa@LevelAccess.com<mailto:Bryan.Garaventa@LevelAccess.com>

415.624.2709<tel:(415)%20624-2709> (o)

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



From: Bryan Garaventa <bryan.garaventa@levelaccess.com<mailto:bryan.garaventa@levelaccess.com>>
Sent: Wednesday, February 2, 2022 12:55 PM
To: James Nurthen <nurthen@adobe.com<mailto:nurthen@adobe.com>>; ARIA <public-aria@w3.org<mailto:public-aria@w3.org>>
Subject: RE: Problem with AccName regarding recursively processed nodes



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.



I understand what you mean, but I can’t find anything that says that.



It would probably be okay to run the algorithm as two different processes, one for name and another for description, but this needs to be stated somewhere that it will do this.



At the least, the following would need to be changed.



“Important: Each

node

 in the subtree is consulted only once. If text has been collected from a descendant, but is referenced by another IDREF in some descendant node, then

that second, or subsequent, reference is not followed. This is done to avoid infinite loops.”



There is no destinction between one type of idref versus another in this statement.



Thanks, I appreciate the help with this.



Bryan Garaventa

Principal Accessibility Architect

Level Access, Inc.

Bryan.Garaventa@LevelAccess.com<mailto:Bryan.Garaventa@LevelAccess.com>

415.624.2709<tel:(415)%20624-2709> (o)

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



From: James Nurthen <nurthen@adobe.com<mailto:nurthen@adobe.com>>
Sent: Wednesday, February 2, 2022 12:04 PM
To: Bryan Garaventa <bryan.garaventa@levelaccess.com<mailto:bryan.garaventa@levelaccess.com>>; ARIA <public-aria@w3.org<mailto:public-aria@w3.org>>
Subject: Re: Problem with AccName regarding recursively processed nodes



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.



I have always read the computation of Accessible Name and Accessible Description as separate invocations of the algorithm.

I can compute either a description or a name and the same node can be referenced in either calculation.



Aaron? How do the actual implementations actually do this?

________________________________

From: Bryan Garaventa <bryan.garaventa@levelaccess.com<mailto:bryan.garaventa@levelaccess.com>>
Sent: Wednesday, February 2, 2022 10:54 AM
To: ARIA <public-aria@w3.org<mailto:public-aria@w3.org>>
Subject: Problem with AccName regarding recursively processed nodes



Hi,

Yesterday I received an issue report about the live algorithm code for AccName that I maintain, and I thought it was a simple bug to fix. In looking at this further though, I’m not so sure, and need some feedback from those here to figure out which it is.



The problem, the following code results in no accessible name, but only a description.



<div id="bob">

<a id="test" href="foo" aria-describedby="bob">Some Text</a>

</div>



If you remove aria-describedby, then it results in an accessible name as expected.



This seems like a simple fix, but it’s not.



The reason why this is complicated is because of the following text in the AccName spec.



Important: Each node<https://www.w3.org/TR/wai-aria-1.2/#dfn-node> in the subtree is consulted only once. If text has been collected from a descendant, but is referenced by another IDREF in some descendant node, then that second, or subsequent, reference is not followed. This is done to avoid infinite loops.



Since the AccName algorithm is linear, the result of it not producing an accessible name is actually correct.



The reason being, the algorithm has to be followed in the steps they are documented.

If either aria-labelledby or aria-describedby is present, the nodes that they reference have to be followed before the other steps that occur afterwards in the algorithm.

As a result, all the nodes that are supposed to be processed if aria-describedby were not present have already been processed because aria-describedby references the same nodes beforehand.

And, as the spec clearly states, you can only process a node once and not during any other iterations within the same process.



So, this is why this code does not result in an accessible name.



My question is, should this be changed, and if so, you should realize that this will impact everything everywhere if it is.



Thanks,

Bryan





Bryan Garaventa

Principal Accessibility Architect

Level Access, Inc.

Bryan.Garaventa@LevelAccess.com<mailto:Bryan.Garaventa@LevelAccess.com>

415.624.2709<tel:(415)%20624-2709> (o)

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