Re: Problem with AccName regarding recursively processed nodes

> On Feb 2, 2022, at 12:06 PM, Scott O'Hara <scott.ohara@microsoft.com> wrote:
> 
> 
> Yeh… I would have expected this to run similarly to how James interpreted this.

Same here.

> In reality, would clarifying this / correcting this actually cause issues?  For instance, testing the pattern I did not run into an instance where the link did not have a name with Webkit, Gecko and Chromium.
>  
> From: James Nurthen
> Sent: Wednesday, February 2, 2022 3:04 PM
> To: Bryan Garaventa; ARIA
> Subject: [EXTERNAL] Re: Problem with AccName regarding recursively processed nodes
>  
> 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>
> Sent: Wednesday, February 2, 2022 10:54 AM
> To: ARIA <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 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
> 415.624.2709 (o)
> www.LevelAccess.com
>  
>