WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Computing a textbox's accessible name when its label is hidden using display:none

for

From: Bryan Garaventa
Date: Sep 3, 2022 6:05PM

To clarify one point, I am not saying that the accessible name should be exposed for hidden label elements, just that the expected functionality is not documented in the HTML spec as it should be.


Bryan Garaventa
Principal Accessibility Architect
Level Access, Inc.
<EMAIL REMOVED>
415.624.2709 (o)
www.LevelAccess.com

-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of Bryan Garaventa via WebAIM-Forum
Sent: Saturday, September 3, 2022 12:27 AM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Cc: Bryan Garaventa < <EMAIL REMOVED> >
Subject: Re: [WebAIM] Computing a textbox's accessible name when its label is hidden using display:none

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.


Hi,
Yes there is a logic flaw, but it's not with the role from what I can tell.

First, we are talking about two different specs. There's the AccName spec and the HTML spec.

The core AccName spec is meant to handle core functionality, and then the HTML spec uses this to handle relative elements for their native host semantic.

It used to be that within the HTML spec, hidden labels were not permitted because this is a flawed design pattern for accessibility, especially since it causes the automatic onclick functionality to be unusable for sighted mouse users.

The AccName spec, in contrast, only explicitly referenced the hidden state of ARIA attributes such as aria-labelledby and aria-describedby, and never the HTML label+input with matching for and ID attributes, which was always meant to be handled by the HTML spec.

From what I can see in the latest HTML spec though, the hidden state of a label is not mentioned at all, making it's functionality entirely unpredictable from a user agent implementor perspective. It is neither permitted nor forbidden,.

Personally I believe there is a bug here with regard to the HTML spec. The intended functionality does need to be documented so that user agents can expose it within the accessibility tree. At present, if you check the accessibility tree in Chrome, you will not see a name for hidden labels.

For now the label element does not map to any ARIA equivalent in the ARIA spec.
https://w3c.github.io/html-aria/
Mainly because there is no label role in ARIA as yet, though this is scheduled to be added.

So, it is not clear how hidden elements are meant to be handled in these cases as yet, and likely won't be for some time.



Bryan Garaventa
Principal Accessibility Architect
Level Access, Inc.
<EMAIL REMOVED>
415.624.2709 (o)
www.LevelAccess.com

-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of glen walker
Sent: Friday, September 2, 2022 9:54 PM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] Computing a textbox's accessible name when its label is hidden using display:none

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.


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?