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

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.

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