Re: AccName uncertainty for form field label

As specified in HTML, the for attribute ‘must’ be associated with an id, so without one it’s breaking. Per your thinking it’s the same as an undefined attribute, this is not correct.

 

So, regarding your example, apples and oranges a bit.  If an author provides an invalid role, e.g. empty string, UAs must treat the element as if no role has been applied to it, as specified in ARIA’s handling author errors.   

 

Label’s for attribute doesn’t have such a specified fallback.  If used it *must* be used as defined in HTML.  Which means it must point to a valid ID, and if an input is nested within it, that ID must be the ID of that input.  Otherwise, it’s invalid and produces less than ideal results, as noted.

 

Now, does that mean I think there shouldn’t be fallbacks?  No.  As I noted in my previous email.  However, that’s clearly not reality right now.

 

 

From: Bryan Garaventa <bryan.garaventa@levelaccess.com>
Date: Friday, March 6, 2020 at 4:02 PM
To: Scott O'Hara <sohara@paciellogroup.com>, 'ARIA' <public-aria@w3.org>
Subject: 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

415.624.2709 (o)

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