RE: AccName uncertainty for form field label

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>
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<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.