Account for title attribute and other aria-* description attributes

[scottaohara]

When reviewing #396, @cookiecrook made a good point about the use of an aria-describedby or aria-description along with a title attribute:

I think there are scenarios where implementations may still wish to map it [the title attribute] even if it's not used by name or description. Leaving that follow-on mapping optional before the final "is not mapped."

For example, I think once aria-description is implemented, browsers would still want to expose the title here as AXHelp in AX API.
<button aria-label="foo" aria-description="bar" title="bop">bif</button>

Rasing this here as the previous PR where this was brought up is going to be closed in favor of a new one for the mono repo

[MelSumner]

So AccName spec, IIRC, indicates that the first thing that is found should be returned and that's it. Especially for things that have string values like aria-label and aria-description. Since title is lower on the priority order list, it shouldn't be returned.

Even for things that accept multiple values, like aria-labelledby and aria-describedby, the IDREFs are gathered and compiled. If these attributes exist, then title, being lower on the priority list, is not accounted for.

What would be the rationalization of ensuring inclusion of the title attribute value if the accessible name or description is already present and accounted for? I'm curious.

[spectranaut]

From today's minutes: https://www.w3.org/2024/11/14-aria-minutes.html#ffff

There is some need to investigate what browser do with title in this scenario. This would involve making some test mark up and looking into the computed accessibility tree, or accessibility API, or investigation with screen readers. This would be a great "second issue" for interested new ARIA working group members!