Relation to HTML-AAM not obvious

[xi]

I was not sure whether to post this issue on accname or html-aam, so maybe it needs to be moved.

The HTML Accessibility API Mappings (html-aam) document has a long section on Accessible Name and Description Computation that overwrites some aspect of this specification. This is not obvious when reading the accname specification. I think a note should be added.

On top of that, splitting the algorithm across two documents makes it even more complex. I understand that this is necessary to split out the bits that are specific to HTML. But it leads to some strange results. Consider the following example:

<input type="text" title="test" hidden />

• If you ignore html-aam, rule 2A applies and the empty string is returned.
• If you do not ignore html-aam, the accname algorithm is completely ignored (because no aria-label or aria-labelledby attribute is present) and the title "test" is returned instead.

I am not sure if this effect is intentional.

[jnurthen]

related #11

[stevefaulkner]

@xi this is an interesting one. In Firefox/chrome/Edge on windows 10 the hidden attribute removes the input from the accessibility tree, so the name calculation is moot. In IE11 hidden does not remove the input from the acc tree, but exposes it with an invisible state. The acc name for the input is still derived from the title attribute in this case.

test case

[zcorpan]

I think accname should either have a general language-agnostic algorithm with clear hooks for each language to define the relevant steps, or accname should just contain everything (HTML, SVG, what else?). The current setup with two conflicting specs is confusing, I can't tell what the expected behavior should be for e.g. this test case:

<fieldset title="Foo" aria-labelledby="nosuch">
 <legend></legend> <!-- empty -->
</fieldset>

In Safari and Chrome, the accessible name is "", in Firefox and Edge it is "Foo".

[xi]

related minutes from TPAC 2018: https://www.w3.org/2018/10/25-aria-minutes#item05