fix: link-name to be deciphered from children

[jeeyyy]

This PR fixes the rule link-name to take into consideration, nested children text content for deciphering accessibleTextVirtual.

This allows this rule to pass in scenarios like:

<a href="link"><span role="presentation">Link text</span></a>

<a id="pass11" href="link"><div>Some content</div><span role="presentation"></span></a>

Closes issue:

• Link-name fails with role="presentation" content #767

Reviewer checks

Required fields, to be filled out by PR reviewer(s)

• Follows the commit message policy, appropriate for next version
• Has documentation updated, a DU ticket, or requires no documentation change
• Includes new tests, or was unnecessary
• Code is reviewed for security by: << Name here >>

[WilcoFiers]

Bug day? I don't think this is the right fix. There seems to be a bug in our implementation of this spec: https://www.w3.org/TR/accname-1.1/#mapping_additional_nd_name

We need to figure out where our implementation is flawed, rather than to just hack in a solution for this one particular case. There is another case open around figure if I recall right that has the same issue.

[jeeyyy]

@WilcoFiers

Cool. There seems to be a lot of context on some of these bugs, that is not detailed in the issue tickets. I came up with this fix, after stepping through the current code base.

Can you link me to the issue for figure? In the interim I will go through the spec.

[WilcoFiers]

This one: #835. I've been thinking of rewriting this one ever since accname 1.1 hit candidate rec. I don't like the existing implementation. It's outdated, clunky and difficult to understand. Here's a draft of what I've been thinking of doing:

text.computationSteps = Object.freeze([
  getAriaLabelledbyText, // Step 2B.1
  getAriaDescribedbyText, // Step 2B.2
  getAriaLabelText, // Step 2C
  getNativeTextAlternative, // Step 2D
  getControlInLabelText, // Step 2E
  getNameFromContent, // Step 2F
  getTextNodeContent, // Step 2G
  getDescendingContentText, // Step 2H
  getTooltipText // Step 2I
])

text.accessibleTextVirtual = function accessibleTextVirtual (node, context = {}) { 
  // Step 2 A, check visibility
  if (!aria.isHidden(node, context)) {
    return ''
  }

  // Return the value of the first step that returns with text
  return text.computationSteps.reduce((text, step) => {
    if (test !== null) {
      return text
    }
    return text.sanitize(step(node, context))
  }, null)
}

/// ------- These can go into their own files:

function getAriaLabelledbyText () {}

function getAriaDescribedbyText () {}

function getAriaLabelText ({ actualNode }) {
  return actualNode.getAttribute('aria-label')
}

function getNativeTextAlternative () {}

function getControlInLabelText () {}

function getNameFromContent () {}

function getTextNodeContent ({ actualNode }) {
  if (actualNode.nodeType !== 3) {
    return null;
  }
  return actualNode.textContent;
}

function getDescendingContentText () {}

function getTooltipText ({ actualNode }) {
  return actualNode.getAttribute('title')
}

[WilcoFiers]

The bug seems to be a thing that was incorrect in an earlier version of the algorithm. The steps don't match anymore. Didn't dive into it too deeply, but it seems Step 2H was added to resolve the bug that we're seeing here. That step clearly wasn't part of the spec when we implemented it.

[WilcoFiers]

Some more thoughts. Most of these methods in my draft rewrite up there already exist in one for or another in checks. With this approach we deduplicate much of what we're doing in acc name computation.

[jeeyyy]

Decided to rewrite accessible-name rule. So closing PR