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 2, 2022 6:57PM


Hi,
I'm not sure why the other tools you mentioned are not reporting the correct behavior, but the Chrome Developer tool is correct. There is no accessible name.

You can verify this here
https://whatsock.github.io/w3c-alternative-text-computation/Editable%20Live%20Input%20AccName%20Test.html

E.G. Copy and paste the following.

<label hidden for="test">Something Hidden</label>
<input id="test" placeholder="Whatever">

In this case there is no correct accessible name, though the placeholder is a fallback and reported as the name to ensure accessibility at the barest minimum.

However, if you do the following instead:

<label id="lbl" hidden for="test">Something Hidden</label>
<input aria-labelledby="lbl" id="test" placeholder="Whatever">

Then the accessible name is "Something Hidden"

The reason being is that only aria-labelledby and aria-describedby are allowed to reference hidden content according to the accessible name computation.
https://www.w3.org/TR/accname-1.2/

All the best,
Bryan


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 Steve Green
Sent: Friday, September 2, 2022 3:36 PM
To: <EMAIL REMOVED>
Subject: [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 have a textbox that has a correctly associated text label, but the label is hidden using "display:none". The textbox also has placeholder text. I am trying to compute the accessible name to understand why Chrome developer tools say the textbox does not have an accessible name, but Axe, SortSite and ARC Toolkit do not report an error.

I have built a minimal test page at http://tpl1.com/sg/form-label.htm. Can anyone confirm my view that Chrome is probably getting it wrong? I find it difficult to believe that three different tool vendors would all make the same mistake.

I am using the Accessible Name Computation at https://w3c.github.io/html-aam/#input-type-text-input-type-password-input-type-number-input-type-search-input-type-tel-input-type-email-input-type-url-and-textarea-element-accessible-name-computation

Step 2 of the computation says "Otherwise use the associated label element's accessible name", and I believe that this is where the problem lies. Chrome developer tools show the label element's accessible name as being null rather than non-existent. The null value overrides the placeholder value, so Chrome reports that the accessible name is null.

I can't see what the tools are doing, but I suspect that they do not consider there to be a label element at all, because of the "display:none". Therefore they are using the placeholder text in their computation, so they do not report a fault.

Regards,
Steve Green
Managing Director
Test Partners Ltd
020 3002 4176 (direct)
0800 612 2780 (switchboard)
07957 246 276 (mobile)
020 7692 5517 (fax)
Skype: testpartners
<EMAIL REMOVED>
www.testpartners.co.uk

Connect to me on LinkedIn - http://uk.linkedin.com/in/stevegreen2