RE: AccName uncertainty for form field label

I understand it’s invalid markup, much like the following.

<a role="" href="#"> Test </a>

Should that really destroy the accessibility of the widget within browsers?



Bryan Garaventa
Principal Accessibility Architect
Level Access, Inc.
Bryan.Garaventa@LevelAccess.com<mailto:Bryan.Garaventa@LevelAccess.com>
415.624.2709 (o)
www.LevelAccess.com<http://www.levelaccess.com/>

From: Scott O'Hara <sohara@paciellogroup.com>
Sent: Friday, March 6, 2020 12:56 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.

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<mailto:bryan.garaventa@levelaccess.com>>
Date: Friday, March 6, 2020 at 3:41 PM
To: Bryan Garaventa <bryan.garaventa@levelaccess.com<mailto:bryan.garaventa@levelaccess.com>>, Scott O'Hara <sohara@paciellogroup.com<mailto:sohara@paciellogroup.com>>, 'ARIA' <public-aria@w3.org<mailto: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<mailto:Bryan.Garaventa@LevelAccess.com>
415.624.2709 (o)
www.LevelAccess.com<http://www.levelaccess.com/>

From: Bryan Garaventa <bryan.garaventa@levelaccess.com<mailto:bryan.garaventa@levelaccess.com>>
Sent: Friday, March 6, 2020 12:16 PM
To: Scott O'Hara <sohara@paciellogroup.com<mailto:sohara@paciellogroup.com>>; 'ARIA' <public-aria@w3.org<mailto: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<https://whatsock.github.io/w3c-alternative-text-computation/Editable%20Live%20Input%20AccName%20Test.html> 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<mailto:Bryan.Garaventa@LevelAccess.com>
415.624.2709 (o)
www.LevelAccess.com<http://www.levelaccess.com/>

From: Scott O'Hara <sohara@paciellogroup.com<mailto:sohara@paciellogroup.com>>
Sent: Thursday, March 5, 2020 5:16 PM
To: 'ARIA' <public-aria@w3.org<mailto: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<mailto:sina@sinabahram.com>>
Organization: Prime Access Consulting
Date: Thursday, March 5, 2020 at 6:14 PM
To: 'Bryan Garaventa' <bryan.garaventa@levelaccess.com<mailto:bryan.garaventa@levelaccess.com>>, 'ARIA' <public-aria@w3.org<mailto:public-aria@w3.org>>
Subject: RE: AccName uncertainty for form field label
Resent-From: <public-aria@w3.org<mailto: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.