RE: AccName uncertainty for form field label

That's fine with me. The difficulty I was trying to work out had to do with role=label and role parity and how this was applicable within AccName.


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: James Nurthen <nurthen@adobe.com>
Sent: Friday, March 6, 2020 3:54 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

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.

Aria-labelledby is ours to define how it works. We deal with this scenario explicitly in ACCNAME as you note

The definition of whether a label is associated with a form field is defined in the HTML specification. If we believe this is wrong - or even if we think there should be a fallback in certain cases - then the only method I'm comfortable with to change it is to log a bug against the HTML specification to change that definition.

James Nurthen  |  Accessibility Engineer  |  Adobe  |  p. 415.832.2734  |  c. 415.987.1918  |  nurthen@adobe.com<mailto:nurthen@adobe.com>



From: Bryan Garaventa <bryan.garaventa@levelaccess.com<mailto:bryan.garaventa@levelaccess.com>>
Date: Friday, March 6, 2020 at 2:29 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
Okay, that's true about role being like apples and oranges, but in ARIA terms, the logic is similar to saying that the presence of aria-labelledby="" on something should prevent an accessible name from being computed.

This doesn't make sense to me, but I'll make note of it.

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: Friday, March 6, 2020 1:34 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.

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<mailto:bryan.garaventa@levelaccess.com>>
Date: Friday, March 6, 2020 at 4:02 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

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<mailto:sohara@paciellogroup.com>>
Sent: Friday, March 6, 2020 12:56 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.

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.