E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 5 (In chronological order)

From: Steve Green
Date: Fri, Sep 02 2022 4:36PM
Subject: Computing a textbox's accessible name when its label is hidden using display:none
No previous message | Next message →

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 ADDRESS REMOVED =
www.testpartners.co.uk
 
Connect to me on LinkedIn - http://uk.linkedin.com/in/stevegreen2

From: Bryan Garaventa
Date: Fri, Sep 02 2022 6:57PM
Subject: Re: Computing a textbox's accessible name when its label is hidden using display:none
← Previous message | Next message →

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 ADDRESS REMOVED =
415.624.2709 (o)
www.LevelAccess.com

-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Steve Green
Sent: Friday, September 2, 2022 3:36 PM
To: = EMAIL ADDRESS 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 ADDRESS REMOVED =
www.testpartners.co.uk

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

From: glen walker
Date: Fri, Sep 02 2022 10:54PM
Subject: Re: Computing a textbox's accessible name when its label is hidden using display:none
← Previous message | Next message →

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?

From: Bryan Garaventa
Date: Sat, Sep 03 2022 1:27AM
Subject: Re: Computing a textbox's accessible name when its label is hidden using display:none
← Previous message | Next message →

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 ADDRESS REMOVED =
415.624.2709 (o)
www.LevelAccess.com

-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of glen walker
Sent: Friday, September 2, 2022 9:54 PM
To: WebAIM Discussion List < = EMAIL ADDRESS 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?

From: Bryan Garaventa
Date: Sat, Sep 03 2022 6:05PM
Subject: Re: Computing a textbox's accessible name when its label is hidden using display:none
← Previous message | No next message

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 ADDRESS REMOVED =
415.624.2709 (o)
www.LevelAccess.com

-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Bryan Garaventa via WebAIM-Forum
Sent: Saturday, September 3, 2022 12:27 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Cc: Bryan Garaventa < = EMAIL ADDRESS 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 ADDRESS REMOVED =
415.624.2709 (o)
www.LevelAccess.com

-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of glen walker
Sent: Friday, September 2, 2022 9:54 PM
To: WebAIM Discussion List < = EMAIL ADDRESS 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?