1488042 - Accessible name for fieldset is the legend's textContent when the legend is display: none

Status: NEW

(Core :: Disability Access APIs, defect, P3)

Description

[Simon Pieters [:zcorpan]]

From what I understand, display: none (and visibility: hidden) elements should not be included in accessible name.

Test at https://github.com/web-platform-tests/wpt/pull/12691

https://github.com/web-platform-tests/wpt/blob/8e12c9149bcc4a2122d5a3a699ea2abc5c90c4e6/html/semantics/forms/the-fieldset-element/accessibility/legend-display-none-manual.html

Expected "", got "Foo".

In Chrome, the accessible name is "".

Comment 1

[James Teh [:Jamie]]

Can you cite the section of the spec which supports this? We discussed similar behaviour related to the <label> element in bug 501580 comment 21 and later comments. The relevant spec is Accessible Name and Description Computation 1.1:
https://www.w3.org/TR/accname-1.1/
As I understand it, the spec tells us what should happen when calculating the name if an element is hidden and is *not* an associated label:

> A. 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.

In this case, I think it's fair to say that <legend> is "a native host language text alternative element". So, we must skip this rule. Looking further:

> D. Otherwise, if the current node's native markup provides an attribute (e.g. title) or element (e.g. HTML label) that defines a text alternative, return that alternative in the form of a flat string as defined by the host language, unless the element is marked as presentational (role="presentation" or role="none"). 

It doesn't mention what to do here if the native text alternative element is hidden. It talks about presentational, but that is very explicitly defined as role="presentation"/"none".

I think we definitely need some spec clarification here.

Comment 2

[Simon Pieters [:zcorpan]]

Spec clarification would certainly be good. Also see https://github.com/w3c/accname/issues/8