Re: Problem with AccName regarding recursively processed nodes

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> wrote:

> Didn’t Aaron already have a PR in progress to separate out the description
> algorithm?
> ------------------------------
> *From:* Bryan Garaventa <bryan.garaventa@levelaccess.com>
> *Sent:* Friday, February 4, 2022 10:44:55 AM
> *To:* James Nurthen <nurthen@adobe.com>; ARIA <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
>
> 415.624.2709 <(415)%20624-2709> (o)
>
> www.LevelAccess.com <http://www.levelaccess.com/>
>
>
>
> *From:* Bryan Garaventa <bryan.garaventa@levelaccess.com>
> *Sent:* Wednesday, February 2, 2022 12:55 PM
> *To:* James Nurthen <nurthen@adobe.com>; ARIA <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
>
> 415.624.2709 <(415)%20624-2709> (o)
>
> www.LevelAccess.com <http://www.levelaccess.com/>
>
>
>
> *From:* James Nurthen <nurthen@adobe.com>
> *Sent:* Wednesday, February 2, 2022 12:04 PM
> *To:* Bryan Garaventa <bryan.garaventa@levelaccess.com>; ARIA <
> 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>
> *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* <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
>
> 415.624.2709 <(415)%20624-2709> (o)
>
> www.LevelAccess.com <http://www.levelaccess.com/>
>
>
>