Logic check: display:none + aria-hidden='false' in name-from-contents calculation

[joanmarie]

According to https://www.w3.org/wiki/AccName_1.1_Testable_Statements#Name_file-label-inline-hidden-elements, the accessible name should be "2 4 6 8 10". However, we have:

<span aria-hidden="false" class="hidden">9</span><span>10</span>

Step 2A of the AccName spec says:

If the current node is hidden and is not directly referenced by aria-labelledby or aria-describedby, nor directly referenced by a native host language text alternative element (e.g. label in HTML) or attribute, return the empty string.

Hidden is defined as:

Indicates that the element is not visible, perceivable, or interactive to any user. An element is considered hidden if it or any one of its ancestor elements is not rendered or is explicitly hidden.

aria-hidden set to false means it is included in the accessibility tree and thus potentially perceivable to users of assistive technologies.

So should the results be "2 4 6 8 9 10" instead?

[JAWS-test]

I don't think so: display:none is stronger than aria-hidden

[jnurthen]

Is this based on spec language somewhere?

[JAWS-test]

I think indirectly yes, because the ARIA specification says that HTML attributes are stronger than ARIA attributes. And display:none is equivalent to the hidden attribute. But it's a borderline case which is not exactly regulated....

[jnurthen]

I don't read the spec text as saying this.

When WAI-ARIA states and properties correspond to host language features that have the same implicit WAI-ARIA semantic,

Here they do not have the same semantic as aria-hidden=false is explicitly defined as "not mapped" in CORE-AAM

it can be particularly problematic to use the WAI-ARIA feature. If the WAI-ARIA feature and the host language feature are both provided but their values are not kept in sync, user agents and assistive technologies cannot know which value to use. Therefore, to prevent providing conflicting states and properties to assistive technologies, host languages MUST explicitly declare where the use of WAI-ARIA attributes on each host language element conflicts with native attributes for that element.

https://www.w3.org/TR/html-aria/#allowed-aria-roles-states-and-properties allows aria-hidden on any element so there is no conflict defined there

When a host language declares a WAI-ARIA attribute to be in direct semantic conflict with a native attribute for a given element, user agents MUST ignore the WAI-ARIA attribute and instead use the host language attribute with the same implicit semantic.

So this does not apply according to the spec.

Host languages MAY document features that cannot be overridden with WAI-ARIA (these are called "strong native semantics"). These can be features that have implicit WAI-ARIA semantics, as well as features where the processing would be uncertain if the semantics were changed with WAI-ARIA. Conformance checkers MAY signal an error or warning when a WAI-ARIA role is used on elements with strong native semantics, but as described above, user agents MUST still use the value of the semantic of the WAI-ARIA role when exposing the element to accessibility APIs unless the native host language semantic is permanently presentational.

I don't believe HTML (or CSS) defines display:none as a strong native semantic so don't think this applies.

[jnurthen]

note: I'm not saying this is the wrong interpretation - just that I can't find it documented - and if this is the correct interpretation it needs to be written into a spec somewhere.

[JAWS-test]

@jnurthen I'm afraid I don't really understand your arguments. hidden is mapped to aria-hidden=true, just as, for example, required is mapped to aria-required (https://www.w3.org/TR/html-aam-1.0/).

Since HTML attributes are stronger than ARIA attributes:

<input required aria-required=false> is a required field.

Likewise, it should be true that:

<input hidden aria-hidden=false> is not in the Accessbility tree.

[jnurthen]

@joanmarie I think I agree with you - but I would never recommend that someone do such a thing. If indeed all browsers pass this check consistently then IMO we should clarify the spec language to match this reality rather than try to change implementations to match spec language.
If someone wants to include text for screen readers only in this way then the standard hidden CSS class works well - we don't need to solve this problem in ARIA.

[joanmarie]

Firefox passes it; Chrome fails it both in terms of spacing and in terms of including the 9. A colleague of mine is fixing the spacing. We don't know what to do about the 9 because of the spec text.

[JAWS-test]

Also hidden and visibility:hidden are overridden by aria-hidden=false in Chrome. However, it is interesting to note that it is not overridden on the element itself, but only if the hidden element is part of a label. I.e. <span hidden aria-hidden=false> is not in the tree with its text content as the label, but if the span is in a button, the text content of the span is used as the label of the button. Strange also that aria-hidden=false overrides the hidden only if they are on the same element. If aria-hidden is inside hidden, it has no effect

[jnurthen]

linking w3c/core-aam#58

[accdc]

Personally I've never been in favor of using aria-hidden="false" to override visually hidden elements to expose them to screen reader users. Mainly because I've seen how this can be abused. E.G. If a dev does this and the hidden content includes active elements like links and form fields, then all of these elements are also exposed to the user, and are totally impossible to interact with or do anything with.

I gave up a long time ago trying to get this removed from the spec, so I guess we just try to document what the majority of browsers are already doing and let things fall where they may.