Re: AccName uncertainty for form field label

It’s invalid markup.  A label with a for attribute must not have an empty string. And if the label has a nested input, the for attribute’s value must match the ID of the nested input.

 

From: Bryan Garaventa <bryan.garaventa@levelaccess.com>
Date: Friday, March 6, 2020 at 3:41 PM
To: Bryan Garaventa <bryan.garaventa@levelaccess.com>, Scott O'Hara <sohara@paciellogroup.com>, 'ARIA' <public-aria@w3.org>
Subject: RE: AccName uncertainty for form field label

 

Hi,

One last question about the implicit label issue.

 

I get the HTML AAM spec for a label element with a for=”whatever” as referencing another field, however this one makes no sense to me.

 

Why should this fail?

 

<label for=””>Email:

<input type=”text” />

</label>

 

In this case, an empty for attribute should be the same as an undefined attribute. At least, I can’t think of any reason why it should not. However, this results in no accessible name within mainstream browsers like Chrome and Firefox.

 

What is the logic for this?

 

Thanks,

Bryan

 

 

Bryan Garaventa

Principal Accessibility Architect

Level Access, Inc.

Bryan.Garaventa@LevelAccess.com

415.624.2709 (o)

www.LevelAccess.com

 

From: Bryan Garaventa <bryan.garaventa@levelaccess.com> 
Sent: Friday, March 6, 2020 12:16 PM
To: Scott O'Hara <sohara@paciellogroup.com>; 'ARIA' <public-aria@w3.org>
Subject: RE: AccName uncertainty for form field label

 

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.

 

Thanks, I’ve updated the prototype to handle this correctly. I also updated it to filter previously processed nodes in accordance with the algorithm as well.

 

As a reminder, I need feedback from interested parties to decide the course of label handling in the github issue at

https://github.com/w3c/accname/issues/78

 

This is to determine if an explicit label qualifies as an id reference in the same manner as an aria-labelledby traversal. I will change whatever needs changing to match what the group wants on this.

 

Thanks,

Bryan

 

 

 

Bryan Garaventa

Principal Accessibility Architect

Level Access, Inc.

Bryan.Garaventa@LevelAccess.com

415.624.2709 (o)

www.LevelAccess.com

 

From: Scott O'Hara <sohara@paciellogroup.com> 
Sent: Thursday, March 5, 2020 5:16 PM
To: 'ARIA' <public-aria@w3.org>
Subject: Re: AccName uncertainty for form field label

 

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.

 

Seems to me that if it were to label the nested input, then it’d only be doing so to mitigate against author error AND there must be no input with the ID that matched the label’s for attribute.

 

From: Sina Bahram <sina@sinabahram.com>
Organization: Prime Access Consulting
Date: Thursday, March 5, 2020 at 6:14 PM
To: 'Bryan Garaventa' <bryan.garaventa@levelaccess.com>, 'ARIA' <public-aria@w3.org>
Subject: RE: AccName uncertainty for form field label
Resent-From: <public-aria@w3.org>
Resent-Date: Thu, 05 Mar 2020 23:14:01 +0000

 

I think it’s completely ambiguous.

 

The ‘for’ attribute is pointing somewhere else, so we need to decide whether encapsulation supersedes programmatic linking.

 

If later on there was an input with an id of ‘test’, I do think that it should also be “email:” , which of course would be suboptimal from an accessibility perspective, but at least not the worst situation of being unlabeled.