E-mail List Archives
Re: Computing a textbox's accessible name when its label is hidden using display:none
From: glen walker
Date: Sep 2, 2022 10:54PM
- Next message: Bryan Garaventa: "Re: Computing a textbox's accessible name when its label is hidden using display:none"
- Previous message: Bryan Garaventa: "Re: Computing a textbox's accessible name when its label is hidden using display:none"
- Next message in Thread: Bryan Garaventa: "Re: Computing a textbox's accessible name when its label is hidden using display:none"
- Previous message in Thread: Bryan Garaventa: "Re: Computing a textbox's accessible name when its label is hidden using display:none"
- View all messages in this Thread
I thought I was pretty comfortable with the accessible name computation but
this is an interesting case and it made me read the "hidden" section more
carefully. Like Bryan, I'm aware of elements being hidden but still being
available via aria-labelledby. I actually use that feature quite a bit.
But if a <label> element is hidden, can it still be the accessible name for
a form element?
The accessible name computation URL that Steve posted is still a proposed
document, and it points to the proposed accessible name computation URL,
https://w3c.github.io/accname/#step2. The wording regarding hidden
elements is a little different in the new version so I'll fall back to the
latest published version, https://www.w3.org/TR/accname-1.2/#step2,
although we should get the same result using either spec.
If you start with Step 1 and "current node" is the <input> element, then 2A
checks if the current node is hidden. It's not (the <input> itself is not
hidden), so we go to 2B.
2B. The <input> does not have an aria-labelledby so we go to 2C.
2C. The <input> does not have an aria-label so we go to 2D.
2D. "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")."
Ok, so the current node (the <input>) does have an element that defines the
text alternative. It specifically calls out the <label> element as an
example. The spec does not say that the <label> must be unhidden. It does
say it can't be presentational. Does setting display:none make the <label>
presentational?
The HTML spec for the <label> element says that a <label> does not have a
role. See https://www.w3.org/TR/html-aria/#el-label. If a <label> does
not have a role, whether hidden or not, is it considered presentational?
Isn't no role the same as role="none"? But if that were true, then a
<label> would never be used as the accessible name, even when unhidden. So
I'm missing an obvious logic flaw somewhere.
So if the "display" setting of the <label> doesn't affect its role (unless
you did something weird like display:table), shouldn't the text in the
<label> always be used as the accessible name whether it's hidden or not?
So shouldn't Steve's example have "Search" as the accessible name of the
input?
- Next message: Bryan Garaventa: "Re: Computing a textbox's accessible name when its label is hidden using display:none"
- Previous message: Bryan Garaventa: "Re: Computing a textbox's accessible name when its label is hidden using display:none"
- Next message in Thread: Bryan Garaventa: "Re: Computing a textbox's accessible name when its label is hidden using display:none"
- Previous message in Thread: Bryan Garaventa: "Re: Computing a textbox's accessible name when its label is hidden using display:none"
- View all messages in this Thread