hidden and css visibility

[eps1lon]

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.

-- https://rawgit.com/w3c/aria/master/#terms

It is currently not clear to me what "rendered" means in a browser context. We have display and visibility to control how an element is displayed. By setting display: none it will be invisible and not take up any space. If visiblity: hidden is used it will be invisible but take up space.

visbility: hidden can be "disabled" by descendants. As it stands right now chromes a11y tree includes these item. NVDA is also announcing those elements and even considering them when counting listitems.

This means visbility: visible can be used to put elements back in the a11y tree (if the parent is hidden) while aria-hidden=false will not (if the parent is aria-hidden).

Would it make sense to change the wording (rendered -> displayed) or rather add a note that visibility: hidden does not necessarily remove the whole subtree?

Edit: I just discovered https://www.w3.org/TR/wai-aria-1.2/#tree_exclusion which tells me it is indeed intended that hidden -> visible nesting will include the visible element in the tree. Maybe link to that section from the hidden terminology?

[eps1lon]

After posting this I discovered https://www.w3.org/TR/wai-aria-1.2/#tree_exclusion

Elements, including their descendent elements, that have host language semantics specifying that the element is not displayed, such as CSS display:none, visibility:hidden, or the HTML 5 hidden attribute.

This makes sense for display: none because it is not inherited and you can't make an element re-appear anyway if a child of display: none has display: block. It also makes sense for hidden since it's recommended to UAs to render hidden as display: none. However, visibility is inherited and can be overridden e.g. the list in <main style="visibility: hidden"><ul style="visbility: visible" /></main> will be announced by NVDA and is included in the accessiblity tree in the chrome dev tools.

Would you consider this a bug in the implementations or incomplete wording in the spec in which case adding something like "visibility: hidden does not necessarily affect descendants" might be helpful.

[JAWS-test]

This is definitely not a bug in the implementation, but a non-exact formulation in the specification. It is correct that visibility:hidden does not automatically hide all child elements, as is the case with aria-hidden=true, display:none and hidden.

[eps1lon]

Edit: I completely missed your point? You were saying aria-hidden should hide all descendants, yes?

as is the case with aria-hidden=true, display:none and hidden.

aria-hidden should specifically hide descendants as per

Elements, including their descendants, that have aria-hidden set to true. In other words, aria-hidden="true" on a parent overrides aria-hidden="false" on descendants.

-- https://www.w3.org/TR/wai-aria-1.2/#tree_exclusion

This matches NVDA and chrome's a11y tree.

As to display: none I didn't find any mention in the spec but you can't somehow "override" this. A child specifying display: block will still be not displayed if any parent has display: none.

As per recommendation of the living standard

[hidden], area, base, basefont, datalist, head, link, meta, noembed,
noframes, param, rp, script, source, style, template, track, title {
display: none;
}

-- https://html.spec.whatwg.org/multipage/rendering.html#hidden-elements

hidden will also hide any descendant regardless of their specified display value.

This also matches NVDA and chrome's a11y tree

[JAWS-test]

Sorry, I may have been inaccurate:

• visibility:hidden does not automatically hide all child elements
• all others always automatically hide all child elements, no matter how they are marked

[Jym77]

We encounter the same issue in ACT rules.
I do agree that the current text for tree exclusion is at least misleading:

Elements, including their descendent elements, that have host language semantics specifying that the element is not displayed, such as CSS display:none, visibility:hidden, or the HTML hidden attribute.

This does sounds like it says that descendants of visibility:hidden elements are also excluded from the accessibility tree, which is not the case in practice.

However, the "host language semantics" of CSS is clear that visibility: hidden can be overriden:

The generated box is invisible (fully transparent, nothing is drawn), but still affects layout. Furthermore, descendants of the element will be visible if they have visibility: visible.

So stopping before the examples "Elements, including their descendent elements, that have host language semantics specifying that the element is not displayed" is technically correct 🤷

[a11ydoer]

reference to Accname PR 137 where we dicussed "rendered tree" cases in ARIA meeting minutes

[spectranaut]

We update the definition of 'hidden' here, and I think it resolves this issue: #1856