E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 44 (In chronological order)

From: pratik roy
Date: Wed, Jul 25 2018 3:13AM
Subject: WCAG 2.1 - 1.3.5 - How to capture a violation?
No previous message | Next message →

Hi Everyone,

WCAG introduced this new guideline a part of there 2.1 release to provide
more purpose to the input fields. But my question is, how can we capture a
violation against this guideline? Beacuse currently there is on faliure
technique provided by WCAG.Although, there is a sufficient technique which
talks about use of auto-fill attributes in input fields.
But can we capture a violation if that sufficient technique is not followed
in a scenario?

Example: In a form, suppose we have two password fields one for current and
other one for new password. Purposeful label is provided for both but no
auto-fill="{current-password | new-password}". Now the question is, can we
capture a violation here?

Please share your thoughts.

Thanks & Regards
PRATIK ROY

From: Lovely, Brian
Date: Wed, Jul 25 2018 6:10AM
Subject: Re: [External Sender] WCAG 2.1 - 1.3.5 - How to capture a violation?
← Previous message | Next message →

-- From: PRATIK ROY: " Example: In a form, suppose we have two password fields one for current and other one for new password. Purposeful label is provided for both but no -- auto-fill="{current-password | new-password}". Now the question is, can we capture a violation here?"

This would have to be manually tested. Since there is no universal label for these fields, a machine couldn't tell what they were for and therefor wouldn't know what the correct values of the autofill field would be.




The information contained in this e-mail is confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.

From: Jonathan Avila
Date: Wed, Jul 25 2018 6:30AM
Subject: Re: WCAG 2.1 - 1.3.5 - How to capture a violation?
← Previous message | Next message →

At this time it is my understanding that the autocomplete attribute is the only sufficient technique for HTML.
So you could use a favlet such as the one I made at the following page (https://labs.levelaccess.com/index.php/Autocomplete_Attribute_Favlet) to display the autofill attributes. You would need to manually determine if the field needs to have it's purpose communicated programmatically and then if the right autocomplete attribute is used. The accessible name cannot be used to communicate the purpose.

1. Determine if field is related to information for the the user rather than other users or non-user information. Only information about the user is covered.
2. Determine if the purpose is listed in WCAG section 7 input purpose (https://www.w3.org/TR/WCAG21/#input-purposes)
3. Review the autocomplete attribute if one exists and determine if it is appropriate from the list above.

Jonathan

From: Jared Smith
Date: Wed, Jul 25 2018 7:15AM
Subject: Re: WCAG 2.1 - 1.3.5 - How to capture a violation?
← Previous message | Next message →

Jonathan -

The normative success criterion text does not require the autocomplete
attribute. It simply requires that the purpose of the field be
programmatically determined if it collects user information. While there is
a sufficient technique (which is non-normative) that allows you to meet
this SC by using the autocomplete attribute, this is not required - and
therefore it would not be a failure if autocomplete is not present in these
cases, so long as the purpose is programmatically identified with the field.

Of course 1.3.1 requires that the field information be programmatically
determined anyway, so 1.3.5 really just adds a SUGGESTION that you use
autocomplete, which does improve the user experience for those using form
fillers.

> The accessible name cannot be used to communicate the purpose

Why couldn't it? I see no suggestion from the normative text that the
accessible name could not be used. In fact, if you didn't use the
accessible name, then you'd likely fail 2.5.3.

Jared

From: Jonathan Avila
Date: Wed, Jul 25 2018 7:29AM
Subject: Re: WCAG 2.1 - 1.3.5 - How to capture a violation?
← Previous message | Next message →

Jared, in my message I did not say that the SC required autocomplete -- but that autocomplete was the only technique that I was aware of that was supported to communicate the purpose. Other techniques such as microdata could be used if accessibility supported. The accessible name is generally not seen to fall into that category because of localization and other issues make prevent it from clearly aligning without ambiguity. You'll notice that the list of purposes from Section 7 of WCAG 2.1 comes from HTML's autocomplete list. So while autocomplete is not required by the SC I am not aware of another method to use that will work given the limited browser support for microdata formats. ARIA in the future could provide this information but I am not aware today that it contains what is needed.

Jonathan

From: Jared Smith
Date: Wed, Jul 25 2018 8:15AM
Subject: Re: WCAG 2.1 - 1.3.5 - How to capture a violation?
← Previous message | Next message →

I'm still really confused by what you are suggesting. Again, where
does this success criterion state or suggest that accessible name
(e.g., <label>, aria-label, etc.) cannot be used to convey the
purpose?

1.3.1 allows (or nearly requires) that accessible name be used to
ensure that "information, structure, and relationships... can be
programmatically determined", so I can't see how 1.3.5, which requires
that "the purpose... can be programmatically determined" (nearly
identical wording), would prohibit this technique. "Programmatically
determined" can't mean two entirely different things for different
success criteria.

> The accessible name is generally not seen to fall into that category because of localization and other issues make prevent it from clearly aligning without ambiguity.

Where does the success criterion indicate or suggest that the purpose
has to be determined independent of localization or unambiguously? If
programmatically determined means "determined independent of
language", then it must also mean this in 1.3.1 (and elsewhere), which
would mean that all accessible names (if this was the chosen technique
for 1.3.1) would have to be language independent.

If the intent of this SC is to ensure that the purpose be identified
universally and unambiguously in all languages via some mechanism
other than accessible name, then it needs to be significantly edited
to indicate this. As is stands now, I see no way in which an
accessible name that conveys the purpose of the field would not be
sufficient to meet the normative text. If I'm wrong, I'm going to need
a much clearer explanation of how "programmatically determined" means
something different here than for the rest of WCAG.

Jared

From: Jon Brundage
Date: Wed, Jul 25 2018 9:20AM
Subject: Re: WCAG 2.1 - 1.3.5 - How to capture a violation?
← Previous message | Next message →

HI Jared-

You state:
"If I'm wrong, I'm going to need
a much clearer explanation of how "programmatically determined" means
something different here than for the rest of WCAG."

What is the definition of "programmatically determined" in your view?

Thanks,

Jon

From: Jared Smith
Date: Wed, Jul 25 2018 10:11AM
Subject: Re: WCAG 2.1 - 1.3.5 - How to capture a violation?
← Previous message | Next message →

Jon Brundage wrote:

> What is the definition of "programmatically determined" in your view?

Well, my view doesn't really matter much. :-) I've voiced concerns
over the ambiguity and difficulties with this term and its definition
since before 2.0 was finalized. Here's one reference from 2012
recommending that it be addressed in 2.1 -
https://webaim.org/blog/wcag-next/. But 2.1 did not entertain changes
to existing definitions or success criteria. Regardless, we do have a
normative definition of "programmatically determined" directly in WCAG
- https://www.w3.org/TR/WCAG21/#dfn-programmatically-determinable

If we look at the non-normative techniques for other success criteria
that use this term, they can provide some insight into what this term
means and what can be considered "programmatically determined". 1.3.1,
3.3.2, and 4.1.2, for example, all allow a form label or aria-label to
meet the "programmatically determined" requirements -
https://www.w3.org/TR/WCAG20-TECHS/H44.html. 2.4.4 allows aria-label
to meet the "programmatically determined" requirement for links -
https://www.w3.org/TR/WCAG20-TECHS/ARIA8.html This is why the
suggestion that an accessible name or label is not sufficiently
"programmatically determined" when it comes to 1.3.5 is rather
concerning.

To be clear, I fully support the use of autocomplete and would always
recommend this as a best practice, but I think it requires a very
broad and creative interpretation of 1.3.5 to suggest that
autocomplete is essentially required.

Jared

From: Patrick H. Lauke
Date: Wed, Jul 25 2018 10:14AM
Subject: Re: WCAG 2.1 - 1.3.5 - How to capture a violation?
← Previous message | Next message →

This has been the crux of the problem around 1.3.5. It really means "machine-readable", i.e. it needs to be part of a defined taxinomy that tools can use to determine the purpose of a control (and potentially offer useful behaviour, such as autofilling form fields). But in the context of 1.3.1 it's also about using semantically correct markup...you couldn't just rely on a set of spans and then give them a label of "list item" and call it good.

> On 25 Jul 2018, at 15:15, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
>
> I'm still really confused by what you are suggesting. Again, where
> does this success criterion state or suggest that accessible name
> (e.g., <label>, aria-label, etc.) cannot be used to convey the
> purpose?
>
> 1.3.1 allows (or nearly requires) that accessible name be used to
> ensure that "information, structure, and relationships... can be
> programmatically determined", so I can't see how 1.3.5, which requires
> that "the purpose... can be programmatically determined" (nearly
> identical wording), would prohibit this technique. "Programmatically
> determined" can't mean two entirely different things for different
> success criteria.
>
>> The accessible name is generally not seen to fall into that category because of localization and other issues make prevent it from clearly aligning without ambiguity.
>
> Where does the success criterion indicate or suggest that the purpose
> has to be determined independent of localization or unambiguously? If
> programmatically determined means "determined independent of
> language", then it must also mean this in 1.3.1 (and elsewhere), which
> would mean that all accessible names (if this was the chosen technique
> for 1.3.1) would have to be language independent.
>
> If the intent of this SC is to ensure that the purpose be identified
> universally and unambiguously in all languages via some mechanism
> other than accessible name, then it needs to be significantly edited
> to indicate this. As is stands now, I see no way in which an
> accessible name that conveys the purpose of the field would not be
> sufficient to meet the normative text. If I'm wrong, I'm going to need
> a much clearer explanation of how "programmatically determined" means
> something different here than for the rest of WCAG.
>
> Jared
> > > >

From: Jonathan Avila
Date: Wed, Jul 25 2018 10:38AM
Subject: Re: WCAG 2.1 - 1.3.5 - How to capture a violation?
← Previous message | Next message →

> I'm still really confused by what you are suggesting. Again, where does this success criterion state or suggest that accessible name (e.g., <label>, aria-label, etc.) cannot be used to convey the purpose?

From what I understand the goal of the criterion was to ensure that there was a machine readable way to know exactly what the purpose of the field was and therefore allow a user agent, assistive technology, or other tool provide an icon, or other identifier to help users with cognitive and learning disabilities know what content to put in the field. The actual autocompleting of the form field is a side benefit but was not the original intent of the criterion. The name of a field and the purpose can and often will be different for various reasons.

I'd suggest that you log an issue on the github repository for WCAG with what you think would help clarify this in the understanding documents of WCAG 2.1

Best Regards,

Jonathan

Jonathan Avila
Chief Accessibility Officer
Level Access
= EMAIL ADDRESS REMOVED =
703.637.8957 office

Visit us online:
Website | Twitter | Facebook | LinkedIn | Blog

Looking to boost your accessibility knowledge? Check out our free webinars!

The information contained in this transmission may be attorney privileged and/or confidential information intended for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this communication is strictly prohibited.

From: Jared Smith
Date: Wed, Jul 25 2018 11:15AM
Subject: Re: WCAG 2.1 - 1.3.5 - How to capture a violation?
← Previous message | Next message →

Patrick wrote:

> This has been the crux of the problem around 1.3.5. It really means "machine-readable", i.e. it needs to be part of a defined taxinomy that tools can use to determine the purpose of a control (and potentially offer useful behaviour, such as autofilling form fields).

Jon wrote:

> From what I understand the goal of the criterion was to ensure that there was a machine readable way to know exactly what the purpose of the field was

I cannot glean a semblance of this interpretation from the normative
text. The SC simply does not indicate that the field must align with a
defined or machine-readable taxonomy. It instead states that WHEN the
field aligns with the defined taxonomy (the autofill names) that the
purpose be programmatically determinable. There's a big difference
between what you are stating the goal of the SC is and what it
actually says.

As an example, <label>Name: <input type="text"></label> clearly aligns
with an autofill value - it collects the user's name. The SC therefore
requires that its purpose be programmatically determinable - which it
clearly is because of the associated label of "Name". (Interestingly,
this would also work in any useful form filler, but that's rather
beside the point.)

If this code is not sufficient, then can you provide an explanation as
to how it fails to meet the normative text of 1.3.5? It's quite
possible I'm misunderstanding something here.

> I'd suggest that you log an issue on the github repository for WCAG with what you think would help clarify this in the understanding documents of WCAG 2.1

There's not anything wrong with the existing technique. It's certainly
one way to meet the success criterion. But if the intent of the
success criterion is that conveying the purpose via an accessible name
is not sufficient and/or that the purpose must be conveyed via a
defined taxonomy, then I don't think this can be addressed without
modifying the success criterion itself to indicate this.

Thanks,

Jared

From: John Foliot
Date: Wed, Jul 25 2018 11:28AM
Subject: Re: WCAG 2.1 - 1.3.5 - How to capture a violation?
← Previous message | Next message →

As one of the "shepherds" of this SC in the WCAG WG, I will confirm that
both Patrick and Jon are correct. The nuanced difference is the use of a
fixed taxonomy added to the input, versus ensuring it has an accessible
name. The "gain" here is actually more visible in non-english content,
where the accessible name would be localized for the language of the page.

<label for="ThisInput">Почтовый индекс</label> <input type="text"
id="ThisInput" autocomplete="postal-code">


No matter what the language of the label text is, the "machine-readable"
bit is clearly "postal-code", which is unambiguously defined here:
https://www.w3.org/TR/WCAG21/#input-purposes

...and specifically: *"postal-code - Postal code, post code, ZIP code,
CEDEX code (if CEDEX, append "CEDEX", and the dissement, if relevant, to
the address-level2 field)"*

Currently, the "taxonomy list" being used is in fact that normative list of
values and definitions that *is* the autocomplete values, and as others
have noted, currently the 'best' technique is to use @autocomplete to
attach the meta-data term to the input field. Going forward, there are
other activities at the W3C (not yet mature enough for production) related
to "Personalization" that hopes/intends to leverage this initial taxonomy,
and provide additional mechanisms and methods for attaching the values to
the inputs.

HTH

JF

On Wed, Jul 25, 2018 at 11:38 AM, Jonathan Avila < = EMAIL ADDRESS REMOVED = >
wrote:

> > I'm still really confused by what you are suggesting. Again, where does
> this success criterion state or suggest that accessible name (e.g.,
> <label>, aria-label, etc.) cannot be used to convey the purpose?
>
> From what I understand the goal of the criterion was to ensure that there
> was a machine readable way to know exactly what the purpose of the field
> was and therefore allow a user agent, assistive technology, or other tool
> provide an icon, or other identifier to help users with cognitive and
> learning disabilities know what content to put in the field. The actual
> autocompleting of the form field is a side benefit but was not the original
> intent of the criterion. The name of a field and the purpose can and often
> will be different for various reasons.
>
> I'd suggest that you log an issue on the github repository for WCAG with
> what you think would help clarify this in the understanding documents of
> WCAG 2.1
>
> Best Regards,
>
> Jonathan
>
> Jonathan Avila
> Chief Accessibility Officer
> Level Access
> = EMAIL ADDRESS REMOVED =
> 703.637.8957 office
>
> Visit us online:
> Website | Twitter | Facebook | LinkedIn | Blog
>
> Looking to boost your accessibility knowledge? Check out our free webinars!
>
> The information contained in this transmission may be attorney privileged
> and/or confidential information intended for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any use, dissemination,
> distribution or copying of this communication is strictly prohibited.
>
>

From: Jared Smith
Date: Wed, Jul 25 2018 12:17PM
Subject: Re: WCAG 2.1 - 1.3.5 - How to capture a violation?
← Previous message | Next message →

John Foliot wrote:

> The "gain" here is actually more visible in non-english content,
> where the accessible name would be localized for the language of the page.
>
> <label for="ThisInput">Почтовый индекс</label> <input type="text"
> id="ThisInput" autocomplete="postal-code">
>
>
> No matter what the language of the label text is, the "machine-readable"
> bit is clearly "postal-code", which is unambiguously defined here:
> https://www.w3.org/TR/WCAG21/#input-purposes

Yes, using autocomplete is a fantastic idea here, but the SC simply
does NOT require alignment with a "machine-readable" taxonomy or that
an unambiguous definition be provided. It only requires that "the
purpose... can be programmatically determined" (I'm quoting the SC
directly here).

In your example, the purpose of the field is clearly available and
associated to the field via the label. So why would the autocomplete
attribute be required in addition to this? Nothing in the SC suggests
that anything more than associating the purpose is necessary. If the
label is somehow not "determinable" here because it happens to be in
Russian, then how could the exact same label be "determinable" to meet
1.3.1 and 3.3.2?

> Currently, the "taxonomy list" being used is in fact that normative list of
> values and definitions that *is* the autocomplete values, and as others
> have noted, currently the 'best' technique is to use @autocomplete to
> attach the meta-data term to the input field.

Right. This is the certainly the "best" technique. But is an
accessible name NOT an acceptable technique?

If it's not, the only other way I can contort my mind to get to this
interpretation from the SC text is to change the meaning of "purpose"
to mean "purpose as defined by a machine-readable,
language-independent taxonomy" (which would be very different than
"purpose" as used in 1.1.1, 2.4.2, and 2.4.9) or to interpret
"programmatically determined" very differently here than anywhere else
in WCAG. I don't think I could be supportive of either of these
contortions.

Jared

From: John Foliot
Date: Wed, Jul 25 2018 12:56PM
Subject: Re: WCAG 2.1 - 1.3.5 - How to capture a violation?
← Previous message | Next message →

Respectfully Jared,

I disagree with your reading and understanding. The SC states:

*"The purpose of each input field collecting information about the user can
be programmatically determined when:..."*


...where programmatically determined has been Normatively defined as:

*programmatically determined (programmatically determinable)*


*determined by software* from author-supplied data provided *in a way that
different user agents*, including assistive technologies, *can extract and
present this information to users in different modalities*

For example, Jon has shared his favelet/bookmarklet, which exposes the
values on screen (as opposed to "filling in the form"), and I have
(awaiting packaging) a Chrome extension that takes the @autocomplete values
and injects icons to supplement text labels​ associated to the various
inputs. Both of these functions work because no matter what you as an
author has supplied as the text label (Accessible Name), the machine
readable token remains constant for the software to determine.

For user agents to be able to determine what the input is seeking, it needs
to be working from a fixed list. If I label an input *Số thẻ tín dụng *for
example, how will software understand that? But if I also programmatically
link the accessible name (*Số thẻ tín dụng*) to a machine-understandable
value (cc-number), *THEN* machines can start to figure it out as well and
"....
extract and present this information to users in different modalities
​" (such as the two examples I mentioned).*​*

​​
Again, the main beneficiary of this SC is actually machines (Perceivable -
1.x.x SC), as opposed to end-users (Understandable 3.x.x SC), which is why
the
​A
ccessible
​N
ame alone is insufficient.

I agree this is less than clear or obvious in the Understanding
documentation today, and I have taken this as an action item at the W3C to
revisit the Understanding document to ensure that it reflects the real
intention of this SC beyond a dry reading of the SC text that seems to be
forming your (and other's) interpretation.

JF

On Wed, Jul 25, 2018 at 1:17 PM, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:

> John Foliot wrote:
>
> > The "gain" here is actually more visible in non-english content,
> > where the accessible name would be localized for the language of the
> page.
> >
> > <label for="ThisInput">Почтовый индекс</label> <input type="text"
> > id="ThisInput" autocomplete="postal-code">
> >
> >
> > No matter what the language of the label text is, the "machine-readable"
> > bit is clearly "postal-code", which is unambiguously defined here:
> > https://www.w3.org/TR/WCAG21/#input-purposes
>
> Yes, using autocomplete is a fantastic idea here, but the SC simply
> does NOT require alignment with a "machine-readable" taxonomy or that
> an unambiguous definition be provided. It only requires that "the
> purpose... can be programmatically determined" (I'm quoting the SC
> directly here).
>
> In your example, the purpose of the field is clearly available and
> associated to the field via the label. So why would the autocomplete
> attribute be required in addition to this? Nothing in the SC suggests
> that anything more than associating the purpose is necessary. If the
> label is somehow not "determinable" here because it happens to be in
> Russian, then how could the exact same label be "determinable" to meet
> 1.3.1 and 3.3.2?
>
> > Currently, the "taxonomy list" being used is in fact that normative list
> of
> > values and definitions that *is* the autocomplete values, and as others
> > have noted, currently the 'best' technique is to use @autocomplete to
> > attach the meta-data term to the input field.
>
> Right. This is the certainly the "best" technique. But is an
> accessible name NOT an acceptable technique?
>
> If it's not, the only other way I can contort my mind to get to this
> interpretation from the SC text is to change the meaning of "purpose"
> to mean "purpose as defined by a machine-readable,
> language-independent taxonomy" (which would be very different than
> "purpose" as used in 1.1.1, 2.4.2, and 2.4.9) or to interpret
> "programmatically determined" very differently here than anywhere else
> in WCAG. I don't think I could be supportive of either of these
> contortions.
>
> Jared
> > > > >



--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
= EMAIL ADDRESS REMOVED =

Advancing the mission of digital accessibility and inclusion

From: Jonathan Cohn
Date: Wed, Jul 25 2018 1:48PM
Subject: Re: WCAG 2.1 - 1.3.5 - How to capture a violation?
← Previous message | Next message →

Interesting, so i believe you are suggesting that using the codes associated with auto-complete attributes gives a language / region independent way of indicating what a specific fields purpose is, and that this could be used to help with designing a personalization accessibility issue.

For individuals working a help desk / call center / data entry fields I would think using auto-complete attribute would attempt to find information from a local directory to fill in the field with auto complete information. But for these applications where 90% of the time one is entering information that will only ever be used for that session I would expect auto-complete would cause more issues than it resolves. Is there currently another attribute being suggested or provided that would resolve these conflicts?

Best Wishes,

Jonathan Cohn

> On Jul 25, 2018, at 1:28 PM, John Foliot < = EMAIL ADDRESS REMOVED = > wrote:
>
> As one of the "shepherds" of this SC in the WCAG WG, I will confirm that
> both Patrick and Jon are correct. The nuanced difference is the use of a
> fixed taxonomy added to the input, versus ensuring it has an accessible
> name. The "gain" here is actually more visible in non-english content,
> where the accessible name would be localized for the language of the page.
>
> <label for="ThisInput">Почтовый индекс</label> <input type="text"
> id="ThisInput" autocomplete="postal-code">
>
>
> No matter what the language of the label text is, the "machine-readable"
> bit is clearly "postal-code", which is unambiguously defined here:
> https://www.w3.org/TR/WCAG21/#input-purposes
>
> ...and specifically: *"postal-code - Postal code, post code, ZIP code,
> CEDEX code (if CEDEX, append "CEDEX", and the dissement, if relevant, to
> the address-level2 field)"*
>
> Currently, the "taxonomy list" being used is in fact that normative list of
> values and definitions that *is* the autocomplete values, and as others
> have noted, currently the 'best' technique is to use @autocomplete to
> attach the meta-data term to the input field. Going forward, there are
> other activities at the W3C (not yet mature enough for production) related
> to "Personalization" that hopes/intends to leverage this initial taxonomy,
> and provide additional mechanisms and methods for attaching the values to
> the inputs.
>
> HTH
>
> JF
>
> On Wed, Jul 25, 2018 at 11:38 AM, Jonathan Avila < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>>> I'm still really confused by what you are suggesting. Again, where does
>> this success criterion state or suggest that accessible name (e.g.,
>> <label>, aria-label, etc.) cannot be used to convey the purpose?
>>
>> From what I understand the goal of the criterion was to ensure that there
>> was a machine readable way to know exactly what the purpose of the field
>> was and therefore allow a user agent, assistive technology, or other tool
>> provide an icon, or other identifier to help users with cognitive and
>> learning disabilities know what content to put in the field. The actual
>> autocompleting of the form field is a side benefit but was not the original
>> intent of the criterion. The name of a field and the purpose can and often
>> will be different for various reasons.
>>
>> I'd suggest that you log an issue on the github repository for WCAG with
>> what you think would help clarify this in the understanding documents of
>> WCAG 2.1
>>
>> Best Regards,
>>
>> Jonathan
>>
>> Jonathan Avila
>> Chief Accessibility Officer
>> Level Access
>> = EMAIL ADDRESS REMOVED =
>> 703.637.8957 office
>>
>> Visit us online:
>> Website | Twitter | Facebook | LinkedIn | Blog
>>
>> Looking to boost your accessibility knowledge? Check out our free webinars!
>>
>> The information contained in this transmission may be attorney privileged
>> and/or confidential information intended for the use of the individual or
>> entity named above. If the reader of this message is not the intended
>> recipient, you are hereby notified that any use, dissemination,
>> distribution or copying of this communication is strictly prohibited.
>>
>>

From: Jared Smith
Date: Wed, Jul 25 2018 2:17PM
Subject: Re: WCAG 2.1 - 1.3.5 - How to capture a violation?
← Previous message | Next message →

John Foliot wrote:

> *determined by software* from author-supplied data provided *in a way that
> different user agents*, including assistive technologies, *can extract and
> present this information to users in different modalities*

I think this is a key in our differing interpretations. This
definition doesn't state that the software has to make sense of the
information, only that it must "extract and present" it to the user in
a meaningful way.

> Both of these functions work because no matter what you as an
> author has supplied as the text label (Accessible Name), the machine
> readable token remains constant for the software to determine.

But the software doesn't need to determine what the fields are for -
the user does! How the software gets the information and presents it
to the user shouldn't matter - it's that the information is presented
to and is "perceivable" and "understandable" by the user that results
in actual accessibility.

> If I label an input *Số thẻ tín dụng *for
> example, how will software understand that?

It doesn't have to. If the user knows what "Số thẻ tín dụng" is, then
it's fully accessible to that user.

If the actual intent of this is to require authors to support
universal machine understandability of input purpose regardless of
language or context, then the SC falls well short of making this
remotely apparent. And if this is done by defining "programmatically
determined" to mean that a computer must always make sense of it, then
authors must also be limited to pre-defined label texts, row headers,
page titles, which must also be "programmatically determined", no?
This logic doesn't fly.

> But if I also programmatically
> link the accessible name (*Số thẻ tín dụng*) to a machine-understandable
> value (cc-number), *THEN* machines can start to figure it out as well and
> "....
> extract and present this information to users in different modalities
> " (such as the two examples I mentioned).**

Yep, absolutely - they can "figure it out *as well*", but the success
criterion does not require that authors support this additional
machine understanding *in addition to* providing a programmatic label
that presents the purpose of the field.

> I agree this is less than clear or obvious in the Understanding
> documentation today

My bigger concern is that if I, as someone that has contributed
significantly to WCAG and has read and written 1000s of pages of
documentation on it, has no idea what this success criterion
presumably requires (assuming this interpretation is the correct one),
then I would have no reasonable expectation that anyone else would
either. I'm rather uncomfortable with non-normative documentation
significantly altering and expanding the meaning of normative success
criteria. My recommendation would be to support the success criterion
text itself, as is, and look to address this broader desire and intent
in a future version.

Jared

From: Jonathan Avila
Date: Wed, Jul 25 2018 6:45PM
Subject: Re: WCAG 2.1 - 1.3.5 - How to capture a violation?
← Previous message | Next message →

> For individuals working a help desk / call center / data entry fields I would think using auto-complete attribute would attempt to find information from a local directory to fill in the field with auto complete information

Fields in a help desk or accounting app that allowed people to enter information about other users would not fall into this SC as this SC was specifically scoped to the fields which take input about the current user and not information about other users for this very reason. Browsers also have settings that can assist with control of autocomplete information.

Jonathan

Jonathan Avila
Chief Accessibility Officer
Level Access
= EMAIL ADDRESS REMOVED =
703.637.8957 office

Visit us online:
Website | Twitter | Facebook | LinkedIn | Blog

Looking to boost your accessibility knowledge? Check out our free webinars!

The information contained in this transmission may be attorney privileged and/or confidential information intended for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this communication is strictly prohibited.

From: John Foliot
Date: Wed, Jul 25 2018 11:26PM
Subject: Re: WCAG 2.1 - 1.3.5 - How to capture a violation?
← Previous message | Next message →

Hi Jared,

A tricky but important discussion. Comments in line:

> > *determined by software* from author-supplied data provided *in a way
that
> > different user agents*, including assistive technologies, *can extract
and
> > present this information to users in different modalities*
>
> I think this is a key in our differing interpretations. This
> definition doesn't state that the software has to make sense of the
> information, only that it must "extract and present" it to the user in
> a meaningful way.

No, not "...in a meaningful way", but rather "...in different modalities".
I believe there is a distinction here that is underscoring our differing
interpretations.

>
> > Both of these functions work because no matter what you as an
> > author has supplied as the text label (Accessible Name), the machine
> > readable token remains constant for the software to determine.
>
> But the software doesn't need to determine what the fields are for -
> the user does! How the software gets the information and presents it
> to the user shouldn't matter - it's that the information is presented
> to and is "perceivable" and "understandable" by the user that results
> in actual accessibility.

You are correct, the software doesn't need to know the "what" of the input
(which is covered by the accessible name generated by the label), but it
*DOES* need to know how to present it in "different modalities". Given that
the accessible name is going to be effectively always a random string
(either because it is in English, or a non-English language) or because the
"label" could have variants in expression (nickname, nic, handle, tag all
would currently map to the @autocomplete value of 'nickname'), the
accessible name does not provide what is required to meet this SC, because
the values of accessible name will always be random author supplied values.

To be able to express the concept of the input, to present it in "different
modalities" (including non-text alternatives such as icons), you need a
standardized look-up table - aka a taxonomy. The explicitly defined values
that are the token values of @autocomplete meet that need today.

Importantly for WCAG 2.1, we've also published those values and definitions
verbatim in WCAG 2.1 as well, to ensure that those definitions don't change
from out under our feet (due to potential changes to future versions of
HTML), and because the WG anticipates other mechanisms to emerge (during
the Personalization work) to attach those values to the inputs: the desire
being that one day we'll have multiple mechanisms (in a similar way that we
can provide the accessible name of an image using either @alt, @aria-label,
or @aria-labelledby today).

>
> > If I label an input *Số thẻ tín dụng *for
> > example, how will software understand that?
>
> It doesn't have to. If the user knows what "Số thẻ tín dụng" is, then
> it's fully accessible to that user.

I disagree. The majority of use-cases that drove the development of this
Success Criteria were informed by the documented needs of users with
cognitive disabilities. For many of those users who have issues with
processing text, they would traditionally require symbols and iconography
to effectively communicate. Question, how would software know how to
express "Số thẻ tín dụng" or "رقم بطاقة الائتمان" as a symbol?

The intention of this Success Criteria is not "the name (label) for the
input is understood by the end user" (a form of access), but rather that
that purpose of the input can be expressed in "different modalities" (i.e.,
as a symbol). Subtle, yes, but quite different as well, due to the need for
a conversion look-up table - the taxonomy.

In other words, for the end user to be able to "Perceive" the reason (a
1.x.x numbered SC), the requirement is closer to "conversion" (aka the
ability to "*Identify* the Input Purpose" and express that in different
modalities) as opposed to "interpretation" (aka make it "Understandable", a
3.x.x numbered SC)

>
> If the actual
​​
intent of this is to require authors to support
> universal machine understandability of input purpose regardless of
> language or context, then the SC falls well short of making this
> remotely apparent.

That is a matter of interpretation. I'm sorry it is less than clear to you,
but the language was reviewed multiple times, along with documented
discussion that lead to the final language, and the Working Group felt that
this language does express the requirement clearly. I agree that currently
the Understanding document attached to this SC is less than clear, and that
needs to be addressed by the Working Group quickly. I've already confirmed
that I've taken ownership of that task.


> And if this is done by defining "programmatically
> determined" to mean that a computer must always make sense of it, then
> authors must also be limited to pre-defined label texts, row headers,
> page titles, which must also be "programmatically determined", no?

No, because the defined term of "programmatically determinable" does not
equal "understandable by the end user", but rather that information (or for
row headers and page titles the "semantics" of those elements) can be
(consistently) identified, so that it can be expressed in different
modalities. Looking at those existing 2.0 SC that use this defined term:

Success Criterion 1.3.1 Info and Relationships
​
(Level A)
Information, structure, and relationships conveyed through presentation can
be *programmatically determined* or are available in text.


To achieve success in any permutation of interpreting this SC (given it
remains the "kitchen sink" of SC) always tracks back to shared common
understanding. The defined semantics of HTML is one such form of shared
understanding
​, and those semantics, for the intent of this SC, are supplied via the
semantics of those HTML elements​
. As an end user, you may not ever be able to understand what <h1>இது ஒரு
தலைப்பு</h1> means, but programmatically, machines will always we able to
unequivocally determine that the content is in fact a heading at level 1.
That's why <div id="first level heading"> fails this SC, because what I
expressed in readable (and for this mailing list audience "understandable")
junk code cannot be "programmatically determined" by machines.

Machines will always be able to determine the difference between a <th> and
a <td>, even if through styling or scripting there may never be a visual
difference on screen for sighted users
​.​
BUT, through alternate or user style sheets that difference *could* be
expressed in a different modality, i.e. apply a different style
​,​
​ because the difference of those two types of table cells can be
determined programmatically, and so modification can be achieved - i.e.,
present the information in a different modality visually, and AT such as
screen readers are programmed to convey the difference to those users.​



Success Criterion 1.3.2 Meaningful Sequence
​
(Level A)
When the sequence in which content is presented affects its meaning, a
correct reading sequence can be *programmatically determined*.


This one is slightly trickier, but the same argument remains applicable.

Reading order can be programmatically determined using a number of
different mechanisms. One example: by identifying the native language of
the document as Hebrew, applications that need to output the text in an
ordered reading sequence in an audio form is already programmed to ensure
R-L reading of the text. For the programmatic determination however you
must always trace back to a fixed list (lang="he" or "heb" and not
lang="Hebrew" - i.e., by using fixed values defined by ISO 639 (
https://iso639-3.sil.org/code_tables/639/data/h) - another "look-up table"
​ taht can be referenced by machines​
)

Then there is a default tabbing order, which is also inherent to reading
order; but one that can be modified by using tabindex. HOWEVER, the values
that you can use for tabindex is restricted to (a fixed list of) numeric
values: 0, positive integers, or -1. Using tabindex="two" does not meet the
requirement, in the same way that tabindex="deux" does not (equal values,
but in different languages) because software
​ today​
is not equipped for heuristic capabilities to translate the wrong value
(deux) to the correct value (2). Perhaps in the future AI will be able to
achieve this, but today that option does not exist (at least not at scale -
IBM Watson "might" have this capacity today, not sure...)


Success Criterion 3.1.1 Language of Page
​
(Level A)
The default human language of each Web page can be *programmatically
determined*.

Success Criterion 3.1.2 Language of Parts
​
(Level AA)
The human language of each passage or phrase in the content can be
*programmatically
determined* except for proper names, technical terms, words of
indeterminate language, and words or phrases that have become part of the
vernacular of the immediately surrounding text.


As in the first Meaningful Sequence example above (determining reading
order in part by declaring the language) both of these SC are solely
dependent on a fixed taxonomy list that is the ISO 639 defined list. No
other values will achieve success. While this most often impacts screen
readers, for those software tools to be able to do "on the fly" language
switching (SC 3.1.2), those values must be encoded using the ISO codes to
be output in a different modality (in this case, a different language
profile)
​. Once again, success is achieved because machines have a stable
references to make the changes in modality, and user success derived by
these SC is directly dependent on those outcomes.


Success Criterion 4.1.2 Name, Role, Value
​
(Level A)
For all user interface components (including but not limited to: form
elements, links and components generated by scripts), the name and role can
be *programmatically determined*; states, properties, and values that can
be set by the user can be programmatically set; and notification of changes
to these items is available to user agents, including assistive
technologies.


This SC only requires that "name" and "role" be programmatically
determined.

For 'name' the value string can be localized, but the mechanism by which
you associate a name
​ (making it programmatically determinable)​
to an element or component is limited to a fixed number of ways, using the
​ machine-understandable​
semantics of HTML (see SC 1.3.1).

For the 'role' to be programmatically identified, it has to take one of the
fixed list of defined values that are valid for that attribute: authors
can't make up new values, because software wouldn't know what to do with
those values, so the intent of the author cannot be 'determined'. The
lookup table
​ for @role​
is defined in ARIA as
​w
idget roles (https://www.w3.org/WAI/PF/aria/roles#widget_roles), document
structure (https://www.w3.org/WAI/PF/aria/roles#document_structure_roles)
​,​
or landmark roles (https://www.w3.org/WAI/PF/aria/roles#landmark_roles). No
machine on earth (that I know of) would be able to programmatically
determine and express in a different modality
​ the following:​
*role="WebAIM_Widget"*.

As such, I assert your interpretation of the definition of
"programmatically determinable" is incorrect, leading to your
misunderstanding of this SC.

For every instance of the use of the term "programmatically determinable"
in WCAG 2.0 and 2.1, achieving success is dependent on
​ machine understanding of​
a taxonomy of sorts, whether a fixed list of roles defined in ARIA, the
fixed input values defined as part of @autocomplete, or the limited and
defined semantics that is HTML (as non-semantic elements such as <div> or
<span> lack any native semantics and thus fail to meet SC 1.3.1 without
further ARIA semantics being attached). And while in many ways
"programmatically determinable" *could* be a synonym of Understanding, this
term as used in WCAG today means the understanding is not by the end user,
but rather by machines, so that machines can express the concept "in
different modalities".


> This logic doesn't fly.

Respectfully disagree.
​ Based on the normative definition of "programmatically determinable"​
(which I've attempted to defend above) and the WG's understanding of that
definition, the
​
intent of this
​ SC​
is
​ indeed​
to require authors to support universal machine understandability of input
purpose
​​ (so that it can be *expressed in different modalities* - the key phrase
in this discussion and the definition of that term).


JF



On Wed, Jul 25, 2018 at 3:17 PM, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
>
> John Foliot wrote:
>
> > *determined by software* from author-supplied data provided *in a way
that
> > different user agents*, including assistive technologies, *can extract
and
> > present this information to users in different modalities*
>
> I think this is a key in our differing interpretations. This
> definition doesn't state that the software has to make sense of the
> information, only that it must "extract and present" it to the user in
> a meaningful way.
>
> > Both of these functions work because no matter what you as an
> > author has supplied as the text label (Accessible Name), the machine
> > readable token remains constant for the software to determine.
>
> But the software doesn't need to determine what the fields are for -
> the user does! How the software gets the information and presents it
> to the user shouldn't matter - it's that the information is presented
> to and is "perceivable" and "understandable" by the user that results
> in actual accessibility.
>
> > If I label an input *Số thẻ tín dụng *for
> > example, how will software understand that?
>
> It doesn't have to. If the user knows what "Số thẻ tín dụng" is, then
> it's fully accessible to that user.
>
> If the actual intent of this is to require authors to support
> universal machine understandability of input purpose regardless of
> language or context, then the SC falls well short of making this
> remotely apparent. And if this is done by defining "programmatically
> determined" to mean that a computer must always make sense of it, then
> authors must also be limited to pre-defined label texts, row headers,
> page titles, which must also be "programmatically determined", no?
> This logic doesn't fly.
>
> > But if I also programmatically
> > link the accessible name (*Số thẻ tín dụng*) to a machine-understandable
> > value (cc-number), *THEN* machines can start to figure it out as well
and
> > "....
> > extract and present this information to users in different modalities
> > " (such as the two examples I mentioned).**
>
> Yep, absolutely - they can "figure it out *as well*", but the success
> criterion does not require that authors support this additional
> machine understanding *in addition to* providing a programmatic label
> that presents the purpose of the field.
>
> > I agree this is less than clear or obvious in the Understanding
> > documentation today
>
> My bigger concern is that if I, as someone that has contributed
> significantly to WCAG and has read and written 1000s of pages of
> documentation on it, has no idea what this success criterion
> presumably requires (assuming this interpretation is the correct one),
> then I would have no reasonable expectation that anyone else would
> either. I'm rather uncomfortable with non-normative documentation
> significantly altering and expanding the meaning of normative success
> criteria. My recommendation would be to support the success criterion
> text itself, as is, and look to address this broader desire and intent
> in a future version.
>
> Jared
> > > > --
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
= EMAIL ADDRESS REMOVED =

Advancing the mission of digital accessibility and inclusion

From: John Foliot
Date: Wed, Jul 25 2018 11:44PM
Subject: Re: WCAG 2.1 - 1.3.5 - How to capture a violation?
← Previous message | Next message →

..and to close the circle, when machines can express the intent of the
input in different modalities, it ultimately *DOES* make it more
understandable by the end user, but again this is a Perceivable SC, and not
an Understandable SC, so the perceivability is the more important goal of
this SC.

JF

On Thu, Jul 26, 2018 at 12:26 AM, John Foliot < = EMAIL ADDRESS REMOVED = > wrote:

> Hi Jared,
>
> A tricky but important discussion. Comments in line:
>
> > > *determined by software* from author-supplied data provided *in a way
> that
> > > different user agents*, including assistive technologies, *can
> extract and
> > > present this information to users in different modalities*
> >
> > I think this is a key in our differing interpretations. This
> > definition doesn't state that the software has to make sense of the
> > information, only that it must "extract and present" it to the user in
> > a meaningful way.
>
> No, not "...in a meaningful way", but rather "...in different modalities".
> I believe there is a distinction here that is underscoring our differing
> interpretations.
>
> >
> > > Both of these functions work because no matter what you as an
> > > author has supplied as the text label (Accessible Name), the machine
> > > readable token remains constant for the software to determine.
> >
> > But the software doesn't need to determine what the fields are for -
> > the user does! How the software gets the information and presents it
> > to the user shouldn't matter - it's that the information is presented
> > to and is "perceivable" and "understandable" by the user that results
> > in actual accessibility.
>
> You are correct, the software doesn't need to know the "what" of the input
> (which is covered by the accessible name generated by the label), but it
> *DOES* need to know how to present it in "different modalities". Given that
> the accessible name is going to be effectively always a random string
> (either because it is in English, or a non-English language) or because the
> "label" could have variants in expression (nickname, nic, handle, tag all
> would currently map to the @autocomplete value of 'nickname'), the
> accessible name does not provide what is required to meet this SC, because
> the values of accessible name will always be random author supplied values.
>
> To be able to express the concept of the input, to present it in
> "different modalities" (including non-text alternatives such as icons), you
> need a standardized look-up table - aka a taxonomy. The explicitly defined
> values that are the token values of @autocomplete meet that need today.
>
> Importantly for WCAG 2.1, we've also published those values and
> definitions verbatim in WCAG 2.1 as well, to ensure that those definitions
> don't change from out under our feet (due to potential changes to future
> versions of HTML), and because the WG anticipates other mechanisms to
> emerge (during the Personalization work) to attach those values to the
> inputs: the desire being that one day we'll have multiple mechanisms (in a
> similar way that we can provide the accessible name of an image using
> either @alt, @aria-label, or @aria-labelledby today).
>
> >
> > > If I label an input *Số thẻ tín dụng *for
> > > example, how will software understand that?
> >
> > It doesn't have to. If the user knows what "Số thẻ tín dụng" is, then
> > it's fully accessible to that user.
>
> I disagree. The majority of use-cases that drove the development of this
> Success Criteria were informed by the documented needs of users with
> cognitive disabilities. For many of those users who have issues with
> processing text, they would traditionally require symbols and iconography
> to effectively communicate. Question, how would software know how to
> express "Số thẻ tín dụng" or "رقم بطاقة الائتمان" as a symbol?
>
> The intention of this Success Criteria is not "the name (label) for the
> input is understood by the end user" (a form of access), but rather that
> that purpose of the input can be expressed in "different modalities" (i.e.,
> as a symbol). Subtle, yes, but quite different as well, due to the need for
> a conversion look-up table - the taxonomy.
>
> In other words, for the end user to be able to "Perceive" the reason (a
> 1.x.x numbered SC), the requirement is closer to "conversion" (aka the
> ability to "*Identify* the Input Purpose" and express that in different
> modalities) as opposed to "interpretation" (aka make it "Understandable", a
> 3.x.x numbered SC)
>
> >
> > If the actual
> ​​
> intent of this is to require authors to support
> > universal machine understandability of input purpose regardless of
> > language or context, then the SC falls well short of making this
> > remotely apparent.
>
> That is a matter of interpretation. I'm sorry it is less than clear to
> you, but the language was reviewed multiple times, along with documented
> discussion that lead to the final language, and the Working Group felt that
> this language does express the requirement clearly. I agree that currently
> the Understanding document attached to this SC is less than clear, and that
> needs to be addressed by the Working Group quickly. I've already confirmed
> that I've taken ownership of that task.
>
>
> > And if this is done by defining "programmatically
> > determined" to mean that a computer must always make sense of it, then
> > authors must also be limited to pre-defined label texts, row headers,
> > page titles, which must also be "programmatically determined", no?
>
> No, because the defined term of "programmatically determinable" does not
> equal "understandable by the end user", but rather that information (or for
> row headers and page titles the "semantics" of those elements) can be
> (consistently) identified, so that it can be expressed in different
> modalities. Looking at those existing 2.0 SC that use this defined term:
>
> Success Criterion 1.3.1 Info and Relationships
> ​
> (Level A)
> Information, structure, and relationships conveyed through presentation
> can be *programmatically determined* or are available in text.
>
>
> To achieve success in any permutation of interpreting this SC (given it
> remains the "kitchen sink" of SC) always tracks back to shared common
> understanding. The defined semantics of HTML is one such form of shared
> understanding
> ​, and those semantics, for the intent of this SC, are supplied via the
> semantics of those HTML elements​
> . As an end user, you may not ever be able to understand what <h1>இது ஒரு
> தலைப்பு</h1> means, but programmatically, machines will always we able to
> unequivocally determine that the content is in fact a heading at level 1.
> That's why <div id="first level heading"> fails this SC, because what I
> expressed in readable (and for this mailing list audience "understandable")
> junk code cannot be "programmatically determined" by machines.
>
> Machines will always be able to determine the difference between a <th>
> and a <td>, even if through styling or scripting there may never be a
> visual difference on screen for sighted users
> ​.​
> BUT, through alternate or user style sheets that difference *could* be
> expressed in a different modality, i.e. apply a different style
> ​,​
> ​ because the difference of those two types of table cells can be
> determined programmatically, and so modification can be achieved - i.e.,
> present the information in a different modality visually, and AT such as
> screen readers are programmed to convey the difference to those users.​
>
>
>
> Success Criterion 1.3.2 Meaningful Sequence
> ​
> (Level A)
> When the sequence in which content is presented affects its meaning, a
> correct reading sequence can be *programmatically determined*.
>
>
> This one is slightly trickier, but the same argument remains applicable.
>
> Reading order can be programmatically determined using a number of
> different mechanisms. One example: by identifying the native language of
> the document as Hebrew, applications that need to output the text in an
> ordered reading sequence in an audio form is already programmed to ensure
> R-L reading of the text. For the programmatic determination however you
> must always trace back to a fixed list (lang="he" or "heb" and not
> lang="Hebrew" - i.e., by using fixed values defined by ISO 639 (
> https://iso639-3.sil.org/code_tables/639/data/h) - another "look-up table"
> ​ taht can be referenced by machines​
> )
>
> Then there is a default tabbing order, which is also inherent to reading
> order; but one that can be modified by using tabindex. HOWEVER, the values
> that you can use for tabindex is restricted to (a fixed list of) numeric
> values: 0, positive integers, or -1. Using tabindex="two" does not meet the
> requirement, in the same way that tabindex="deux" does not (equal values,
> but in different languages) because software
> ​ today​
> is not equipped for heuristic capabilities to translate the wrong value
> (deux) to the correct value (2). Perhaps in the future AI will be able to
> achieve this, but today that option does not exist (at least not at scale -
> IBM Watson "might" have this capacity today, not sure...)
>
>
> Success Criterion 3.1.1 Language of Page
> ​
> (Level A)
> The default human language of each Web page can be *programmatically
> determined*.
>
> Success Criterion 3.1.2 Language of Parts
> ​
> (Level AA)
> The human language of each passage or phrase in the content can be *programmatically
> determined* except for proper names, technical terms, words of
> indeterminate language, and words or phrases that have become part of the
> vernacular of the immediately surrounding text.
>
>
> As in the first Meaningful Sequence example above (determining reading
> order in part by declaring the language) both of these SC are solely
> dependent on a fixed taxonomy list that is the ISO 639 defined list. No
> other values will achieve success. While this most often impacts screen
> readers, for those software tools to be able to do "on the fly" language
> switching (SC 3.1.2), those values must be encoded using the ISO codes to
> be output in a different modality (in this case, a different language
> profile)
> ​. Once again, success is achieved because machines have a stable
> references to make the changes in modality, and user success derived by
> these SC is directly dependent on those outcomes.
>
>
> Success Criterion 4.1.2 Name, Role, Value
> ​
> (Level A)
> For all user interface components (including but not limited to: form
> elements, links and components generated by scripts), the name and role can
> be *programmatically determined*; states, properties, and values that can
> be set by the user can be programmatically set; and notification of changes
> to these items is available to user agents, including assistive
> technologies.
>
>
> This SC only requires that "name" and "role" be programmatically
> determined.
>
> For 'name' the value string can be localized, but the mechanism by which
> you associate a name
> ​ (making it programmatically determinable)​
> to an element or component is limited to a fixed number of ways, using the
> ​ machine-understandable​
> semantics of HTML (see SC 1.3.1).
>
> For the 'role' to be programmatically identified, it has to take one of
> the fixed list of defined values that are valid for that attribute: authors
> can't make up new values, because software wouldn't know what to do with
> those values, so the intent of the author cannot be 'determined'. The
> lookup table
> ​ for @role​
> is defined in ARIA as
> ​w
> idget roles (https://www.w3.org/WAI/PF/aria/roles#widget_roles), document
> structure (https://www.w3.org/WAI/PF/aria/roles#document_structure_roles)
> ​,​
> or landmark roles (https://www.w3.org/WAI/PF/aria/roles#landmark_roles).
> No machine on earth (that I know of) would be able to programmatically
> determine and express in a different modality
> ​ the following:​
> *role="WebAIM_Widget"*.
>
> As such, I assert your interpretation of the definition of
> "programmatically determinable" is incorrect, leading to your
> misunderstanding of this SC.
>
> For every instance of the use of the term "programmatically determinable"
> in WCAG 2.0 and 2.1, achieving success is dependent on
> ​ machine understanding of​
> a taxonomy of sorts, whether a fixed list of roles defined in ARIA, the
> fixed input values defined as part of @autocomplete, or the limited and
> defined semantics that is HTML (as non-semantic elements such as <div> or
> <span> lack any native semantics and thus fail to meet SC 1.3.1 without
> further ARIA semantics being attached). And while in many ways
> "programmatically determinable" *could* be a synonym of Understanding, this
> term as used in WCAG today means the understanding is not by the end user,
> but rather by machines, so that machines can express the concept "in
> different modalities".
>
>
> > This logic doesn't fly.
>
> Respectfully disagree.
> ​ Based on the normative definition of "programmatically determinable"​
> (which I've attempted to defend above) and the WG's understanding of that
> definition, the
> ​
> intent of this
> ​ SC​
> is
> ​ indeed​
> to require authors to support universal machine understandability of input
> purpose
> ​​ (so that it can be *expressed in different modalities* - the key
> phrase in this discussion and the definition of that term).
>
>
> JF
>
>
>
> On Wed, Jul 25, 2018 at 3:17 PM, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
> >
> > John Foliot wrote:
> >
> > > *determined by software* from author-supplied data provided *in a way
> that
> > > different user agents*, including assistive technologies, *can extract
> and
> > > present this information to users in different modalities*
> >
> > I think this is a key in our differing interpretations. This
> > definition doesn't state that the software has to make sense of the
> > information, only that it must "extract and present" it to the user in
> > a meaningful way.
> >
> > > Both of these functions work because no matter what you as an
> > > author has supplied as the text label (Accessible Name), the machine
> > > readable token remains constant for the software to determine.
> >
> > But the software doesn't need to determine what the fields are for -
> > the user does! How the software gets the information and presents it
> > to the user shouldn't matter - it's that the information is presented
> > to and is "perceivable" and "understandable" by the user that results
> > in actual accessibility.
> >
> > > If I label an input *Số thẻ tín dụng *for
> > > example, how will software understand that?
> >
> > It doesn't have to. If the user knows what "Số thẻ tín dụng" is, then
> > it's fully accessible to that user.
> >
> > If the actual intent of this is to require authors to support
> > universal machine understandability of input purpose regardless of
> > language or context, then the SC falls well short of making this
> > remotely apparent. And if this is done by defining "programmatically
> > determined" to mean that a computer must always make sense of it, then
> > authors must also be limited to pre-defined label texts, row headers,
> > page titles, which must also be "programmatically determined", no?
> > This logic doesn't fly.
> >
> > > But if I also programmatically
> > > link the accessible name (*Số thẻ tín dụng*) to a
> machine-understandable
> > > value (cc-number), *THEN* machines can start to figure it out as well
> and
> > > "....
> > > extract and present this information to users in different modalities
> > > " (such as the two examples I mentioned).**
> >
> > Yep, absolutely - they can "figure it out *as well*", but the success
> > criterion does not require that authors support this additional
> > machine understanding *in addition to* providing a programmatic label
> > that presents the purpose of the field.
> >
> > > I agree this is less than clear or obvious in the Understanding
> > > documentation today
> >
> > My bigger concern is that if I, as someone that has contributed
> > significantly to WCAG and has read and written 1000s of pages of
> > documentation on it, has no idea what this success criterion
> > presumably requires (assuming this interpretation is the correct one),
> > then I would have no reasonable expectation that anyone else would
> > either. I'm rather uncomfortable with non-normative documentation
> > significantly altering and expanding the meaning of normative success
> > criteria. My recommendation would be to support the success criterion
> > text itself, as is, and look to address this broader desire and intent
> > in a future version.
> >
> > Jared
> > > > > > > > >
>
>
>
> --
> John Foliot
> Principal Accessibility Strategist
> Deque Systems Inc.
> = EMAIL ADDRESS REMOVED =
>
> Advancing the mission of digital accessibility and inclusion
>



--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
= EMAIL ADDRESS REMOVED =

Advancing the mission of digital accessibility and inclusion

From: Jared Smith
Date: Thu, Jul 26 2018 9:10AM
Subject: Re: WCAG 2.1 - 1.3.5 - How to capture a violation?
← Previous message | Next message →

John -

Thanks for taking the time to provide such a detailed explanation.
This really is very helpful and informative.

I've always viewed programmatically determined as being adapted in a
way or "different modalities" that provides meaning and usefulness to
the user. But I can see based on your explanations that this
user-focused interpretation is too broad - it focuses instead only on
computer parsing.

I won't belabor the discussion about the semantics and nuances of the
language and terms any more, except to restate that I do not believe
that we can expect web authors to understand the requirements of this
success criterion from the normative text. It's rather difficult to
explain that an associated label is "programmatically determined" to
convey "information and relationships" for an input under 1.3.1, but
is not "programmatically determined" to convey "purpose" for an input
under 1.3.5.

(Quick related note - why is title attribute -
https://www.w3.org/TR/WCAG20-TECHS/H65.html - sufficient to meet
1.3.1? This doesn't seem to meet your definition for "programmatically
determined", right?)

But this language and the W3C's interpretation of it is not changing.
So it becomes incumbent upon us to try to explain it in ways that will
minimize confusion and potential liability for web authors. Which
brings me to a couple additional questions...

If a field maps to one of the defined "input purposes" and does not
have the proper autocomplete attribute, is it a failure? In other
words, is
<label>Name <input type="text"></label>
now a WCAG 2.1 failure?

I really need a clear answer to this question. You've stated several
times that autocomplete is not the only way to meet this SC. This was
a primary factor in my misunderstanding this SC - I thought if
@autocomplete isn't required, then certainly a descriptive label is
therefore sufficient, because how else would they pass? Now, based on
your explanations, I don't see how anything other than @autocomplete
could be sufficient to meet this SC today.

As a follow-up... what if the associated label uses language that is
common and standard for that input purpose (e.g., "Name" or "Credit
card"). I believe most (all?) common form fillers interpret these
common label values to provide the needed form-fill functionality
(otherwise they wouldn't work on forms that lack @autocomplete). Using
@autocomplete would thus provide no additional benefit or
functionality in this case. If the author deems these to be
"accessibility supported", would this be sufficient to meet 1.3.5?

Your arguments about other languages seems a stretch here. Why would
someone that only speaks Vietnamese need to know the purpose of an
input on an English page they can't understand? But if their
Vietnamese form filler knows that "Số thẻ tín dụng" is for credit card
number on a Vietnamese page, then @autocomplete doesn't give them
anything extra. If this is the case, then why require it to meet
1.3.5?

I really appreciate the dialogue! Thanks again!

Jared

From: John Foliot
Date: Fri, Jul 27 2018 12:47AM
Subject: Re: WCAG 2.1 - 1.3.5 - How to capture a violation?
← Previous message | Next message →

Hi Jared,

It's rather difficult to
explain that an associated label is "programmatically determined" to
convey "information and relationships" for an input under 1.3.1, but
is not "programmatically determined" to convey "purpose" for an input
under 1.3.5.

Quick check: we're not confusing "programmatically *associated*" with
"programmatically *determined*" here, correct?

An "associated label" (i.e. one that uses the <label> element) is but one
way of labeling an input to convey information and relationships; we could
also use @label or @labelledby to meet the requirements of SC 1.3.1. As
long as a "label" (aka Accessible Name) is programmatically determinable,
then the value string that is associated to the concept of "label" can also
be programmatically determined, and presented in a different modality (for
example, in audio via a screen reader).

*WHAT* the value string is (i.e. the text or instructions to convey the
purpose *to the human user*, in any language) is not covered by this SC,
but rather by an "Understanding" SC: Success Criterion 3.3.2 Labels or
Instructions (Level A): Labels or instructions are provided when content
requires user input. It's both SC, working together, that allows for both
Perceiveability and Understandability in this use-case.

Succinctly: 1.3.1 ensures that machines and software (like screen readers)
can determine that there is a label there, and further convey what the
label's "value" is to different modalities, 3.3.2 ensures that the end user
can actually understand the string and do something with it (i.e., interact
with the input)


(Quick related note - why is title attribute -
https://www.w3.org/TR/WCAG20-TECHS/H65.html - sufficient to meet
1.3.1? This doesn't seem to meet your definition for "programmatically
determined", right?)

ah yes, @title. A three part answer:

1) It is important to again remember that SC 1.3.1 wants a programmatically
determinable way of determining the the label for the input - a machine
recognizable identifier (for example @label or @title) that will have a
value string that, for the purposes of the accessibility API's need for an
"Accessible Name", can be a random string that can be both seen visually,
but also can be presented in a different modality (audio). Again the *value* of
the string here is for human consumption and cognition (thus a string that
still needs to be "understandable" to meet SC 3.3.2), but the "association"
is programmatically 'determined' (aka identified and associated) using an
attribute (fixed term) on the input element. (Remember too that it has to
be a fixed term, so that the machine has a fixed text string to "look up"
or pattern match against.)

2) Originally, the HTML Accessibility API Mappings 1.0 (
https://www.w3.org/TR/html-aam-1.0/#input-type-text-input-type-password-input-type-search-input-type-tel-input-type-url-and-textarea-element)
included @title as part of the Accessible Name calculation:

1. If the control has an aria-label
<https://www.w3.org/TR/wai-aria-1.1/#aria-label> or an aria-labelledby
<https://www.w3.org/TR/wai-aria-1.1/#aria-labelledby> attribute
the accessible
name <https://www.w3.org/TR/html-aam-1.0/#dfn-accessible-name> is to
be calculated using the algorithm defined in Accessible Name and
Description: Computation and API Mappings 1.1
<https://w3c.github.io/accname/>.
2. Otherwise use the associated label element(s) accessible name
<https://www.w3.org/TR/html-aam-1.0/#dfn-accessible-name>(s) - if
more than one label is associated; concatenate by DOM order,
delimited by spaces.
3. Otherwise use the title attribute
4. If none of the above yield a usable text string there is no accessible
name <https://www.w3.org/TR/html-aam-1.0/#dfn-accessible-name>

However, as we know, in practice this wasn't working - @title was *NOT*
being conveyed by screen readers as the accessible name. (I'll note that
this is the fault of the Screen Readers for not supporting the spec, but
also necessitating a change in the specification). This has been addressed
with the publishing of Accessible Name and Description Computation 1.1 (W3C
Candidate Recommendation 19 June 2018) (
https://www.w3.org/TR/accname-1.1/#mapping_additional_nd_te) which has
removed @title from the calculation. As such it has negated that technique
(note to self - action item two: more housekeeping)

3) We know that "technical conformance" does not equal "accessible", so the
technique, while ineffective today (and I would recommend it be avoided)
will none-the-less still meet the "technical conformance" that a legal
reading of WCAG 2.0. conformance may mandate. (In other words, because it
was an effective [sic] technique when 2.0 was published, we cannot un-ring
the legislative bell that attached legal conformance to the technical
specification.) It sucks, mostly because legislation demands a fixed
published spec, while technology changes daily from under our feet, but
that is the answer to your question. (On a more positive note, because
Techniques are non-normative, it may be easier to remove them, so I think
we'll be able to do so, but I cannot "guarantee" that - we may have to
settle with a WARNING in that technique.)


If a field maps to one of the defined "input purposes" and does not
have the proper autocomplete attribute, is it a failure? In other
words, is
<label>Name <input type="text"></label>
now a WCAG 2.1 failure?

Well... it does not meed the requirement of SC 1.3.5, but it does still
meet WCAG 2.1's SC 1.3.1 and SC 3.3.2. But broadly speaking, no, you could
not claim 2.1 conformance with that code snippet, because the value, while
in English in your example, can be any string text value in any language,
so it cannot be "looked up" by a machine. Machines need fixed token strings
to do that kind of functionality.


I really need a clear answer to this question. You've stated several
times that autocomplete is not the only way to meet this SC.

No I haven't Jared, please re-read my responses.

Today(!) the only *functioning technique* we have to meet this SC is to use
@autocomplete, but what is important to understand (with relationship to
the 'ask' of this SC) is what we needed to do: we needed a mechanism to
attach a fixed token string (a taxonomy term) to the input element that
could be machine interpreted for the purposes of output in different
modalities.

Initially, this SC had a lot more to it (common buttons and controls - see
this for an *idea* of what we were looking at:
https://docs.google.com/spreadsheets/d/1N63TKXrUXSmF1OeZAgpy8iTnDyQ1nzVbrevq2lBDvos/edit?usp=sharing
)
, but because we lacked the appropriate taxonomy, and creating a new
taxonomy was out of scope for our Working Group, we had to 'settle' for a
smaller
existing
taxonomy that was those token values initially defined in HTML5 for
@autocomplete
.

However, while that taxonomy has yet to be ported to say, a Schema.org
notation, I had also explored the ability to so, so that we could attach
that token value to an element using Microdata (
https://www.w3.org/TR/microdata/) - a technique put aside (due to the lack
of an established taxonomy) but I hope to continue to expand upon.

Additionally, and related to this discussion, the Personalization Task
force is currently exploring other/different mechanisms to attach an
extended taxonomy (under development) for other similar needs. (see:
https://github.com/w3c/personalization-semantics/wiki/Comparison-of-ways-to-use-vocabulary-in-content
)


This was
a primary factor in my misunderstanding this SC - I thought if
@autocomplete isn't required, then certainly a descriptive label is
therefore sufficient, because how else would they pass? Now, based on
your explanations, I don't see how anything other than @autocomplete
could be sufficient to meet this SC today.

Well, once again, a descriptive label is for the human to compute, but we
need a mechanism that also allows for a machine to compute the "Purpose" of
the element. That mechanism has two parts, a means of attaching it that is
"programmatically determinable" (i.e. an attribute), AS WELL AS a token
value taken from the list of defined tokens that are the @autocomplete/WCAG
2.1 tokens as the value string of the attribute. (In the same way that
@lang - the attribute, uses a fixed token - the country code values defined
in the ISO specification, as the two parts required to meet the Language
SC's: lang="en" passes, lang="english" fails)


As a follow-up... what if the associated label uses language that is
common and standard for that input purpose (e.g., "Name" or "Credit
card"). I believe most (all?) common form fillers interpret these
common label values to provide the needed form-fill functionality
(otherwise they wouldn't work on forms that lack @autocomplete).

Nope, because those are random text strings that, in your example, are in
the same language as the token (English), but often won't be. Additionally
and as an aside, "Credit Card" would not suffice, as the required token for
that input is actually (presumably?) cc-number (but, because your visible,
on-screen English label is actually too vague, could also be one of any of
the other cc-* values, such as cc-name, cc-address, etc. See:
http://john.foliot.ca/demos/autofill.php)

As for form fillers, my limited testing (
https://www.w3.org/WAI/GL/wiki/WCAG_2.1_Implementations/JF/research)
suggests that those tools are currently doing heuristics against English
token values, but they don't work very well if you aren't using the English
token somewhere in the code, so their usefulness is significantly
diminished in non-English locales. This is a poster child for why
"standards" are so important: if those tools using heuristics today instead
supported the @autocomplete spec as defined, they could extend their market
reach, but, well, you know...


Using
@autocomplete would thus provide no additional benefit or
functionality in this case. If the author deems these to be
"accessibility supported", would this be sufficient to meet 1.3.5?

Functionality to whom? More importantly, is the benefit understood? That
what is being sought is not for the humans to consume directly, its for the
machines: the goal of this SC is NOT to make forms easier to fill out, but
rather for machines to understand, with zero ambiguity, what is being
sought in the tagged <input>, using an attribute and a fixed token or
taxonomy term, so that expressing that "purpose" or "label" can be further
conveyed to different modalities (such as using an icon). Please stop
thinking of this as a human-consumable requirement, it isn't, it's for
machines to do something with.


Your arguments about other languages seems a stretch here. Why would
someone that only speaks Vietnamese need to know the purpose of an
input on an English page they can't understand? But if their
Vietnamese form filler knows that "Số thẻ tín dụng" is for credit card
number on a Vietnamese page, then @autocomplete doesn't give them
anything extra. If this is the case, then why require it to meet
1.3.5?

Hopefully by now, the answer here is clear. The outcome of the Success
Criteria is to take "languages" out of the equation: we're using a fixed
token, written in English, as a value string for an attribute, also written
in English, "programmatically" attached to the <input> element - none of
which is shown on screen, but expressed in the DOM, so that machines now
also understand (or at least can be programmed to understand) what is being
sought. The fact that the only technique we can apply today also has (for
purposes of this SC) the added benefit that browsers and other tools can
also act on that metadata by, for example, supplying *your* data (localized
text strings stored locally in the browser or password manager tools) when
the machine understands what is being asked for in a form input is a bonus:
that functionality is but one outcome achieved when you tag the input with
a fixed token value, but not the goal of the SC (which, coming full circle,
I acknowledge is less than clear in the Understanding document, which needs
to be fixed).


HTH

JF

On Thu, Jul 26, 2018 at 10:10 AM, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:

> John -
>
> Thanks for taking the time to provide such a detailed explanation.
> This really is very helpful and informative.
>
> I've always viewed programmatically determined as being adapted in a
> way or "different modalities" that provides meaning and usefulness to
> the user. But I can see based on your explanations that this
> user-focused interpretation is too broad - it focuses instead only on
> computer parsing.
>
> I won't belabor the discussion about the semantics and nuances of the
> language and terms any more, except to restate that I do not believe
> that we can expect web authors to understand the requirements of this
> success criterion from the normative text. It's rather difficult to
> explain that an associated label is "programmatically determined" to
> convey "information and relationships" for an input under 1.3.1, but
> is not "programmatically determined" to convey "purpose" for an input
> under 1.3.5.
>
> (Quick related note - why is title attribute -
> https://www.w3.org/TR/WCAG20-TECHS/H65.html - sufficient to meet
> 1.3.1? This doesn't seem to meet your definition for "programmatically
> determined", right?)
>
> But this language and the W3C's interpretation of it is not changing.
> So it becomes incumbent upon us to try to explain it in ways that will
> minimize confusion and potential liability for web authors. Which
> brings me to a couple additional questions...
>
> If a field maps to one of the defined "input purposes" and does not
> have the proper autocomplete attribute, is it a failure? In other
> words, is
> <label>Name <input type="text"></label>
> now a WCAG 2.1 failure?
>
> I really need a clear answer to this question. You've stated several
> times that autocomplete is not the only way to meet this SC. This was
> a primary factor in my misunderstanding this SC - I thought if
> @autocomplete isn't required, then certainly a descriptive label is
> therefore sufficient, because how else would they pass? Now, based on
> your explanations, I don't see how anything other than @autocomplete
> could be sufficient to meet this SC today.
>
> As a follow-up... what if the associated label uses language that is
> common and standard for that input purpose (e.g., "Name" or "Credit
> card"). I believe most (all?) common form fillers interpret these
> common label values to provide the needed form-fill functionality
> (otherwise they wouldn't work on forms that lack @autocomplete). Using
> @autocomplete would thus provide no additional benefit or
> functionality in this case. If the author deems these to be
> "accessibility supported", would this be sufficient to meet 1.3.5?
>
> Your arguments about other languages seems a stretch here. Why would
> someone that only speaks Vietnamese need to know the purpose of an
> input on an English page they can't understand? But if their
> Vietnamese form filler knows that "Số thẻ tín dụng" is for credit card
> number on a Vietnamese page, then @autocomplete doesn't give them
> anything extra. If this is the case, then why require it to meet
> 1.3.5?
>
> I really appreciate the dialogue! Thanks again!
>
> Jared
> > > > >



--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
= EMAIL ADDRESS REMOVED =

Advancing the mission of digital accessibility and inclusion

From: Jonathan Avila
Date: Fri, Jul 27 2018 5:31AM
Subject: Re: WCAG 2.1 - 1.3.5 - How to capture a violation?
← Previous message | Next message →

Don't forget WCAG2.0 also has 2.4.6 headings and labels describe topic or purpose but unlike 1.3.5 doesn't require it to be programmatically determinable.

Jonathan

Sent from my iPhone

> On Jul 27, 2018, at 2:48 AM, John Foliot < = EMAIL ADDRESS REMOVED = > wrote:
>
> Hi Jared,
>
> It's rather difficult to
> explain that an associated label is "programmatically determined" to
> convey "information and relationships" for an input under 1.3.1, but
> is not "programmatically determined" to convey "purpose" for an input
> under 1.3.5.
>
> Quick check: we're not confusing "programmatically *associated*" with
> "programmatically *determined*" here, correct?
>
> An "associated label" (i.e. one that uses the <label> element) is but one
> way of labeling an input to convey information and relationships; we could
> also use @label or @labelledby to meet the requirements of SC 1.3.1. As
> long as a "label" (aka Accessible Name) is programmatically determinable,
> then the value string that is associated to the concept of "label" can also
> be programmatically determined, and presented in a different modality (for
> example, in audio via a screen reader).
>
> *WHAT* the value string is (i.e. the text or instructions to convey the
> purpose *to the human user*, in any language) is not covered by this SC,
> but rather by an "Understanding" SC: Success Criterion 3.3.2 Labels or
> Instructions (Level A): Labels or instructions are provided when content
> requires user input. It's both SC, working together, that allows for both
> Perceiveability and Understandability in this use-case.
>
> Succinctly: 1.3.1 ensures that machines and software (like screen readers)
> can determine that there is a label there, and further convey what the
> label's "value" is to different modalities, 3.3.2 ensures that the end user
> can actually understand the string and do something with it (i.e., interact
> with the input)
>
>
> (Quick related note - why is title attribute -
> https://www.w3.org/TR/WCAG20-TECHS/H65.html - sufficient to meet
> 1.3.1? This doesn't seem to meet your definition for "programmatically
> determined", right?)
>
> ah yes, @title. A three part answer:
>
> 1) It is important to again remember that SC 1.3.1 wants a programmatically
> determinable way of determining the the label for the input - a machine
> recognizable identifier (for example @label or @title) that will have a
> value string that, for the purposes of the accessibility API's need for an
> "Accessible Name", can be a random string that can be both seen visually,
> but also can be presented in a different modality (audio). Again the *value* of
> the string here is for human consumption and cognition (thus a string that
> still needs to be "understandable" to meet SC 3.3.2), but the "association"
> is programmatically 'determined' (aka identified and associated) using an
> attribute (fixed term) on the input element. (Remember too that it has to
> be a fixed term, so that the machine has a fixed text string to "look up"
> or pattern match against.)
>
> 2) Originally, the HTML Accessibility API Mappings 1.0 (
> https://www.w3.org/TR/html-aam-1.0/#input-type-text-input-type-password-input-type-search-input-type-tel-input-type-url-and-textarea-element)
> included @title as part of the Accessible Name calculation:
>
> 1. If the control has an aria-label
> <https://www.w3.org/TR/wai-aria-1.1/#aria-label> or an aria-labelledby
> <https://www.w3.org/TR/wai-aria-1.1/#aria-labelledby> attribute
> the accessible
> name <https://www.w3.org/TR/html-aam-1.0/#dfn-accessible-name> is to
> be calculated using the algorithm defined in Accessible Name and
> Description: Computation and API Mappings 1.1
> <https://w3c.github.io/accname/>.
> 2. Otherwise use the associated label element(s) accessible name
> <https://www.w3.org/TR/html-aam-1.0/#dfn-accessible-name>(s) - if
> more than one label is associated; concatenate by DOM order,
> delimited by spaces.
> 3. Otherwise use the title attribute
> 4. If none of the above yield a usable text string there is no accessible
> name <https://www.w3.org/TR/html-aam-1.0/#dfn-accessible-name>
>
> However, as we know, in practice this wasn't working - @title was *NOT*
> being conveyed by screen readers as the accessible name. (I'll note that
> this is the fault of the Screen Readers for not supporting the spec, but
> also necessitating a change in the specification). This has been addressed
> with the publishing of Accessible Name and Description Computation 1.1 (W3C
> Candidate Recommendation 19 June 2018) (
> https://www.w3.org/TR/accname-1.1/#mapping_additional_nd_te) which has
> removed @title from the calculation. As such it has negated that technique
> (note to self - action item two: more housekeeping)
>
> 3) We know that "technical conformance" does not equal "accessible", so the
> technique, while ineffective today (and I would recommend it be avoided)
> will none-the-less still meet the "technical conformance" that a legal
> reading of WCAG 2.0. conformance may mandate. (In other words, because it
> was an effective [sic] technique when 2.0 was published, we cannot un-ring
> the legislative bell that attached legal conformance to the technical
> specification.) It sucks, mostly because legislation demands a fixed
> published spec, while technology changes daily from under our feet, but
> that is the answer to your question. (On a more positive note, because
> Techniques are non-normative, it may be easier to remove them, so I think
> we'll be able to do so, but I cannot "guarantee" that - we may have to
> settle with a WARNING in that technique.)
>
>
> If a field maps to one of the defined "input purposes" and does not
> have the proper autocomplete attribute, is it a failure? In other
> words, is
> <label>Name <input type="text"></label>
> now a WCAG 2.1 failure?
>
> Well... it does not meed the requirement of SC 1.3.5, but it does still
> meet WCAG 2.1's SC 1.3.1 and SC 3.3.2. But broadly speaking, no, you could
> not claim 2.1 conformance with that code snippet, because the value, while
> in English in your example, can be any string text value in any language,
> so it cannot be "looked up" by a machine. Machines need fixed token strings
> to do that kind of functionality.
>
>
> I really need a clear answer to this question. You've stated several
> times that autocomplete is not the only way to meet this SC.
>
> No I haven't Jared, please re-read my responses.
>
> Today(!) the only *functioning technique* we have to meet this SC is to use
> @autocomplete, but what is important to understand (with relationship to
> the 'ask' of this SC) is what we needed to do: we needed a mechanism to
> attach a fixed token string (a taxonomy term) to the input element that
> could be machine interpreted for the purposes of output in different
> modalities.
>
> Initially, this SC had a lot more to it (common buttons and controls - see
> this for an *idea* of what we were looking at:
> https://docs.google.com/spreadsheets/d/1N63TKXrUXSmF1OeZAgpy8iTnDyQ1nzVbrevq2lBDvos/edit?usp=sharing
> )
> , but because we lacked the appropriate taxonomy, and creating a new
> taxonomy was out of scope for our Working Group, we had to 'settle' for a
> smaller
> existing
> taxonomy that was those token values initially defined in HTML5 for
> @autocomplete
> .
>
> However, while that taxonomy has yet to be ported to say, a Schema.org
> notation, I had also explored the ability to so, so that we could attach
> that token value to an element using Microdata (
> https://www.w3.org/TR/microdata/) - a technique put aside (due to the lack
> of an established taxonomy) but I hope to continue to expand upon.
>
> Additionally, and related to this discussion, the Personalization Task
> force is currently exploring other/different mechanisms to attach an
> extended taxonomy (under development) for other similar needs. (see:
> https://github.com/w3c/personalization-semantics/wiki/Comparison-of-ways-to-use-vocabulary-in-content
> )
>
>
> This was
> a primary factor in my misunderstanding this SC - I thought if
> @autocomplete isn't required, then certainly a descriptive label is
> therefore sufficient, because how else would they pass? Now, based on
> your explanations, I don't see how anything other than @autocomplete
> could be sufficient to meet this SC today.
>
> Well, once again, a descriptive label is for the human to compute, but we
> need a mechanism that also allows for a machine to compute the "Purpose" of
> the element. That mechanism has two parts, a means of attaching it that is
> "programmatically determinable" (i.e. an attribute), AS WELL AS a token
> value taken from the list of defined tokens that are the @autocomplete/WCAG
> 2.1 tokens as the value string of the attribute. (In the same way that
> @lang - the attribute, uses a fixed token - the country code values defined
> in the ISO specification, as the two parts required to meet the Language
> SC's: lang="en" passes, lang="english" fails)
>
>
> As a follow-up... what if the associated label uses language that is
> common and standard for that input purpose (e.g., "Name" or "Credit
> card"). I believe most (all?) common form fillers interpret these
> common label values to provide the needed form-fill functionality
> (otherwise they wouldn't work on forms that lack @autocomplete).
>
> Nope, because those are random text strings that, in your example, are in
> the same language as the token (English), but often won't be. Additionally
> and as an aside, "Credit Card" would not suffice, as the required token for
> that input is actually (presumably?) cc-number (but, because your visible,
> on-screen English label is actually too vague, could also be one of any of
> the other cc-* values, such as cc-name, cc-address, etc. See:
> http://john.foliot.ca/demos/autofill.php)
>
> As for form fillers, my limited testing (
> https://www.w3.org/WAI/GL/wiki/WCAG_2.1_Implementations/JF/research)
> suggests that those tools are currently doing heuristics against English
> token values, but they don't work very well if you aren't using the English
> token somewhere in the code, so their usefulness is significantly
> diminished in non-English locales. This is a poster child for why
> "standards" are so important: if those tools using heuristics today instead
> supported the @autocomplete spec as defined, they could extend their market
> reach, but, well, you know...
>
>
> Using
> @autocomplete would thus provide no additional benefit or
> functionality in this case. If the author deems these to be
> "accessibility supported", would this be sufficient to meet 1.3.5?
>
> Functionality to whom? More importantly, is the benefit understood? That
> what is being sought is not for the humans to consume directly, its for the
> machines: the goal of this SC is NOT to make forms easier to fill out, but
> rather for machines to understand, with zero ambiguity, what is being
> sought in the tagged <input>, using an attribute and a fixed token or
> taxonomy term, so that expressing that "purpose" or "label" can be further
> conveyed to different modalities (such as using an icon). Please stop
> thinking of this as a human-consumable requirement, it isn't, it's for
> machines to do something with.
>
>
> Your arguments about other languages seems a stretch here. Why would
> someone that only speaks Vietnamese need to know the purpose of an
> input on an English page they can't understand? But if their
> Vietnamese form filler knows that "Số thẻ tín dụng" is for credit card
> number on a Vietnamese page, then @autocomplete doesn't give them
> anything extra. If this is the case, then why require it to meet
> 1.3.5?
>
> Hopefully by now, the answer here is clear. The outcome of the Success
> Criteria is to take "languages" out of the equation: we're using a fixed
> token, written in English, as a value string for an attribute, also written
> in English, "programmatically" attached to the <input> element - none of
> which is shown on screen, but expressed in the DOM, so that machines now
> also understand (or at least can be programmed to understand) what is being
> sought. The fact that the only technique we can apply today also has (for
> purposes of this SC) the added benefit that browsers and other tools can
> also act on that metadata by, for example, supplying *your* data (localized
> text strings stored locally in the browser or password manager tools) when
> the machine understands what is being asked for in a form input is a bonus:
> that functionality is but one outcome achieved when you tag the input with
> a fixed token value, but not the goal of the SC (which, coming full circle,
> I acknowledge is less than clear in the Understanding document, which needs
> to be fixed).
>
>
> HTH
>
> JF
>
>> On Thu, Jul 26, 2018 at 10:10 AM, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
>>
>> John -
>>
>> Thanks for taking the time to provide such a detailed explanation.
>> This really is very helpful and informative.
>>
>> I've always viewed programmatically determined as being adapted in a
>> way or "different modalities" that provides meaning and usefulness to
>> the user. But I can see based on your explanations that this
>> user-focused interpretation is too broad - it focuses instead only on
>> computer parsing.
>>
>> I won't belabor the discussion about the semantics and nuances of the
>> language and terms any more, except to restate that I do not believe
>> that we can expect web authors to understand the requirements of this
>> success criterion from the normative text. It's rather difficult to
>> explain that an associated label is "programmatically determined" to
>> convey "information and relationships" for an input under 1.3.1, but
>> is not "programmatically determined" to convey "purpose" for an input
>> under 1.3.5.
>>
>> (Quick related note - why is title attribute -
>> https://www.w3.org/TR/WCAG20-TECHS/H65.html - sufficient to meet
>> 1.3.1? This doesn't seem to meet your definition for "programmatically
>> determined", right?)
>>
>> But this language and the W3C's interpretation of it is not changing.
>> So it becomes incumbent upon us to try to explain it in ways that will
>> minimize confusion and potential liability for web authors. Which
>> brings me to a couple additional questions...
>>
>> If a field maps to one of the defined "input purposes" and does not
>> have the proper autocomplete attribute, is it a failure? In other
>> words, is
>> <label>Name <input type="text"></label>
>> now a WCAG 2.1 failure?
>>
>> I really need a clear answer to this question. You've stated several
>> times that autocomplete is not the only way to meet this SC. This was
>> a primary factor in my misunderstanding this SC - I thought if
>> @autocomplete isn't required, then certainly a descriptive label is
>> therefore sufficient, because how else would they pass? Now, based on
>> your explanations, I don't see how anything other than @autocomplete
>> could be sufficient to meet this SC today.
>>
>> As a follow-up... what if the associated label uses language that is
>> common and standard for that input purpose (e.g., "Name" or "Credit
>> card"). I believe most (all?) common form fillers interpret these
>> common label values to provide the needed form-fill functionality
>> (otherwise they wouldn't work on forms that lack @autocomplete). Using
>> @autocomplete would thus provide no additional benefit or
>> functionality in this case. If the author deems these to be
>> "accessibility supported", would this be sufficient to meet 1.3.5?
>>
>> Your arguments about other languages seems a stretch here. Why would
>> someone that only speaks Vietnamese need to know the purpose of an
>> input on an English page they can't understand? But if their
>> Vietnamese form filler knows that "Số thẻ tín dụng" is for credit card
>> number on a Vietnamese page, then @autocomplete doesn't give them
>> anything extra. If this is the case, then why require it to meet
>> 1.3.5?
>>
>> I really appreciate the dialogue! Thanks again!
>>
>> Jared
>> >> >> >> >>
>
>
>
> --
> John Foliot
> Principal Accessibility Strategist
> Deque Systems Inc.
> = EMAIL ADDRESS REMOVED =
>
> Advancing the mission of digital accessibility and inclusion
> > > >

From: Jared Smith
Date: Fri, Jul 27 2018 8:30AM
Subject: Re: WCAG 2.1 - 1.3.5 - How to capture a violation?
← Previous message | Next message →

John -

Thank you for the detailed explanations. As I promised, I won't
belabor the discussion about the language further. The fact it's taken
such a lengthy conversation for you to explain the language and nuance
of this success criterion to me should hopefully be a good indication
of how difficult this will be for us to explain to others.

> the goal of this SC is NOT to make forms easier to fill out, but
> rather for machines to understand

> Please stop thinking of this as a human-consumable requirement,
> it isn't, it's for machines to do something with.

These statements pretty much sum up my disappointment in all of this.
WCAG would now demand 100% non-ambiguous perfection for machines in
situations where the field purpose is already fully understood by and
accessible to end users. It favors the machine over the human, and
does so by burdening human authors.

I do hope there will be consideration for a sufficient technique for
basic forms where informative form labels are used (which, as Jonathan
noted, is already required by 2.4.6). Every form filler can (or
readily could) support with very high levels of accuracy the
identification of input purpose for the majority of forms on the web
(username/password, basic registration forms, shipping details, etc.).

As an example, I took your example form
(http://john.foliot.ca/demos/autofill.php) and removed all
autocomplete attributes. With my form filler, the results were nearly
identical both with and without the attributes. Without the attributes
it didn't fill in "sex" (but does work with "gender") and "Telephone:
Country Code" was filled with country name rather than code - both
readily fixable with minor improvements to the text parsing in the
form filler. In short, @autocomplete provided almost no added benefit.

Now I fully understand your argument about fields where the purpose
may be ambiguous or non-standard, that do not have common, informative
label values, or are in a language where user agents do not yet
properly parse the field labels. Certainly autocomplete would be
useful here. But these are the exception, not the norm. And shouldn't
the burden here be more on the user agent to support these fields
rather than the author to add extra code?

Web forms that are currently properly parsed by form fillers (i.e.,
are "accessibility supported"), are WCAG 2.0 conformant, and are fully
accessible to end users are now non-conformant with WCAG 2.1 AA
because they lack an attribute that is intended to tell the machine
something it has already accurately surmised from the label. To become
2.1 conformant the authors of these forms are now required to add code
that would thus do nothing to improve accessibility for end users.

Thanks,

Jared

From: chagnon
Date: Fri, Jul 27 2018 9:24AM
Subject: Re: WCAG 2.1 - 1.3.5 - How to capture a violation?
← Previous message | Next message →

Agee with Jared, quoted below:
" It favors the machine over the human, and does so by burdening human
authors. "

Which nimrod turned accessibility around to now make machines happy, rather
than the people who use machines? Is this why we're all here?

Flip around the focus: we should figure out how to make content work better
for people, and then program the machines to provide the content in the way
it's needed.

Accessibility is for people, not for machines.

--Bevi Chagnon
- - -
Bevi Chagnon, founder/CEO | = EMAIL ADDRESS REMOVED =
- - -
PubCom: Technologists for Accessible Design + Publishing
consulting . training . development . design . sec. 508 services
Upcoming classes at www.PubCom.com/classes
- - -
Latest blog-newsletter - Accessibility Tips

From: Karlen Communications
Date: Fri, Jul 27 2018 9:59AM
Subject: Re: WCAG 2.1 - 1.3.5 - How to capture a violation?
← Previous message | Next message →

Amen! Preach!

I realize that the "machines are winning" every day I try to use my adaptive
technology and spend hours on content that should be simple enough to
access.

Cheers, Karen

From: Jeremy Echols
Date: Fri, Jul 27 2018 12:51PM
Subject: Re: WCAG 2.1 - 1.3.5 - How to capture a violation?
← Previous message | Next message →

As a developer, I find this burdensome, but it also makes a great deal of sense. If somebody has a form input labeled "Last Name", sure, that's pretty clear. But sometimes you'll see something like "Enter your surname" or "What is your last name / surname?". I can figure this out. Most people I know can figure it out. But inclusive design should never be about what "most" people can figure out.

For people who already have cognitive challenges like dyslexia, I can see a huge benefit in using a machine-friendly taxonomy that can map to unambiguous terms.

From: Jared Smith
Date: Fri, Jul 27 2018 2:43PM
Subject: Re: WCAG 2.1 - 1.3.5 - How to capture a violation?
← Previous message | Next message →

Jeremy -

I absolutely agree. In cases where the purpose of the field is
ambiguous, using autocomplete is incredibly helpful and should be
required.

But the same software that parses autocomplete="family-name" already
knows that <label>Last Name: <input type="text"></label> is the same
thing, and thus provides identical functionality when you request help
in completing this field? Does it then make sense to require authors
to add the autocomplete attribute if it provides no better
accessibility?

I'd think it worthwhile to examine this further as a possible
sufficient technique, though recognize that this would rely on authors
to provide an equivalent label text that is "accessibility supported"
by form fillers (something much more difficult to define than the
blanket "autocomplete is required").

I have considered the scenario where the input is for entering someone
else's last name. In this case, autocomplete would not be used, yet
the form filler would, if activated erroneously, fill it with the
user's last name. But this is the current reality anyway. The form
fillers already use form labels in their heuristics if autocomplete
isn't present (and perhaps even if it is). The only way to avoid this
potential issue is for form fillers to ONLY respect @autocomplete, and
that certainly is not going to happen - they'd stop working on nearly
all web forms (including the ones that passed 2.0, but now fail 2.1
without having changed).

Thanks,

Jared

From: Jeremy Echols
Date: Fri, Jul 27 2018 3:39PM
Subject: Re: WCAG 2.1 - 1.3.5 - How to capture a violation?
← Previous message | Next message →

I think ambiguity is a slippery thing to define in any kind of normative way. Better to just say "here's a list of terms that are always known to mean a specific thing". With a clearly defined taxonomy, you don't have to build any kind of AI to guess at fields, so the programmatic use of these fields is open to a much wider audience, which can be useful.

That said, "autocomplete" feels very wrong for this purpose. I feel like this should be a new attribute, like aria-purpose or something.

It also seems like this SC should have been rolled out slowly, especially given how much confusion it's generated. I could see this as a AAA failure with some intent to make it higher priority in the future. Those of us targeting AA are going to immediately fail without another massive audit we weren't prepared for. It may even simply put off some authors entirely, and cause them to say, "AA is getting too difficult; let's just support WCAG A", which is a major loss.

I do like the intent behind this, but it's definitely a tricky one.

From: John Foliot
Date: Fri, Jul 27 2018 7:25PM
Subject: Re: WCAG 2.1 - 1.3.5 - How to capture a violation?
← Previous message | Next message →

Jared,

These statements pretty much sum up my disappointment in all of this.
WCAG would now demand 100% non-ambiguous perfection for machines in
situations where the field purpose is already fully understood by and
accessible to end users.

I'm sorry Jared, I fundamentally reject that assertion. You and I both know
that for many users that is simply not the case - that no web page on the
internet today is "fully" understood and accessible to all end users.
Virtually all of the new SC that emerged in 2.1 came from addressing known
gaps in 2.0 in the areas of Cognitive disabilities, Low Vision users (see
1.4.10 Reflow), and "Mobile" (which got abstracted for the most part to
touch interfaces - see 2.5.5 Target Size)

As I've previously noted, many of the use-cases that informed this SC were
based upon researched conducted and documented by the COGA Task Force. That
user group is currently significantly under-served by WCAG, in part due to
the complexity of finding a scalable way of addressing the myriad needs of
that community. This is a "foot in the door" start, with a goal of
addressing partial needs for some COGA users: users with Dyslexia and users
with
Aphasia.

*Users with Dyslexia* (https://www.w3.org/TR/coga-user-research/#dyslexia)
often still struggle with forms. Specific to form inputs, issues include:
Memory

- Mistakes with routine information, e.g., providing age, phone number,
or ages of children.
- Inability to hold on to information without referring to notes.

Automatizing Skills


- People with dyslexia do not tend to automatize skills very well. A
high degree of mental effort is required in carrying out tasks that typical
individuals generally do not feel requires effort. This is particularly
true when the skill is composed of several sub-skills (e.g., reading,
writing, driving).

Information Processing.

- Difficulties with taking in information efficiently (could be written
or auditory).
- Slow speed of information processing, such as a 'penny dropping' delay
between hearing or reading something and understanding and responding to it.

Literacy

- If people are undiagnosed or diagnosed late, they may be illiterate or
barely literate.
- Where literacy has been mastered, problems continue, such as poor
spelling; difficulty extracting meaning from written material; difficulty
with unfamiliar words; and difficulty with scanning or skimming text
.

Organization, Sequencing

- Incorrect sequencing of strings of numbers and letters (passwords,
phone numbers)

*User Story:*

*Harry is a high school student with dyslexia. Although he can read, his
level is slow and he finds it difficult. Harry does not use a screen reader
because he is afraid it will stop him from reading and improving his
skills. Harry wishes that forms could *
*be personalized to **display icons instead of text, as he finds those
easier to recognize and understand*
*.*



Then there are
*users with Aphasia* (https://www.w3.org/TR/coga-user-research/#aphasia).
"
Communication difficulties may arise as the result of what is commonly
known as a stroke. The type of impairment that results is known as Aphasia
due to brain damage, which may cause receptive (comprehension) and
expressive (speech and language) difficulties, or dysarthria and dyspraxia
where words can become unintelligible, amongst other difficulties.
"
Again, specific to forms, issues might include:

*Memory*

- Receptive and Expressive Aphasia may result in impaired short term
memory which can impact on re-learning language as can the impairment of
auditory memory for relearning correct articulation *and visual memory
that affects reading and writing*.

*Reasoning*

- Where intellectual capacity is affected there may be issues with
reasoning, learning and thus remembering plus abstraction.

*Language*


- Aphasia can cause difficulties with word finding, the meanings of
words and sentences, grammar and comprehension affecting the ability to
communicate.

*Visual Perception*


- Not recognising letters and words impact on reading and even object
recognition can be affected.

*Knowledge*


- Aphasia does not necessarily impact on intelligence but knowledge will
be trapped within the brain if the individual cannot express their thoughts.


I'll stop here (there's plenty more research at the referenced W3C URL),
but suffice to say, based upon the above research, I will respectfully
suggest
Jared
perhaps typed that comment without fully thinking through what
he was
saying.


It favors the machine over the human, and does so by burdening human
authors.


While I respect that as a concern, how many times do we also here similar
arguments when it comes to adding aria attributes, or even (
in the past
) alt text? As previously noted, we're aware of this issue, which is why
we're also continuing to research alternative ways of applying or attaching
meta-data like this to, not only form inputs, but other critical page
controls. I previously referred you to this research (*Comparison of ways
to use vocabulary in content* -
https://github.com/w3c/personalization-semantics/wiki/Comparison-of-ways-to-use-vocabulary-in-content),

which includes
exploring ways of addressing this need
, including different methods of applying element level metadata, and
looking at mechanisms that work with
lower-level APIs. But yes, today, there is an authoring burden (although,
because the requirement is to attach one of a fixed number of token values,
this could be reasonably addressed in WYSIWYG editors via a drop-down or
similar feature).


But the same software that parses autocomplete="family-name" already
knows that <label>Last Name: <input type="text"></label> is the same
thing, and thus provides identical functionality when you request help
in completing this field?


Sorry once again my friend, I reject that as a far too Western-centric
comment. As an example of why I reject your claim, I encourage you to wheel
on over to here: http://www.sunnlenska.is/frettir/6025.html
(and yes, there are other accessibility concerns with that page, but for
the purpose of this discussion, let's just focus on the form)


Question, is your "form-filler" able to autocomplete the Form "Senda
frétt"? (right hand side - there is an icon of an envelope)

In my version of Firefox, despite the fact that the I've added the
appropriate text strings to support automatically filling in forms (i.e.,
my email address is remembered, as one example), that form will not be auto
-
completed - including the third field which *is* seeking your email address
(translated here:
https://translate.google.com/translate?hl=en&sl=is&tl=en&u=http%3A%2F%2Fwww.sunnlenska.is%2Ffrettir%2F6025.html
)

Why?
B
ecause nowhere in the source code related to that input is the string
"email". The heuristics you are relying on to support that statement cannot
be performed "programmat
i
cally", because the 'common' (Western/English-centric) text-string used
for the heuristics
is not
present on this Icelandic-language page
.


...though recognize that this would rely on authors
to
provide an equivalent label text that is "accessibility supported"
by form fillers (something much more difficult to define than the
blanket "autocomplete is required").

Let me re-state that slightly differently: "...provide an equivalent TOKEN
that is "accessibility supported"..."
, which is effectively what using the @autocomplete attribute delivers. And
how is that "accessibility supported" requirement achieved? By restricting
the list of token values to a fixed list, so that the machines can do the
look-up.

Remember again that WCAG seeks to avoid being overly prescriptive, which is
why nowhere in the SC does it state "autocomplete is required" - which is
what some folks are interpreting this SC to mean, but that's a false
reading of the requirement (which I've previously tried to untangle in this
thread). The issue is that today, the only "accessibility supported"
technique available is to use @autocomplete.


I have considered the scenario where the input is for entering someone
else's last name. In this case, autocomplete would not be used, yet
the form filler would, if activated erroneously, fill it with the
user's last name.


Maybe, maybe not: it all depends on what token string is associated to the
label in the code. Besides, this SC is scoped to data related to the
individual user, and not to other potential names.

The form
fillers already use form labels in their heuristics if autocomplete
isn't present (and perhaps even if it is). The only way to avoid this
potential issue is for form fillers to ONLY respect @autocomplete...


Jared!!! This SC is NOT (I repeat, *NOT*) about the actual function of *filling
in the fields* (which would have made it an "Operable" SC - aka a 2.x.x
SC), or even that the Purpose is clear to the end user via on-screen or
audio labelling (an Understanding SC - aka 3.x.x) - it's about being able
to "Perceive" what the form input is for - its *Purpose - *and that the
purpose can be* programmatically determined*. That's it, nothing more than
that.

It's about facilitating Personalization, an entry-level SC that is leading
towards a far greater desire for page customizations or Personalizations.
It is completely about machine understanding - "Programmatic Determination"
- so that machines can do something with the authored content. Currently,
one such "doing something" (not necessarily a "purpose" outcome) is the
auto-completion of those forms (**if** you've stored the correct values,
*your* name, *your* email, etc. in the local user-agent).

Focusing on that function however completely misses the point of the SC,
which we should all remember is entitled "*Identify Input Purpose*" and not
"Facilitate Form Completion". I personally believe the root of confusion in
this thread is failing to read the title and requirement of the actual SC,
as too many authors are focusing on a (the?) technique instead.


Meanwhile, Jeremy wrote:

With a clearly defined taxonomy, you don't have to build any kind of AI to
guess at fields, so the programmatic use of these fields is open to a much
wider audience, which can be useful.

Exactly. One additional constraint we had to deal with was the fact that
our W3C charter did not permit us to create a new taxonomy, so we had to
find one that served the purpose. That taxonomy, the "look up table" that
is the list of tokens and definitions previously defined in HTML5 (as part
of *that* Working Group's output) met the basic need. It is not an accident
however that the list is re-published in WCAG, not as "autocomplete values"
but rather as *Section 7. Input Purposes for User Interface Components* (
https://www.w3.org/TR/WCAG21/#input-purposes
) - also part of the normative spec.

That section further states:

"

*This section contains a listing of common user interface component
<https://www.w3.org/TR/WCAG21/#dfn-user-interface-components> input
purposes. The terms below are not keywords that must be used(*), but
instead represent purposes that must be captured in the taxonomy adopted by
a webpage. Where applicable, authors mark up controls with the chosen
taxonomy to indicate the semantic purpose. This provides the potential for
user agents and assistive technologies to apply personalized presentations
that can enable more people to understand and use the content."(* although
that is not forbidden either - JF)*

However, today, the only "accessibility supported" means of attaching those
purposes is to use the keywords (tokens) and the @autocomplete attribute.
I've previously linked the ongoing work to find other attributes or
alternative mechanisms that could also meet this requirement (including
perhaps minting a new aria-purpose attribute, or by using Microdata, or
JSON LD, or RDFa, or...). The current problem however is even if we minted
a new aria-attribute tomorrow (which won't happen, it takes at least 2
years for things like that to happen at the W3C), we ALSO need to satisfy
the "accessibility supported" requirement that is also part of WCAG 2.0 and
2.1. Because @autocomplete is a valid attribute that shares the same
taxonomy terms and is accessibility supported today, we were able to
re-purpose the attribute to attach the metadata, and by using a normative
attribute that is already being used in the wild today.

That said, "autocomplete" feels very wrong for this purpose.


Well, I'd argue not "VERY" wrong, but it is doing some re-purposing that
may not be 100% clear (as witnessed by this thread). It is (and was) a
tricky needle to thread, but it meets the need.

I feel like this should be a new attribute, like aria-purpose or something.


Like I said, we're working on it
<https://github.com/w3c/personalization-semantics/wiki/Comparison-of-ways-to-use-vocabulary-in-content>
...

JF



On Fri, Jul 27, 2018 at 3:43 PM, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:

> Jeremy -
>
> I absolutely agree. In cases where the purpose of the field is
> ambiguous, using autocomplete is incredibly helpful and should be
> required.
>
> But the same software that parses autocomplete="family-name" already
> knows that <label>Last Name: <input type="text"></label> is the same
> thing, and thus provides identical functionality when you request help
> in completing this field? Does it then make sense to require authors
> to add the autocomplete attribute if it provides no better
> accessibility?
>
> I'd think it worthwhile to examine this further as a possible
> sufficient technique, though recognize that this would rely on authors
> to provide an equivalent label text that is "accessibility supported"
> by form fillers (something much more difficult to define than the
> blanket "autocomplete is required").
>
> I have considered the scenario where the input is for entering someone
> else's last name. In this case, autocomplete would not be used, yet
> the form filler would, if activated erroneously, fill it with the
> user's last name. But this is the current reality anyway. The form
> fillers already use form labels in their heuristics if autocomplete
> isn't present (and perhaps even if it is). The only way to avoid this
> potential issue is for form fillers to ONLY respect @autocomplete, and
> that certainly is not going to happen - they'd stop working on nearly
> all web forms (including the ones that passed 2.0, but now fail 2.1
> without having changed).
>
> Thanks,
>
> Jared
> > > > >



--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
= EMAIL ADDRESS REMOVED =

Advancing the mission of digital accessibility and inclusion

From: Katie Haritos-Shea
Date: Fri, Jul 27 2018 8:54PM
Subject: Re: WCAG 2.1 - 1.3.5 - How to capture a violation?
← Previous message | Next message →

As someone who blatantly ridiculed the COGA people, task force and work, I
find this defense of an unbaked SC trying to make others seem 'uninformed'
and 'insensitive'' to COGA needs, nauseating.

On Fri, Jul 27, 2018, 9:25 PM John Foliot < = EMAIL ADDRESS REMOVED = > wrote:

> Jared,
>
> These statements pretty much sum up my disappointment in all of this.
> WCAG would now demand 100% non-ambiguous perfection for machines in
> situations where the field purpose is already fully understood by and
> accessible to end users.
>
> I'm sorry Jared, I fundamentally reject that assertion. You and I both know
> that for many users that is simply not the case - that no web page on the
> internet today is "fully" understood and accessible to all end users.
> Virtually all of the new SC that emerged in 2.1 came from addressing known
> gaps in 2.0 in the areas of Cognitive disabilities, Low Vision users (see
> 1.4.10 Reflow), and "Mobile" (which got abstracted for the most part to
> touch interfaces - see 2.5.5 Target Size)
>
> As I've previously noted, many of the use-cases that informed this SC were
> based upon researched conducted and documented by the COGA Task Force. That
> user group is currently significantly under-served by WCAG, in part due to
> the complexity of finding a scalable way of addressing the myriad needs of
> that community. This is a "foot in the door" start, with a goal of
> addressing partial needs for some COGA users: users with Dyslexia and users
> with
> Aphasia.
>
> *Users with Dyslexia* (https://www.w3.org/TR/coga-user-research/#dyslexia)
> often still struggle with forms. Specific to form inputs, issues include:
> Memory
>
> - Mistakes with routine information, e.g., providing age, phone number,
> or ages of children.
> - Inability to hold on to information without referring to notes.
>
> Automatizing Skills
>
>
> - People with dyslexia do not tend to automatize skills very well. A
> high degree of mental effort is required in carrying out tasks that
> typical
> individuals generally do not feel requires effort. This is particularly
> true when the skill is composed of several sub-skills (e.g., reading,
> writing, driving).
>
> Information Processing.
>
> - Difficulties with taking in information efficiently (could be written
> or auditory).
> - Slow speed of information processing, such as a 'penny dropping' delay
> between hearing or reading something and understanding and responding
> to it.
>
> Literacy
>
> - If people are undiagnosed or diagnosed late, they may be illiterate or
> barely literate.
> - Where literacy has been mastered, problems continue, such as poor
> spelling; difficulty extracting meaning from written material;
> difficulty
> with unfamiliar words; and difficulty with scanning or skimming text
> .
>
> Organization, Sequencing
>
> - Incorrect sequencing of strings of numbers and letters (passwords,
> phone numbers)
>
> *User Story:*
>
> *Harry is a high school student with dyslexia. Although he can read, his
> level is slow and he finds it difficult. Harry does not use a screen reader
> because he is afraid it will stop him from reading and improving his
> skills. Harry wishes that forms could *
> *be personalized to **display icons instead of text, as he finds those
> easier to recognize and understand*
> *.*
>
>
>
> Then there are
> *users with Aphasia* (https://www.w3.org/TR/coga-user-research/#aphasia).
> "
> Communication difficulties may arise as the result of what is commonly
> known as a stroke. The type of impairment that results is known as Aphasia
> due to brain damage, which may cause receptive (comprehension) and
> expressive (speech and language) difficulties, or dysarthria and dyspraxia
> where words can become unintelligible, amongst other difficulties.
> "
> Again, specific to forms, issues might include:
>
> *Memory*
>
> - Receptive and Expressive Aphasia may result in impaired short term
> memory which can impact on re-learning language as can the impairment of
> auditory memory for relearning correct articulation *and visual memory
> that affects reading and writing*.
>
> *Reasoning*
>
> - Where intellectual capacity is affected there may be issues with
> reasoning, learning and thus remembering plus abstraction.
>
> *Language*
>
>
> - Aphasia can cause difficulties with word finding, the meanings of
> words and sentences, grammar and comprehension affecting the ability to
> communicate.
>
> *Visual Perception*
>
>
> - Not recognising letters and words impact on reading and even object
> recognition can be affected.
>
> *Knowledge*
>
>
> - Aphasia does not necessarily impact on intelligence but knowledge will
> be trapped within the brain if the individual cannot express their
> thoughts.
>
>
> I'll stop here (there's plenty more research at the referenced W3C URL),
> but suffice to say, based upon the above research, I will respectfully
> suggest
> Jared
> perhaps typed that comment without fully thinking through what
> he was
> saying.
>
>
> It favors the machine over the human, and does so by burdening human
> authors.
>
>
> While I respect that as a concern, how many times do we also here similar
> arguments when it comes to adding aria attributes, or even (
> in the past
> ) alt text? As previously noted, we're aware of this issue, which is why
> we're also continuing to research alternative ways of applying or attaching
> meta-data like this to, not only form inputs, but other critical page
> controls. I previously referred you to this research (*Comparison of ways
> to use vocabulary in content* -
>
> https://github.com/w3c/personalization-semantics/wiki/Comparison-of-ways-to-use-vocabulary-in-content
> ),
>
> which includes
> exploring ways of addressing this need
> , including different methods of applying element level metadata, and
> looking at mechanisms that work with
> lower-level APIs. But yes, today, there is an authoring burden (although,
> because the requirement is to attach one of a fixed number of token values,
> this could be reasonably addressed in WYSIWYG editors via a drop-down or
> similar feature).
>
>
> But the same software that parses autocomplete="family-name" already
> knows that <label>Last Name: <input type="text"></label> is the same
> thing, and thus provides identical functionality when you request help
> in completing this field?
>
>
> Sorry once again my friend, I reject that as a far too Western-centric
> comment. As an example of why I reject your claim, I encourage you to wheel
> on over to here: http://www.sunnlenska.is/frettir/6025.html
> (and yes, there are other accessibility concerns with that page, but for
> the purpose of this discussion, let's just focus on the form)
>
>
> Question, is your "form-filler" able to autocomplete the Form "Senda
> frétt"? (right hand side - there is an icon of an envelope)
>
> In my version of Firefox, despite the fact that the I've added the
> appropriate text strings to support automatically filling in forms (i.e.,
> my email address is remembered, as one example), that form will not be auto
> -
> completed - including the third field which *is* seeking your email address
> (translated here:
>
> https://translate.google.com/translate?hl=en&sl=is&tl=en&u=http%3A%2F%2Fwww.sunnlenska.is%2Ffrettir%2F6025.html
> )
>
> Why?
> B
> ecause nowhere in the source code related to that input is the string
> "email". The heuristics you are relying on to support that statement cannot
> be performed "programmat
> i
> cally", because the 'common' (Western/English-centric) text-string used
> for the heuristics
> is not
> present on this Icelandic-language page
> .
>
>
> ...though recognize that this would rely on authors
> to
> provide an equivalent label text that is "accessibility supported"
> by form fillers (something much more difficult to define than the
> blanket "autocomplete is required").
>
> Let me re-state that slightly differently: "...provide an equivalent TOKEN
> that is "accessibility supported"..."
> , which is effectively what using the @autocomplete attribute delivers. And
> how is that "accessibility supported" requirement achieved? By restricting
> the list of token values to a fixed list, so that the machines can do the
> look-up.
>
> Remember again that WCAG seeks to avoid being overly prescriptive, which is
> why nowhere in the SC does it state "autocomplete is required" - which is
> what some folks are interpreting this SC to mean, but that's a false
> reading of the requirement (which I've previously tried to untangle in this
> thread). The issue is that today, the only "accessibility supported"
> technique available is to use @autocomplete.
>
>
> I have considered the scenario where the input is for entering someone
> else's last name. In this case, autocomplete would not be used, yet
> the form filler would, if activated erroneously, fill it with the
> user's last name.
>
>
> Maybe, maybe not: it all depends on what token string is associated to the
> label in the code. Besides, this SC is scoped to data related to the
> individual user, and not to other potential names.
>
> The form
> fillers already use form labels in their heuristics if autocomplete
> isn't present (and perhaps even if it is). The only way to avoid this
> potential issue is for form fillers to ONLY respect @autocomplete...
>
>
> Jared!!! This SC is NOT (I repeat, *NOT*) about the actual function of
> *filling
> in the fields* (which would have made it an "Operable" SC - aka a 2.x.x
> SC), or even that the Purpose is clear to the end user via on-screen or
> audio labelling (an Understanding SC - aka 3.x.x) - it's about being able
> to "Perceive" what the form input is for - its *Purpose - *and that the
> purpose can be* programmatically determined*. That's it, nothing more than
> that.
>
> It's about facilitating Personalization, an entry-level SC that is leading
> towards a far greater desire for page customizations or Personalizations.
> It is completely about machine understanding - "Programmatic Determination"
> - so that machines can do something with the authored content. Currently,
> one such "doing something" (not necessarily a "purpose" outcome) is the
> auto-completion of those forms (**if** you've stored the correct values,
> *your* name, *your* email, etc. in the local user-agent).
>
> Focusing on that function however completely misses the point of the SC,
> which we should all remember is entitled "*Identify Input Purpose*" and not
> "Facilitate Form Completion". I personally believe the root of confusion in
> this thread is failing to read the title and requirement of the actual SC,
> as too many authors are focusing on a (the?) technique instead.
>
>
> Meanwhile, Jeremy wrote:
>
> With a clearly defined taxonomy, you don't have to build any kind of AI to
> guess at fields, so the programmatic use of these fields is open to a much
> wider audience, which can be useful.
>
> Exactly. One additional constraint we had to deal with was the fact that
> our W3C charter did not permit us to create a new taxonomy, so we had to
> find one that served the purpose. That taxonomy, the "look up table" that
> is the list of tokens and definitions previously defined in HTML5 (as part
> of *that* Working Group's output) met the basic need. It is not an accident
> however that the list is re-published in WCAG, not as "autocomplete values"
> but rather as *Section 7. Input Purposes for User Interface Components* (
> https://www.w3.org/TR/WCAG21/#input-purposes
> ) - also part of the normative spec.
>
> That section further states:
>
> "
>
> *This section contains a listing of common user interface component
> <https://www.w3.org/TR/WCAG21/#dfn-user-interface-components> input
> purposes. The terms below are not keywords that must be used(*), but
> instead represent purposes that must be captured in the taxonomy adopted by
> a webpage. Where applicable, authors mark up controls with the chosen
> taxonomy to indicate the semantic purpose. This provides the potential for
> user agents and assistive technologies to apply personalized presentations
> that can enable more people to understand and use the content."(* although
> that is not forbidden either - JF)*
>
> However, today, the only "accessibility supported" means of attaching those
> purposes is to use the keywords (tokens) and the @autocomplete attribute.
> I've previously linked the ongoing work to find other attributes or
> alternative mechanisms that could also meet this requirement (including
> perhaps minting a new aria-purpose attribute, or by using Microdata, or
> JSON LD, or RDFa, or...). The current problem however is even if we minted
> a new aria-attribute tomorrow (which won't happen, it takes at least 2
> years for things like that to happen at the W3C), we ALSO need to satisfy
> the "accessibility supported" requirement that is also part of WCAG 2.0 and
> 2.1. Because @autocomplete is a valid attribute that shares the same
> taxonomy terms and is accessibility supported today, we were able to
> re-purpose the attribute to attach the metadata, and by using a normative
> attribute that is already being used in the wild today.
>
> That said, "autocomplete" feels very wrong for this purpose.
>
>
> Well, I'd argue not "VERY" wrong, but it is doing some re-purposing that
> may not be 100% clear (as witnessed by this thread). It is (and was) a
> tricky needle to thread, but it meets the need.
>
> I feel like this should be a new attribute, like aria-purpose or something.
>
>
> Like I said, we're working on it
> <
> https://github.com/w3c/personalization-semantics/wiki/Comparison-of-ways-to-use-vocabulary-in-content
> >
> ...
>
> JF
>
>
>
> On Fri, Jul 27, 2018 at 3:43 PM, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
>
> > Jeremy -
> >
> > I absolutely agree. In cases where the purpose of the field is
> > ambiguous, using autocomplete is incredibly helpful and should be
> > required.
> >
> > But the same software that parses autocomplete="family-name" already
> > knows that <label>Last Name: <input type="text"></label> is the same
> > thing, and thus provides identical functionality when you request help
> > in completing this field? Does it then make sense to require authors
> > to add the autocomplete attribute if it provides no better
> > accessibility?
> >
> > I'd think it worthwhile to examine this further as a possible
> > sufficient technique, though recognize that this would rely on authors
> > to provide an equivalent label text that is "accessibility supported"
> > by form fillers (something much more difficult to define than the
> > blanket "autocomplete is required").
> >
> > I have considered the scenario where the input is for entering someone
> > else's last name. In this case, autocomplete would not be used, yet
> > the form filler would, if activated erroneously, fill it with the
> > user's last name. But this is the current reality anyway. The form
> > fillers already use form labels in their heuristics if autocomplete
> > isn't present (and perhaps even if it is). The only way to avoid this
> > potential issue is for form fillers to ONLY respect @autocomplete, and
> > that certainly is not going to happen - they'd stop working on nearly
> > all web forms (including the ones that passed 2.0, but now fail 2.1
> > without having changed).
> >
> > Thanks,
> >
> > Jared
> > > > > > > > > >
>
>
>
> --
> John Foliot
> Principal Accessibility Strategist
> Deque Systems Inc.
> = EMAIL ADDRESS REMOVED =
>
> Advancing the mission of digital accessibility and inclusion
> > > > >

From: Jared Smith
Date: Fri, Jul 27 2018 10:32PM
Subject: Re: WCAG 2.1 - 1.3.5 - How to capture a violation?
← Previous message | Next message →

John Foliot < = EMAIL ADDRESS REMOVED = > wrote:

>> These statements pretty much sum up my disappointment in all of this.
>> WCAG would now demand 100% non-ambiguous perfection for machines in
>> situations where the field purpose is already fully understood by and
>> accessible to end users.
>
> I'm sorry Jared, I fundamentally reject that assertion. You and I both know
> that for many users that is simply not the case - that no web page on the
> internet today is "fully" understood and accessible to all end users.

OK, my use of "fully" was overstating, but now you're just distorting
what I've written. What I'm saying (and you fail to acknowledge) is
that in cases where the software (form filler, icon generator,
translator, personalizationer, or whatever) treats a label of "Last
name" and autocomplete="family-name" EXACTLY the same, then there's no
ADDITIONAL benefit to end users if the required autocomplete attribute
is present. But, as you've repeatedly emphasized, this SC isn't about
end users anyway, so I understand why you dismiss this idea.

> As I've previously noted, many of the use-cases that informed this SC were
> based upon researched conducted and documented by the COGA Task Force.

John, you know that we've conducted a fair amount of research and
testing with users with cognitive and learning disabilities and have
written and published at length on the topic. Our article is the top
Google result for "cognitive disabilities". I don't appreciate your
repeated condescending suggestions that I'm ignorant of this audience
or their needs.

> The heuristics you are relying on to support that statement cannot
> be performed "programmatically", because the 'common' (Western/English-centric) text-string used
> for the heuristics is not
> present on this Icelandic-language page

Sure, though it's a rather obscure example. Because current programs
don't support the Icelandic labels, then autocomplete would certainly
be necessary here. But what of the millions of forms where the
text-string heuristics are already performed "programmatically" - and
no less "programmatically" than @autocomplete?

Additionally, there's little keeping user agents from
"programmatically" supporting new text-strings in any language. You
could contribute the Icelandic label texts from that web page to
LastPass (as one example) right now in a matter of minutes -
https://lastpass.com/trans.php?isocode=is-is&product=chrome&poname=chrome.
Once included, then these fields (and any others on the web with these
labels) would be treated no differently than if @autocomplete were
added to them.

> And how is that "accessibility supported" requirement achieved? By restricting
> the list of token values to a fixed list, so that the machines can do the
> look-up.

Which of the following do you think would be more likely and would
result in more far-reaching accessibility - that we get a handful of
popular browsers and software programs to properly parse additional
common label texts to accurately determine input purpose, or that we
get millions of web authors to add additional, new attributes to the
majority of forms on the web?

Of course the best of both worlds for users with cognitive and
learning disabilities having a more accessible form experience would
be for better label parsing in their software AND for authors to add
@autocomplete when it will improve accessibility for these users.

But you've made it abundantly clear that this success criterion isn't
intended to improve form accessibility for users with disabilities at
all, but "is completely about machine understanding". I'll reluctantly
accept this as the W3C's intent, as short-sighted as I believe it to
be, and will try to help authors understand that autocomplete is
currently required for conformance and to minimize legal risk, even in
cases where it doesn't make any difference for end user accessibility.
But more so, I'll continue to help authors understand the needs of
users with disabilities so they can focus their efforts on things that
actually make a difference.

Jared

From: John Foliot
Date: Sat, Jul 28 2018 2:15AM
Subject: Re: WCAG 2.1 - 1.3.5 - How to capture a violation?
← Previous message | Next message →

Hi Jared,

First, if my tone in my last posting digressed to being offensive, I
apologize to you directly. This discussion has spanned 3 evenings, and it
has been my desire to explain this SC, and to answer clarifying questions
you have posed in a factual, evidence-based discussion. While it is no
excuse, I do apologize if my frustration in still not "getting there"
resulted in my recent snark towards you or your knowledge. You and I have
had a long, collegial, and personal relationship that goes back a long way,
and I do respect and acknowledge the work that you and WebAIM have
contributed to the cause of Web Accessibility over the many years we've
known each other. Sorry man.

***************

What I'm saying (and you fail to acknowledge) is
that in cases where the software (form filler, icon generator,
translator, personalizationer, or whatever) treats a label of "Last
name" and autocomplete="family-name" EXACTLY the same, then there's no
ADDITIONAL benefit to end users if the required autocomplete attribute
is present.

To be clear, I am not dismissing the direct benefit that auto-completed
form inputs provides to end-users.

My concern is that you are not acknowledging that across the myriad of
users-agents and internationalization issues, to meet the *programmatically
determinable* purpose of an input consistently requires a formally
published taxonomy to become a standardized way of delivering this benefit,
as opposed to the current ad-hoc heuristic approach that some tools are
taking. I provided an admittedly arcane example of how the heuristic
approach could fail when the lack of an English token identifier resulted
in the email field on that form for not being auto-filled. This SC seeks to
mitigate that failure risk by mandating a fixed value, derived from a
published taxonomy.

Additionally and importantly, this SC also seeks to re-purpose the taxonomy
originally defined as part of the @autocomplete spec in HTML 5 to do more,
such as page personalization by using those same declared definitions, so
this is about auto-filling AND MORE, which we will be able to do when we
can be assured of that fixed taxonomy is being used.

I've not heard you recognize that this SC will open up those other benefits
(specifically personalization) that the stricter mandate of a fixed
taxonomy will deliver, which was the over-arching goal of this SC in the
first place.


But, as you've repeatedly emphasized, this SC isn't about
end users anyway, so I understand why you dismiss this idea.

If I may, I'll split that. It's not an either / or proposition, but rather
that by standardizing the concepts as token values improves the
effectiveness to deliver on user-benefits (in your example, not hoping that
"*Credit Card*" will suffice, but rather *knowing* that *cc-number* will
ALWAYS work by standards-consuming tools). This SC hardens the requirement
for the fixed taxonomy, so that other tools can deliver the benefits (form
completion and more) consistently.


But what of the millions of forms where the
text-string heuristics are already performed "programmatically" - and
no less "programmatically" than @autocomplete?

OK, I'm hearing that.

This is what WCAG 2.1 normative text says to that concept:


*This section contains a listing of common user interface component input
purposes. The terms below are not keywords that must be used, but instead
represent purposes that must be captured in the taxonomy adopted by a
webpage. Where applicable, authors mark up controls with the chosen
taxonomy to indicate the semantic purpose.*

(source:
https://www.w3.org/TR/WCAG21/#input-purposes
)


One key requirement here is "the taxonomy" that captures the purpose.

If I am to hear your argument, common terms such as Name and Address have
an implied (community) 'taxonomy', at least in English
, and that currently that support for auto-filling the form fields (at
least for English content) is pretty good
. But

I believe
we both agree
this
breaks down when internationalization issues occur.

One reason why the Working Group did not advance this SC with the larger
list of common buttons and controls
<https://docs.google.com/spreadsheets/d/1N63TKXrUXSmF1OeZAgpy8iTnDyQ1nzVbrevq2lBDvos/edit?usp=sharing>
originally proposed was that we lacked a "formal taxonomy" for many of
those common button and control types, even if they too had a "commonly"
understood (community) taxonomic
understanding, for example buttons for "Sign In" and "Sign Out".
We likely all understand those concepts 'heuristically', but they have not
been formally defined in a taxonomy as yet, so we couldn't include them in
this SC.


As such, while I do understand your reasoning, I
believe
the WG has
previously
signaled that a common or community taxonomic understanding did not suffice
for the purposes of this SC
;
that a formal taxonomy was expected
. The attendant
Note
also states:



*The list of input type purposes is based on the control purposes defined
in the HTML 5.2 Autofill field section (*), but it is important to
understand that a different technology may have some or all of the same
concepts defined in its specification and only the concepts that are mapped
to the meanings below are required.*

*(* and not the values in the HTML5 autocomplete specification, even though
today those values are identical - JF)*


N
oting
here
that the concepts are required in a *defined specification*
I believe
further underscores the
mandate
for a formal taxonomy.


Which of the following do you think would be more likely and would
result in more far-reaching accessibility - that we get a handful of
popular browsers and software programs to properly parse additional
common label texts to accurately determine input purpose, or that we
get millions of web authors to add additional, new attributes to the
majority of forms on the web?

As far as goals are concerned, we are on the same page: we want machines (a
handful of popular browsers and software programs) to do the heavy lifting.

I think we're diverging on means and methods (as well as derived outcomes):
you are indicating to me that you believe heuristics will get us there, I
am arguing that a fixed formal taxonomy has a better chance of ensuring we
get there, which was the intention of this SC. (I'll also note that this is
in alignment with the current thinking and work coming from the
Personalization TF, a COGA activity at the W3C:
https://www.w3.org/TR/personalization-semantics-1.0/).


In many ways, the autocomplete attribute emerged at HTML5 for very similar
reasons - the browser vendors at the W3C wanted a standardized means of
delivering on the auto-filling function
,
without having to apply heavy heuristics to account for not only minor
variants in English labeling (your "Credit Card" example) and
also avoiding
essentially the same Internationalization issues that I demonstrated in
that Icelandic page. Sure, heuristics are working relatively well
most of the time
with English content today, but the most efficient means of ensuring this is
will work across the board is
to have a standardized taxonomy
"programmatically determinable"
.

As I see it, those browsers have 2 choices:

-
*to properly parse additional common label texts*

in all it's variants and language permutations
,
browsers and other tools need to either compile a really big list of all
those variants (individually or a shared compiling exercise), or hope for
AI to parse all those variations accurately;

- or publish a list of fixed terms that they will then "promise" to
support.

Computationally, the second choice is far simpler
and faster
for the browsers to do
(and which they did for the @autocomplete attribute - so if current
implementation support from the browsers is any indication, they seem to
prefer fixed lists)
.

So to meet your
and my stated
goal
consistently
, we
would
need to collect all those variants and define them
in a formal taxonomy
, or accept
that
the fixed list that the browsers are already doing something with, which
conceptually align with other goals we seek to achieve
, meets that need
.



...
or that we

get millions of web authors to add additional, new attributes to the

majority of forms on the web?


I am extremely mindful of "attribute creep" in HTML5, and share similar
concerns. I'll note however that the WCAG WG has not defined any attribute
here or elsewhere that I am aware of. That generally happens in other
technical Working Groups within the W3C.

Additionally, at the risk of being pedantic, the preferred technique today
consists of using 1 new (actually "existing" HTML5) attribute coupled with
one of its fixed list of values to a limited set of text inputs. While it
does increase the author lift, I will suggest that the lift is relatively
light overall. As I noted earlier, getting support for this in WYSIWYG
editors (if not already added to some, because it is a HTML5 attribute)
should be fairly easy.


But you've made it abundantly clear that this success criterion isn't
intended to improve form accessibility for users with disabilities at
all, but "is completely about machine understanding".

Well, that's kind of extreme
. As I previously stated, it's not an either / or outcome, but rather by
facilitating the need for the machines to act on the Purpose of the input
in a easy-to-parse way, we can also meet other goals and needs more closely
or directly associated to the actual user, without depending on heuristics
and the risks associated with that.


Of course the best of both worlds for users with cognitive and
learning disabilities having a more accessible form experience would
be for better label parsing in their software AND for authors to add
@autocomplete when it will improve accessibility for these users.

Yup, and this SC increases the likelihood that that we can achieve that
second part: that going forward, authors will explicitly tag their inputs
in such a way that the browsers can get better at parsing consistently.

Since this SC does not (CAN not) mandate "use autocomplete", but rather
"ensure the fixed concepts, formally defined in WCAG 2.1 (Section 7) be
"programmatically determinable" [sic]", the SC leaves the actual method to
the author. Today we have but one 'accessibility supported' method, but the
SC does allow for other mechanisms to co-exist with the @autocomplete
attribute technique (because SC do not mandate techniques). The SC is also
clear that you do not have to use the specific tokens as published in the
WCAG spec but rather that the concepts (defined in the WCAG 2.1 spec), if
mapped to another taxonomy schema, retains the same semantic.


But you've made it abundantly clear that this success criterion isn't
intended to improve form accessibility for users with disabilities at
all,


Jared, that's not fair. The primary intent (but not the sole intent) is for
supporting machines, machines which in turn will be able to support and
improve the accessibility of the end user. The improvement being sought is
greater than just filling out the form; its that we can
also provide "customization" (or
output in
different modalities) to benefit users in other ways - the Personalization
goal - without expecting a heuristic solution to address those other needs.


...and will try to help authors understand that autocomplete is currently
required for conformance and to minimize legal risk...

While in practice today that is the sole technique we can use, it is and
remains factually incorrect to state that adding @autocomplete is required
- it's not.

In plain English
:
the requirement
of this SC
is to tag specific inputs, those inputs that align to the any of the
purposes listed and defined in WCAG 2.1 Section 7, with a programmatically
determinable way of determining the purpose of the input
. Using the @autocomplete technique does just that, with the added benefit
of facilitating the filling of form inputs.

As such, I too will recommend using the @autocomplete Technique, but for
different reasons: attaching a predictable token to the input allows for
user-customization, AND ensures that automated form-filling will work more
robustly and accurately because the value is explicitly declared, versus
deduced via heuristics.

JF

On Fri, Jul 27, 2018 at 11:32 PM, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:

> John Foliot < = EMAIL ADDRESS REMOVED = > wrote:
>
> >> These statements pretty much sum up my disappointment in all of this.
> >> WCAG would now demand 100% non-ambiguous perfection for machines in
> >> situations where the field purpose is already fully understood by and
> >> accessible to end users.
> >
> > I'm sorry Jared, I fundamentally reject that assertion. You and I both
> know
> > that for many users that is simply not the case - that no web page on the
> > internet today is "fully" understood and accessible to all end users.
>
> OK, my use of "fully" was overstating, but now you're just distorting
> what I've written. What I'm saying (and you fail to acknowledge) is
> that in cases where the software (form filler, icon generator,
> translator, personalizationer, or whatever) treats a label of "Last
> name" and autocomplete="family-name" EXACTLY the same, then there's no
> ADDITIONAL benefit to end users if the required autocomplete attribute
> is present. But, as you've repeatedly emphasized, this SC isn't about
> end users anyway, so I understand why you dismiss this idea.
>
> > As I've previously noted, many of the use-cases that informed this SC
> were
> > based upon researched conducted and documented by the COGA Task Force.
>
> John, you know that we've conducted a fair amount of research and
> testing with users with cognitive and learning disabilities and have
> written and published at length on the topic. Our article is the top
> Google result for "cognitive disabilities". I don't appreciate your
> repeated condescending suggestions that I'm ignorant of this audience
> or their needs.
>
> > The heuristics you are relying on to support that statement cannot
> > be performed "programmatically", because the 'common'
> (Western/English-centric) text-string used
> > for the heuristics is not
> > present on this Icelandic-language page
>
> Sure, though it's a rather obscure example. Because current programs
> don't support the Icelandic labels, then autocomplete would certainly
> be necessary here. But what of the millions of forms where the
> text-string heuristics are already performed "programmatically" - and
> no less "programmatically" than @autocomplete?
>
> Additionally, there's little keeping user agents from
> "programmatically" supporting new text-strings in any language. You
> could contribute the Icelandic label texts from that web page to
> LastPass (as one example) right now in a matter of minutes -
> https://lastpass.com/trans.php?isocode=is-is&product=chrome&poname=chrome.
> Once included, then these fields (and any others on the web with these
> labels) would be treated no differently than if @autocomplete were
> added to them.
>
> > And how is that "accessibility supported" requirement achieved? By
> restricting
> > the list of token values to a fixed list, so that the machines can do the
> > look-up.
>
> Which of the following do you think would be more likely and would
> result in more far-reaching accessibility - that we get a handful of
> popular browsers and software programs to properly parse additional
> common label texts to accurately determine input purpose, or that we
> get millions of web authors to add additional, new attributes to the
> majority of forms on the web?
>
> Of course the best of both worlds for users with cognitive and
> learning disabilities having a more accessible form experience would
> be for better label parsing in their software AND for authors to add
> @autocomplete when it will improve accessibility for these users.
>
> But you've made it abundantly clear that this success criterion isn't
> intended to improve form accessibility for users with disabilities at
> all, but "is completely about machine understanding". I'll reluctantly
> accept this as the W3C's intent, as short-sighted as I believe it to
> be, and will try to help authors understand that autocomplete is
> currently required for conformance and to minimize legal risk, even in
> cases where it doesn't make any difference for end user accessibility.
> But more so, I'll continue to help authors understand the needs of
> users with disabilities so they can focus their efforts on things that
> actually make a difference.
>
> Jared
> > > > >



--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
= EMAIL ADDRESS REMOVED =

Advancing the mission of digital accessibility and inclusion

From: Jonathan Avila
Date: Sat, Jul 28 2018 6:34PM
Subject: Re: WCAG 2.1 - 1.3.5 - How to capture a violation?
← Previous message | Next message →

This argument is much like the one for the language attribute. Machines can figure out what language is being used and people know the language of the page and their assistive technology therefore why burden authors with setting a language on every page - that only befits machines.

Or why explicitly set form labels as long as the label precedes the form file AT and users can figure that out. Explicit labels for something that is adjacent is a lot of work with page authors.

These are real arguments that have been made against WCAG 2.0.

Jonathan

Sent from my iPhone

> On Jul 27, 2018, at 10:30 AM, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
>
> John -
>
> Thank you for the detailed explanations. As I promised, I won't
> belabor the discussion about the language further. The fact it's taken
> such a lengthy conversation for you to explain the language and nuance
> of this success criterion to me should hopefully be a good indication
> of how difficult this will be for us to explain to others.
>
>> the goal of this SC is NOT to make forms easier to fill out, but
>> rather for machines to understand
>
>> Please stop thinking of this as a human-consumable requirement,
>> it isn't, it's for machines to do something with.
>
> These statements pretty much sum up my disappointment in all of this.
> WCAG would now demand 100% non-ambiguous perfection for machines in
> situations where the field purpose is already fully understood by and
> accessible to end users. It favors the machine over the human, and
> does so by burdening human authors.
>
> I do hope there will be consideration for a sufficient technique for
> basic forms where informative form labels are used (which, as Jonathan
> noted, is already required by 2.4.6). Every form filler can (or
> readily could) support with very high levels of accuracy the
> identification of input purpose for the majority of forms on the web
> (username/password, basic registration forms, shipping details, etc.).
>
> As an example, I took your example form
> (http://john.foliot.ca/demos/autofill.php) and removed all
> autocomplete attributes. With my form filler, the results were nearly
> identical both with and without the attributes. Without the attributes
> it didn't fill in "sex" (but does work with "gender") and "Telephone:
> Country Code" was filled with country name rather than code - both
> readily fixable with minor improvements to the text parsing in the
> form filler. In short, @autocomplete provided almost no added benefit.
>
> Now I fully understand your argument about fields where the purpose
> may be ambiguous or non-standard, that do not have common, informative
> label values, or are in a language where user agents do not yet
> properly parse the field labels. Certainly autocomplete would be
> useful here. But these are the exception, not the norm. And shouldn't
> the burden here be more on the user agent to support these fields
> rather than the author to add extra code?
>
> Web forms that are currently properly parsed by form fillers (i.e.,
> are "accessibility supported"), are WCAG 2.0 conformant, and are fully
> accessible to end users are now non-conformant with WCAG 2.1 AA
> because they lack an attribute that is intended to tell the machine
> something it has already accurately surmised from the label. To become
> 2.1 conformant the authors of these forms are now required to add code
> that would thus do nothing to improve accessibility for end users.
>
> Thanks,
>
> Jared
> > > >

From: John Foliot
Date: Sun, Jul 29 2018 12:34PM
Subject: Re: WCAG 2.1 - 1.3.5 - How to capture a violation?
← Previous message | Next message →

Hi Jon,

Spot on. In both of your examples, heuristics *could* perhaps make accurate
predictions for end users, whether predicting the language of the page, or
accurately pairing a label to an input... maybe, but also maybe not. (We
can point to YouTube auto-captions as another example where machine
guessing also fails the end user as often as not)

But by being explicit, authors remove any ambiguity, which, as you noted in
reference to the language SC's, is one of the primary goals. The human user
rarely if ever *sees* <html lang="en"> (usually only machines do), but the
benefits derived by that Requirement DOES benefit end-users, and meeting
those SC has proven to be beneficial over-all.

Related to SC 1.3.5, I think much of the confusion is due to the fact that
we are looking to re-purpose a concept that HTML5 originally solved (how to
attach a more granular definition of an input's purpose) to allow us to do
more for the end user: speed the filling of those inputs, yes, but also,
because that more granular purpose is encoded in the code, reliably perform
other functions leading towards page modifications (different modalities)
i.e., Personalization. (For example, using [autocomplete="password"] as a
CSS Selector.)

And while indeed using the autocomplete attribute technique is the
preferred method going forward, the SC language is careful to not prescribe
that, instead requiring the functional outcome of these more granular
definitions be programmatically determinable, while leaving open the
possibility of other techniques to emerge.

JF


On Jul 28, 2018 7:34 PM, "Jonathan Avila" < = EMAIL ADDRESS REMOVED = > wrote:

This argument is much like the one for the language attribute. Machines
can figure out what language is being used and people know the language of
the page and their assistive technology therefore why burden authors with
setting a language on every page - that only befits machines.

Or why explicitly set form labels as long as the label precedes the form
file AT and users can figure that out. Explicit labels for something that
is adjacent is a lot of work with page authors.

These are real arguments that have been made against WCAG 2.0.

Jonathan

Sent from my iPhone

> On Jul 27, 2018, at 10:30 AM, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
>
> John -
>
> Thank you for the detailed explanations. As I promised, I won't
> belabor the discussion about the language further. The fact it's taken
> such a lengthy conversation for you to explain the language and nuance
> of this success criterion to me should hopefully be a good indication
> of how difficult this will be for us to explain to others.
>
>> the goal of this SC is NOT to make forms easier to fill out, but
>> rather for machines to understand
>
>> Please stop thinking of this as a human-consumable requirement,
>> it isn't, it's for machines to do something with.
>
> These statements pretty much sum up my disappointment in all of this.
> WCAG would now demand 100% non-ambiguous perfection for machines in
> situations where the field purpose is already fully understood by and
> accessible to end users. It favors the machine over the human, and
> does so by burdening human authors.
>
> I do hope there will be consideration for a sufficient technique for
> basic forms where informative form labels are used (which, as Jonathan
> noted, is already required by 2.4.6). Every form filler can (or
> readily could) support with very high levels of accuracy the
> identification of input purpose for the majority of forms on the web
> (username/password, basic registration forms, shipping details, etc.).
>
> As an example, I took your example form
> (http://john.foliot.ca/demos/autofill.php) and removed all
> autocomplete attributes. With my form filler, the results were nearly
> identical both with and without the attributes. Without the attributes
> it didn't fill in "sex" (but does work with "gender") and "Telephone:
> Country Code" was filled with country name rather than code - both
> readily fixable with minor improvements to the text parsing in the
> form filler. In short, @autocomplete provided almost no added benefit.
>
> Now I fully understand your argument about fields where the purpose
> may be ambiguous or non-standard, that do not have common, informative
> label values, or are in a language where user agents do not yet
> properly parse the field labels. Certainly autocomplete would be
> useful here. But these are the exception, not the norm. And shouldn't
> the burden here be more on the user agent to support these fields
> rather than the author to add extra code?
>
> Web forms that are currently properly parsed by form fillers (i.e.,
> are "accessibility supported"), are WCAG 2.0 conformant, and are fully
> accessible to end users are now non-conformant with WCAG 2.1 AA
> because they lack an attribute that is intended to tell the machine
> something it has already accurately surmised from the label. To become
> 2.1 conformant the authors of these forms are now required to add code
> that would thus do nothing to improve accessibility for end users.
>
> Thanks,
>
> Jared
> > > >

From: Jared Smith
Date: Sun, Jul 29 2018 5:34PM
Subject: Re: WCAG 2.1 - 1.3.5 - How to capture a violation?
← Previous message | Next message →

Jon and John -

I agree with both of you. Your explanations have helped me better see
how this will be useful for accessibility in the future and why it
should be advocated for today. I do still find the language of the
success criterion a bit troublesome and I think it could be a bit of a
hard sell to authors in cases where they can't associate adding
@autocomplete with any clear user benefit *today*, but perhaps there
will soon be new or better assistive technologies that will further
utilize this to greatly improve form completion for users with
cognitive and learning disabilities.

Thanks,

Jared

From: John Foliot
Date: Sun, Jul 29 2018 6:29PM
Subject: Re: WCAG 2.1 - 1.3.5 - How to capture a violation?
← Previous message | Next message →

Hi Jared,

You've hit the problem nail directly on the head: accessibility supported.

One challenge we faced, and the reason this SC was skinnied down to JUST
form inputs (and not the other controls and components originally sought,
and noted in the spreadsheet I shared previously) was exactly this
chicken-and-egg problem: we lacked tools that could parse and act on
element level meta-data, because there is very little element level
meta-data out there to act upon. While limited in scope, @autocomplete was
the exception there, and met both the higher-level technical requirements
(a built-for-purpose attribute AND a defined taxonomy), while also
materially providing a concrete benefit to users today.

We faced a similar problem with ARIA in the earliest days: why add ARIA
attributes to your code if no tools were doing anything with it? And why
build ARIA-aware tools if there was no ARIA content to act on? If IBM (with
the foresight of Rich Schwerdtfeger) had not hired Aaron Leventhal to get
ARIA support embedded in Firefox, we'd likely have the same problem today
with ARIA.

At this time, while the corpus of web content explicitly using
@autocomplete is but a small percentage of web content in the wild, there
IS a significant enough body already, so that future tools now have content
to act upon. SC 1.3.5 will help increase the amount of forms out there
tagged with this meta-data, and by using the attribute and values as
designed by HTML5 now, it also has at least one direct benefit in browsers
today.

Hopefully companies and accessibility-aware hackers both will seize on this
opportunity to use the element level meta-data for other purposes that
benefit users. I expect (hope) to start to see browser extensions
prototyping different types of Personalization examples in the near future.
(Hint: this might be an interesting challenge for a hackathon.)

JF




On Sun, Jul 29, 2018, 6:35 PM Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:

> Jon and John -
>
> I agree with both of you. Your explanations have helped me better see
> how this will be useful for accessibility in the future and why it
> should be advocated for today. I do still find the language of the
> success criterion a bit troublesome and I think it could be a bit of a
> hard sell to authors in cases where they can't associate adding
> @autocomplete with any clear user benefit *today*, but perhaps there
> will soon be new or better assistive technologies that will further
> utilize this to greatly improve form completion for users with
> cognitive and learning disabilities.
>
> Thanks,
>
> Jared
> > > > >

From: Joseph Sherman
Date: Mon, Jul 30 2018 10:39AM
Subject: Re: (Title element) WAS WCAG 2.1 - 1.3.5 - How to capture a violation?
← Previous message | Next message →

I saw the exchange, that the Title element is no longer part of the accessible name calculation. We have been using the following code for some font icons- the plug in we are using allows only the addition of the Title element to the font icons repository. Manually adding labels for every use of the font icons is impractical, as most folks adding the icons are not code savvy, they just use the WYSWYG editor.

<a class="ts-font-icons-link " href="http://*/news/rss.html" target="_blank" title="RSS Feed"><i class="ts-font-icon icon-rss_ko" style="background-color:#ffffff; width: auto; height: auto; font-size: 31px; line-height: 100%;color:#353a3d;"></i></a>

Wouldn't it have be better to add the Title element to AT instead of removing it from the Specification?

Joseph

From: Birkir R. Gunnarsson
Date: Mon, Jul 30 2018 11:40AM
Subject: Re: (Title element) WAS WCAG 2.1 - 1.3.5 - How to capture a violation?
← Previous message | Next message →

Agreed.
For clarity, we are talking about the title attribute, not the title element.

The Accessible name calculation algorithm has allowed use of the title
attribute as a source of accessible name for years.
It is accessible to more people than aria-label, which is purely a
screen reader solution, without CSS or JavaScript custom
implementation.
For focusable element the title attribute is supported as a source of
accessible name by the vast majority of common browser and screen
reader combinations.

Removing a valid source of accessible name from the accessible name
algorithm that has been stable and used for years, on thousands of
pages, needs a pretty strong justification in my opinion.
It creates a lot of work and makes accessibility standards less
credible and robust.
Imagine recommending the use of a certain HTmL or ARIA attribute
because it solves a problem and it is a valid technique listed in a
standard.
If there is precedent that such attributes are removed from the
standard down the road, a product owner is not going to allocate
deverloper time to add this attribute.

Assistive technology support is not a valid reason , as far as I know,
so what is?


On 7/30/18, Joseph Sherman < = EMAIL ADDRESS REMOVED = > wrote:
> I saw the exchange, that the Title element is no longer part of the
> accessible name calculation. We have been using the following code for some
> font icons- the plug in we are using allows only the addition of the Title
> element to the font icons repository. Manually adding labels for every use
> of the font icons is impractical, as most folks adding the icons are not
> code savvy, they just use the WYSWYG editor.
>
> <a class="ts-font-icons-link " href="http://*/news/rss.html" target="_blank"
> title="RSS Feed"><i class="ts-font-icon icon-rss_ko"
> style="background-color:#ffffff; width: auto; height: auto; font-size: 31px;
> line-height: 100%;color:#353a3d;"></i></a>
>
> Wouldn't it have be better to add the Title element to AT instead of
> removing it from the Specification?
>
> Joseph
>
>
>

From: John Foliot
Date: Mon, Jul 30 2018 1:36PM
Subject: Re: (Title element) WAS WCAG 2.1 - 1.3.5 - How to capture a violation?
← Previous message | Next message →

So... I may have been wrong there...

There are multiple documents now at the W3C related to name-calculation, so
that is a problem as well as a source of confusion.

Further reading and research suggests that ARIA 1.1 no longer references
the @title attribute directly, but the *HTML Accessibility API Mappings 1.0*
Recommendation *does* (
https://www.w3.org/TR/html-aam-1.0/#input-type-text-input-type-password-input-type-search-input-type-tel-input-type-url-and-textarea-element),
as does the *Accessible Name and Description Computation 1.1*
Recommendation (
https://www.w3.org/TR/accname-1.1/).

*The ARIA 1.1 *spec says this about @title:

(The accessible)
name comes from values provided by the author in explicit markup features
such as the aria-label
<https://www.w3.org/TR/wai-aria-1.1/#aria-label> attribute,
the aria-labelledby
<https://www.w3.org/TR/wai-aria-1.1/#aria-labelledby> attribute,
or the host language labeling mechanism, such as the alt or title attributes
in HTML, with HTML title attribute having the lowest precedence for
specifying a text alternative.


So I mis-spoke, and apologize for adding confusion. It was late, I was
discussing a different topic, and didn't give enough research to that point.

JF

On Mon, Jul 30, 2018 at 12:40 PM, Birkir R. Gunnarsson <
= EMAIL ADDRESS REMOVED = > wrote:

> Agreed.
> For clarity, we are talking about the title attribute, not the title
> element.
>
> The Accessible name calculation algorithm has allowed use of the title
> attribute as a source of accessible name for years.
> It is accessible to more people than aria-label, which is purely a
> screen reader solution, without CSS or JavaScript custom
> implementation.
> For focusable element the title attribute is supported as a source of
> accessible name by the vast majority of common browser and screen
> reader combinations.
>
> Removing a valid source of accessible name from the accessible name
> algorithm that has been stable and used for years, on thousands of
> pages, needs a pretty strong justification in my opinion.
> It creates a lot of work and makes accessibility standards less
> credible and robust.
> Imagine recommending the use of a certain HTmL or ARIA attribute
> because it solves a problem and it is a valid technique listed in a
> standard.
> If there is precedent that such attributes are removed from the
> standard down the road, a product owner is not going to allocate
> deverloper time to add this attribute.
>
> Assistive technology support is not a valid reason , as far as I know,
> so what is?
>
>
> On 7/30/18, Joseph Sherman < = EMAIL ADDRESS REMOVED = > wrote:
> > I saw the exchange, that the Title element is no longer part of the
> > accessible name calculation. We have been using the following code for
> some
> > font icons- the plug in we are using allows only the addition of the
> Title
> > element to the font icons repository. Manually adding labels for every
> use
> > of the font icons is impractical, as most folks adding the icons are not
> > code savvy, they just use the WYSWYG editor.
> >
> > <a class="ts-font-icons-link " href="http://*/news/rss.html"
> target="_blank"
> > title="RSS Feed"><i class="ts-font-icon icon-rss_ko"
> > style="background-color:#ffffff; width: auto; height: auto; font-size:
> 31px;
> > line-height: 100%;color:#353a3d;"></i></a>
> >
> > Wouldn't it have be better to add the Title element to AT instead of
> > removing it from the Specification?
> >
> > Joseph
> >
> >
> >

From: Birkir R. Gunnarsson
Date: Mon, Jul 30 2018 1:47PM
Subject: Re: (Title element) WAS WCAG 2.1 - 1.3.5 - How to capture a violation?
← Previous message | Next message →

Hey John
I thought it was a mistake, and nobody will balme you for getting this
thing wrong with the thorough and detailed explanation you were
providing on a different topic (that explanation has been duely saved
to my favorites and given a write up in my accessibility guide related
to WCAG 2.1).
NO problem, glad this was a minor mistake of yours and not a
substantive change in the W3C specifications.


On 7/30/18, John Foliot < = EMAIL ADDRESS REMOVED = > wrote:
> So... I may have been wrong there...
>
> There are multiple documents now at the W3C related to name-calculation, so
> that is a problem as well as a source of confusion.
>
> Further reading and research suggests that ARIA 1.1 no longer references
> the @title attribute directly, but the *HTML Accessibility API Mappings
> 1.0*
> Recommendation *does* (
> https://www.w3.org/TR/html-aam-1.0/#input-type-text-input-type-password-input-type-search-input-type-tel-input-type-url-and-textarea-element),
> as does the *Accessible Name and Description Computation 1.1*
> Recommendation (
> https://www.w3.org/TR/accname-1.1/).
>
> *The ARIA 1.1 *spec says this about @title:
>
> (The accessible)
> name comes from values provided by the author in explicit markup features
> such as the aria-label
> <https://www.w3.org/TR/wai-aria-1.1/#aria-label> attribute,
> the aria-labelledby
> <https://www.w3.org/TR/wai-aria-1.1/#aria-labelledby> attribute,
> or the host language labeling mechanism, such as the alt or title
> attributes
> in HTML, with HTML title attribute having the lowest precedence for
> specifying a text alternative.
>
>
> So I mis-spoke, and apologize for adding confusion. It was late, I was
> discussing a different topic, and didn't give enough research to that
> point.
>
> JF
>
> On Mon, Jul 30, 2018 at 12:40 PM, Birkir R. Gunnarsson <
> = EMAIL ADDRESS REMOVED = > wrote:
>
>> Agreed.
>> For clarity, we are talking about the title attribute, not the title
>> element.
>>
>> The Accessible name calculation algorithm has allowed use of the title
>> attribute as a source of accessible name for years.
>> It is accessible to more people than aria-label, which is purely a
>> screen reader solution, without CSS or JavaScript custom
>> implementation.
>> For focusable element the title attribute is supported as a source of
>> accessible name by the vast majority of common browser and screen
>> reader combinations.
>>
>> Removing a valid source of accessible name from the accessible name
>> algorithm that has been stable and used for years, on thousands of
>> pages, needs a pretty strong justification in my opinion.
>> It creates a lot of work and makes accessibility standards less
>> credible and robust.
>> Imagine recommending the use of a certain HTmL or ARIA attribute
>> because it solves a problem and it is a valid technique listed in a
>> standard.
>> If there is precedent that such attributes are removed from the
>> standard down the road, a product owner is not going to allocate
>> deverloper time to add this attribute.
>>
>> Assistive technology support is not a valid reason , as far as I know,
>> so what is?
>>
>>
>> On 7/30/18, Joseph Sherman < = EMAIL ADDRESS REMOVED = > wrote:
>> > I saw the exchange, that the Title element is no longer part of the
>> > accessible name calculation. We have been using the following code for
>> some
>> > font icons- the plug in we are using allows only the addition of the
>> Title
>> > element to the font icons repository. Manually adding labels for every
>> use
>> > of the font icons is impractical, as most folks adding the icons are
>> > not
>> > code savvy, they just use the WYSWYG editor.
>> >
>> > <a class="ts-font-icons-link " href="http://*/news/rss.html"
>> target="_blank"
>> > title="RSS Feed"><i class="ts-font-icon icon-rss_ko"
>> > style="background-color:#ffffff; width: auto; height: auto; font-size:
>> 31px;
>> > line-height: 100%;color:#353a3d;"></i></a>
>> >
>> > Wouldn't it have be better to add the Title element to AT instead of
>> > removing it from the Specification?
>> >
>> > Joseph
>> >
>> >
>> >

From: John Foliot
Date: Mon, Jul 30 2018 2:19PM
Subject: Re: (Title element) WAS WCAG 2.1 - 1.3.5 - How to capture a violation?
← Previous message | Next message →

Thanks Birkir,

I am a tad concerned however that the original link I provided (Text
Alternative Computation:
https://www.w3.org/TR/accname-1.1/#mapping_additional_nd_te) did support my
claim, but then going back and looking at other specs I realized the error,
so it seems there may be a mis-sync within the group of specifications all
related to this topic (accessible name calculation). I plan on raising it
with the ARIA WG.

From a practical perspective, I've long recommended that @title was not
providing the accessible name consistently (certainly not for images), and
so that technique should be avoided, but it seems that it still would meet
the technical (legal) requirement. The third point of my 3-part answer is
still accurate AFAIK

JF

On Mon, Jul 30, 2018 at 2:47 PM, Birkir R. Gunnarsson <
= EMAIL ADDRESS REMOVED = > wrote:

> Hey John
> I thought it was a mistake, and nobody will balme you for getting this
> thing wrong with the thorough and detailed explanation you were
> providing on a different topic (that explanation has been duely saved
> to my favorites and given a write up in my accessibility guide related
> to WCAG 2.1).
> NO problem, glad this was a minor mistake of yours and not a
> substantive change in the W3C specifications.
>
>
> On 7/30/18, John Foliot < = EMAIL ADDRESS REMOVED = > wrote:
> > So... I may have been wrong there...
> >
> > There are multiple documents now at the W3C related to name-calculation,
> so
> > that is a problem as well as a source of confusion.
> >
> > Further reading and research suggests that ARIA 1.1 no longer references
> > the @title attribute directly, but the *HTML Accessibility API Mappings
> > 1.0*
> > Recommendation *does* (
> > https://www.w3.org/TR/html-aam-1.0/#input-type-text-
> input-type-password-input-type-search-input-type-tel-
> input-type-url-and-textarea-element),
> > as does the *Accessible Name and Description Computation 1.1*
> > Recommendation (
> > https://www.w3.org/TR/accname-1.1/).
> >
> > *The ARIA 1.1 *spec says this about @title:
> >
> > (The accessible)
> > name comes from values provided by the author in explicit markup features
> > such as the aria-label
> > <https://www.w3.org/TR/wai-aria-1.1/#aria-label> attribute,
> > the aria-labelledby
> > <https://www.w3.org/TR/wai-aria-1.1/#aria-labelledby> attribute,
> > or the host language labeling mechanism, such as the alt or title
> > attributes
> > in HTML, with HTML title attribute having the lowest precedence for
> > specifying a text alternative.
> >
> >
> > So I mis-spoke, and apologize for adding confusion. It was late, I was
> > discussing a different topic, and didn't give enough research to that
> > point.
> >
> > JF
> >
> > On Mon, Jul 30, 2018 at 12:40 PM, Birkir R. Gunnarsson <
> > = EMAIL ADDRESS REMOVED = > wrote:
> >
> >> Agreed.
> >> For clarity, we are talking about the title attribute, not the title
> >> element.
> >>
> >> The Accessible name calculation algorithm has allowed use of the title
> >> attribute as a source of accessible name for years.
> >> It is accessible to more people than aria-label, which is purely a
> >> screen reader solution, without CSS or JavaScript custom
> >> implementation.
> >> For focusable element the title attribute is supported as a source of
> >> accessible name by the vast majority of common browser and screen
> >> reader combinations.
> >>
> >> Removing a valid source of accessible name from the accessible name
> >> algorithm that has been stable and used for years, on thousands of
> >> pages, needs a pretty strong justification in my opinion.
> >> It creates a lot of work and makes accessibility standards less
> >> credible and robust.
> >> Imagine recommending the use of a certain HTmL or ARIA attribute
> >> because it solves a problem and it is a valid technique listed in a
> >> standard.
> >> If there is precedent that such attributes are removed from the
> >> standard down the road, a product owner is not going to allocate
> >> deverloper time to add this attribute.
> >>
> >> Assistive technology support is not a valid reason , as far as I know,
> >> so what is?
> >>
> >>
> >> On 7/30/18, Joseph Sherman < = EMAIL ADDRESS REMOVED = > wrote:
> >> > I saw the exchange, that the Title element is no longer part of the
> >> > accessible name calculation. We have been using the following code for
> >> some
> >> > font icons- the plug in we are using allows only the addition of the
> >> Title
> >> > element to the font icons repository. Manually adding labels for every
> >> use
> >> > of the font icons is impractical, as most folks adding the icons are
> >> > not
> >> > code savvy, they just use the WYSWYG editor.
> >> >
> >> > <a class="ts-font-icons-link " href="http://*/news/rss.html"
> >> target="_blank"
> >> > title="RSS Feed"><i class="ts-font-icon icon-rss_ko"
> >> > style="background-color:#ffffff; width: auto; height: auto;
> font-size:
> >> 31px;
> >> > line-height: 100%;color:#353a3d;"></i></a>
> >> >
> >> > Wouldn't it have be better to add the Title element to AT instead of
> >> > removing it from the Specification?
> >> >
> >> > Joseph
> >> >
> >> >
> >> >

From: Jonathan Avila
Date: Mon, Jul 30 2018 6:39PM
Subject: Re: (Title element) WAS WCAG 2.1 - 1.3.5 - How to capture a violation?
← Previous message | Next message →

I would oppose changes to drop the title attribute from being used for type input text and other form field name calculations. While it may not be preferred it has and continues to have widespread support and may be needed with certain CMS and legacy systems that don't support aria additions.

Last I looked it was still listed.

Jonathan

Sent from my iPhone

> On Jul 30, 2018, at 4:19 PM, John Foliot < = EMAIL ADDRESS REMOVED = > wrote:
>
> Thanks Birkir,
>
> I am a tad concerned however that the original link I provided (Text
> Alternative Computation:
> https://www.w3.org/TR/accname-1.1/#mapping_additional_nd_te) did support my
> claim, but then going back and looking at other specs I realized the error,
> so it seems there may be a mis-sync within the group of specifications all
> related to this topic (accessible name calculation). I plan on raising it
> with the ARIA WG.
>
> From a practical perspective, I've long recommended that @title was not
> providing the accessible name consistently (certainly not for images), and
> so that technique should be avoided, but it seems that it still would meet
> the technical (legal) requirement. The third point of my 3-part answer is
> still accurate AFAIK
>
> JF
>
> On Mon, Jul 30, 2018 at 2:47 PM, Birkir R. Gunnarsson <
> = EMAIL ADDRESS REMOVED = > wrote:
>
>> Hey John
>> I thought it was a mistake, and nobody will balme you for getting this
>> thing wrong with the thorough and detailed explanation you were
>> providing on a different topic (that explanation has been duely saved
>> to my favorites and given a write up in my accessibility guide related
>> to WCAG 2.1).
>> NO problem, glad this was a minor mistake of yours and not a
>> substantive change in the W3C specifications.
>>
>>
>>> On 7/30/18, John Foliot < = EMAIL ADDRESS REMOVED = > wrote:
>>> So... I may have been wrong there...
>>>
>>> There are multiple documents now at the W3C related to name-calculation,
>> so
>>> that is a problem as well as a source of confusion.
>>>
>>> Further reading and research suggests that ARIA 1.1 no longer references
>>> the @title attribute directly, but the *HTML Accessibility API Mappings
>>> 1.0*
>>> Recommendation *does* (
>>> https://www.w3.org/TR/html-aam-1.0/#input-type-text-
>> input-type-password-input-type-search-input-type-tel-
>> input-type-url-and-textarea-element),
>>> as does the *Accessible Name and Description Computation 1.1*
>>> Recommendation (
>>> https://www.w3.org/TR/accname-1.1/).
>>>
>>> *The ARIA 1.1 *spec says this about @title:
>>>
>>> (The accessible)
>>> name comes from values provided by the author in explicit markup features
>>> such as the aria-label
>>> <https://www.w3.org/TR/wai-aria-1.1/#aria-label> attribute,
>>> the aria-labelledby
>>> <https://www.w3.org/TR/wai-aria-1.1/#aria-labelledby> attribute,
>>> or the host language labeling mechanism, such as the alt or title
>>> attributes
>>> in HTML, with HTML title attribute having the lowest precedence for
>>> specifying a text alternative.
>>>
>>>
>>> So I mis-spoke, and apologize for adding confusion. It was late, I was
>>> discussing a different topic, and didn't give enough research to that
>>> point.
>>>
>>> JF
>>>
>>> On Mon, Jul 30, 2018 at 12:40 PM, Birkir R. Gunnarsson <
>>> = EMAIL ADDRESS REMOVED = > wrote:
>>>
>>>> Agreed.
>>>> For clarity, we are talking about the title attribute, not the title
>>>> element.
>>>>
>>>> The Accessible name calculation algorithm has allowed use of the title
>>>> attribute as a source of accessible name for years.
>>>> It is accessible to more people than aria-label, which is purely a
>>>> screen reader solution, without CSS or JavaScript custom
>>>> implementation.
>>>> For focusable element the title attribute is supported as a source of
>>>> accessible name by the vast majority of common browser and screen
>>>> reader combinations.
>>>>
>>>> Removing a valid source of accessible name from the accessible name
>>>> algorithm that has been stable and used for years, on thousands of
>>>> pages, needs a pretty strong justification in my opinion.
>>>> It creates a lot of work and makes accessibility standards less
>>>> credible and robust.
>>>> Imagine recommending the use of a certain HTmL or ARIA attribute
>>>> because it solves a problem and it is a valid technique listed in a
>>>> standard.
>>>> If there is precedent that such attributes are removed from the
>>>> standard down the road, a product owner is not going to allocate
>>>> deverloper time to add this attribute.
>>>>
>>>> Assistive technology support is not a valid reason , as far as I know,
>>>> so what is?
>>>>
>>>>
>>>>> On 7/30/18, Joseph Sherman < = EMAIL ADDRESS REMOVED = > wrote:
>>>>> I saw the exchange, that the Title element is no longer part of the
>>>>> accessible name calculation. We have been using the following code for
>>>> some
>>>>> font icons- the plug in we are using allows only the addition of the
>>>> Title
>>>>> element to the font icons repository. Manually adding labels for every
>>>> use
>>>>> of the font icons is impractical, as most folks adding the icons are
>>>>> not
>>>>> code savvy, they just use the WYSWYG editor.
>>>>>
>>>>> <a class="ts-font-icons-link " href="http://*/news/rss.html"
>>>> target="_blank"
>>>>> title="RSS Feed"><i class="ts-font-icon icon-rss_ko"
>>>>> style="background-color:#ffffff; width: auto; height: auto;
>> font-size:
>>>> 31px;
>>>>> line-height: 100%;color:#353a3d;"></i></a>
>>>>>
>>>>> Wouldn't it have be better to add the Title element to AT instead of
>>>>> removing it from the Specification?
>>>>>
>>>>> Joseph
>>>>>
>>>>>
>>>>>

From: Fischer, Johannes
Date: Tue, Jul 31 2018 12:22AM
Subject: Re: (Title element) WAS WCAG 2.1 - 1.3.5 - How to capture a violation?
← Previous message | Next message →

Is the title attribute really not in the Accessible Name Calculation anymore? I think, it's still contained as last resort, look here: https://www.w3.org/TR/accname-1.1/#step2I
Letter I says: "Otherwise, if the current node has a Tooltip attribute, return its value".

When you click on "Tooltip attribute", you get the following definition: "Any host language attribute that would result in a user agent generating a tooltip such as in response to a mouse hover in desktop user agents."
In my opinion this is in the host language HTML the title attribute, because user agents generate a tooltip of this.

What else should letter I be about if not the title attribute?
Johannes

Von: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > im Auftrag von Jonathan Avila < = EMAIL ADDRESS REMOVED = >
Gesendet: Dienstag, 31. Juli 2018 02:39
An: WebAIM Discussion List
Betreff: Re: [WebAIM] (Title element) WAS WCAG 2.1 - 1.3.5 - How to capture a violation?

I would oppose changes to drop the title attribute from being used for type input text and other form field name calculations. While it may not be preferred it has and continues to have widespread support and may be needed with certain CMS and legacy systems that don’t support aria additions.

Last I looked it was still listed.

Jonathan

Sent from my iPhone

> On Jul 30, 2018, at 4:19 PM, John Foliot < = EMAIL ADDRESS REMOVED = > wrote:
>
> Thanks Birkir,
>
> I am a tad concerned however that the original link I provided (Text
> Alternative Computation:
> https://www.w3.org/TR/accname-1.1/#mapping_additional_nd_te) did support my
> claim, but then going back and looking at other specs I realized the error,
> so it seems there may be a mis-sync within the group of specifications all
> related to this topic (accessible name calculation). I plan on raising it
> with the ARIA WG.
>
> From a practical perspective, I've long recommended that @title was not
> providing the accessible name consistently (certainly not for images), and
> so that technique should be avoided, but it seems that it still would meet
> the technical (legal) requirement. The third point of my 3-part answer is
> still accurate AFAIK
>
> JF
>
> On Mon, Jul 30, 2018 at 2:47 PM, Birkir R. Gunnarsson <
> = EMAIL ADDRESS REMOVED = > wrote:
>
>> Hey John
>> I thought it was a mistake, and nobody will balme you for getting this
>> thing wrong with the thorough and detailed explanation you were
>> providing on a different topic (that explanation has been duely saved
>> to my favorites and given a write up in my accessibility guide related
>> to WCAG 2.1).
>> NO problem, glad this was a minor mistake of yours and not a
>> substantive change in the W3C specifications.
>>
>>
>>> On 7/30/18, John Foliot < = EMAIL ADDRESS REMOVED = > wrote:
>>> So... I may have been wrong there...
>>>
>>> There are multiple documents now at the W3C related to name-calculation,
>> so
>>> that is a problem as well as a source of confusion.
>>>
>>> Further reading and research suggests that ARIA 1.1 no longer references
>>> the @title attribute directly, but the *HTML Accessibility API Mappings
>>> 1.0*
>>> Recommendation *does* (
>>> https://www.w3.org/TR/html-aam-1.0/#input-type-text-
>> input-type-password-input-type-search-input-type-tel-
>> input-type-url-and-textarea-element),
>>> as does the *Accessible Name and Description Computation 1.1*
>>> Recommendation (
>>> https://www.w3.org/TR/accname-1.1/).
>>>
>>> *The ARIA 1.1 *spec says this about @title:
>>>
>>> (The accessible)
>>> name comes from values provided by the author in explicit markup features
>>> such as the aria-label
>>> <https://www.w3.org/TR/wai-aria-1.1/#aria-label> attribute,
>>> the aria-labelledby
>>> <https://www.w3.org/TR/wai-aria-1.1/#aria-labelledby> attribute,
>>> or the host language labeling mechanism, such as the alt or title
>>> attributes
>>> in HTML, with HTML title attribute having the lowest precedence for
>>> specifying a text alternative.
>>>
>>>
>>> So I mis-spoke, and apologize for adding confusion. It was late, I was
>>> discussing a different topic, and didn't give enough research to that
>>> point.
>>>
>>> JF
>>>
>>> On Mon, Jul 30, 2018 at 12:40 PM, Birkir R. Gunnarsson <
>>> = EMAIL ADDRESS REMOVED = > wrote:
>>>
>>>> Agreed.
>>>> For clarity, we are talking about the title attribute, not the title
>>>> element.
>>>>
>>>> The Accessible name calculation algorithm has allowed use of the title
>>>> attribute as a source of accessible name for years.
>>>> It is accessible to more people than aria-label, which is purely a
>>>> screen reader solution, without CSS or JavaScript custom
>>>> implementation.
>>>> For focusable element the title attribute is supported as a source of
>>>> accessible name by the vast majority of common browser and screen
>>>> reader combinations.
>>>>
>>>> Removing a valid source of accessible name from the accessible name
>>>> algorithm that has been stable and used for years, on thousands of
>>>> pages, needs a pretty strong justification in my opinion.
>>>> It creates a lot of work and makes accessibility standards less
>>>> credible and robust.
>>>> Imagine recommending the use of a certain HTmL or ARIA attribute
>>>> because it solves a problem and it is a valid technique listed in a
>>>> standard.
>>>> If there is precedent that such attributes are removed from the
>>>> standard down the road, a product owner is not going to allocate
>>>> deverloper time to add this attribute.
>>>>
>>>> Assistive technology support is not a valid reason , as far as I know,
>>>> so what is?
>>>>
>>>>
>>>>> On 7/30/18, Joseph Sherman < = EMAIL ADDRESS REMOVED = > wrote:
>>>>> I saw the exchange, that the Title element is no longer part of the
>>>>> accessible name calculation. We have been using the following code for
>>>> some
>>>>> font icons- the plug in we are using allows only the addition of the
>>>> Title
>>>>> element to the font icons repository. Manually adding labels for every
>>>> use
>>>>> of the font icons is impractical, as most folks adding the icons are
>>>>> not
>>>>> code savvy, they just use the WYSWYG editor.
>>>>>
>>>>> <a class="ts-font-icons-link " href="http://*/news/rss.html"
>>>> target="_blank"
>>>>> title="RSS Feed"><i class="ts-font-icon icon-rss_ko"
>>>>> style="background-color:#ffffff; width: auto; height: auto;
>> font-size:
>>>> 31px;
>>>>> line-height: 100%;color:#353a3d;"></i></a>
>>>>>
>>>>> Wouldn't it have be better to add the Title element to AT instead of
>>>>> removing it from the Specification?
>>>>>
>>>>> Joseph
>>>>>
>>>>>
>>>>>

From: John Foliot
Date: Tue, Jul 31 2018 6:38AM
Subject: Re: (Title element) WAS WCAG 2.1 - 1.3.5 - How to capture a violation?
← Previous message | No next message

Johannes,

Please see my earlier response.

JF

On Tue, Jul 31, 2018 at 1:22 AM, Fischer, Johannes < = EMAIL ADDRESS REMOVED = >
wrote:

> Is the title attribute really not in the Accessible Name Calculation
> anymore? I think, it's still contained as last resort, look here:
> https://www.w3.org/TR/accname-1.1/#step2I
> Letter I says: "Otherwise, if the current node has a Tooltip attribute,
> return its value".
>
> When you click on "Tooltip attribute", you get the following definition:
> "Any host language attribute that would result in a user agent generating a
> tooltip such as in response to a mouse hover in desktop user agents."
> In my opinion this is in the host language HTML the title attribute,
> because user agents generate a tooltip of this.
>
> What else should letter I be about if not the title attribute?
> Johannes
>
> > Von: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > im Auftrag von
> Jonathan Avila < = EMAIL ADDRESS REMOVED = >
> Gesendet: Dienstag, 31. Juli 2018 02:39
> An: WebAIM Discussion List
> Betreff: Re: [WebAIM] (Title element) WAS WCAG 2.1 - 1.3.5 - How to
> capture a violation?
>
> I would oppose changes to drop the title attribute from being used for
> type input text and other form field name calculations. While it may not
> be preferred it has and continues to have widespread support and may be
> needed with certain CMS and legacy systems that don't support aria
> additions.
>
> Last I looked it was still listed.
>
> Jonathan
>
> Sent from my iPhone
>
> > On Jul 30, 2018, at 4:19 PM, John Foliot < = EMAIL ADDRESS REMOVED = > wrote:
> >
> > Thanks Birkir,
> >
> > I am a tad concerned however that the original link I provided (Text
> > Alternative Computation:
> > https://www.w3.org/TR/accname-1.1/#mapping_additional_nd_te) did
> support my
> > claim, but then going back and looking at other specs I realized the
> error,
> > so it seems there may be a mis-sync within the group of specifications
> all
> > related to this topic (accessible name calculation). I plan on raising it
> > with the ARIA WG.
> >
> > From a practical perspective, I've long recommended that @title was not
> > providing the accessible name consistently (certainly not for images),
> and
> > so that technique should be avoided, but it seems that it still would
> meet
> > the technical (legal) requirement. The third point of my 3-part answer is
> > still accurate AFAIK
> >
> > JF
> >
> > On Mon, Jul 30, 2018 at 2:47 PM, Birkir R. Gunnarsson <
> > = EMAIL ADDRESS REMOVED = > wrote:
> >
> >> Hey John
> >> I thought it was a mistake, and nobody will balme you for getting this
> >> thing wrong with the thorough and detailed explanation you were
> >> providing on a different topic (that explanation has been duely saved
> >> to my favorites and given a write up in my accessibility guide related
> >> to WCAG 2.1).
> >> NO problem, glad this was a minor mistake of yours and not a
> >> substantive change in the W3C specifications.
> >>
> >>
> >>> On 7/30/18, John Foliot < = EMAIL ADDRESS REMOVED = > wrote:
> >>> So... I may have been wrong there...
> >>>
> >>> There are multiple documents now at the W3C related to
> name-calculation,
> >> so
> >>> that is a problem as well as a source of confusion.
> >>>
> >>> Further reading and research suggests that ARIA 1.1 no longer
> references
> >>> the @title attribute directly, but the *HTML Accessibility API Mappings
> >>> 1.0*
> >>> Recommendation *does* (
> >>> https://www.w3.org/TR/html-aam-1.0/#input-type-text-
> >> input-type-password-input-type-search-input-type-tel-
> >> input-type-url-and-textarea-element),
> >>> as does the *Accessible Name and Description Computation 1.1*
> >>> Recommendation (
> >>> https://www.w3.org/TR/accname-1.1/).
> >>>
> >>> *The ARIA 1.1 *spec says this about @title:
> >>>
> >>> (The accessible)
> >>> name comes from values provided by the author in explicit markup
> features
> >>> such as the aria-label
> >>> <https://www.w3.org/TR/wai-aria-1.1/#aria-label> attribute,
> >>> the aria-labelledby
> >>> <https://www.w3.org/TR/wai-aria-1.1/#aria-labelledby> attribute,
> >>> or the host language labeling mechanism, such as the alt or title
> >>> attributes
> >>> in HTML, with HTML title attribute having the lowest precedence for
> >>> specifying a text alternative.
> >>>
> >>>
> >>> So I mis-spoke, and apologize for adding confusion. It was late, I was
> >>> discussing a different topic, and didn't give enough research to that
> >>> point.
> >>>
> >>> JF
> >>>
> >>> On Mon, Jul 30, 2018 at 12:40 PM, Birkir R. Gunnarsson <
> >>> = EMAIL ADDRESS REMOVED = > wrote:
> >>>
> >>>> Agreed.
> >>>> For clarity, we are talking about the title attribute, not the title
> >>>> element.
> >>>>
> >>>> The Accessible name calculation algorithm has allowed use of the title
> >>>> attribute as a source of accessible name for years.
> >>>> It is accessible to more people than aria-label, which is purely a
> >>>> screen reader solution, without CSS or JavaScript custom
> >>>> implementation.
> >>>> For focusable element the title attribute is supported as a source of
> >>>> accessible name by the vast majority of common browser and screen
> >>>> reader combinations.
> >>>>
> >>>> Removing a valid source of accessible name from the accessible name
> >>>> algorithm that has been stable and used for years, on thousands of
> >>>> pages, needs a pretty strong justification in my opinion.
> >>>> It creates a lot of work and makes accessibility standards less
> >>>> credible and robust.
> >>>> Imagine recommending the use of a certain HTmL or ARIA attribute
> >>>> because it solves a problem and it is a valid technique listed in a
> >>>> standard.
> >>>> If there is precedent that such attributes are removed from the
> >>>> standard down the road, a product owner is not going to allocate
> >>>> deverloper time to add this attribute.
> >>>>
> >>>> Assistive technology support is not a valid reason , as far as I know,
> >>>> so what is?
> >>>>
> >>>>
> >>>>> On 7/30/18, Joseph Sherman < = EMAIL ADDRESS REMOVED = > wrote:
> >>>>> I saw the exchange, that the Title element is no longer part of the
> >>>>> accessible name calculation. We have been using the following code
> for
> >>>> some
> >>>>> font icons- the plug in we are using allows only the addition of the
> >>>> Title
> >>>>> element to the font icons repository. Manually adding labels for
> every
> >>>> use
> >>>>> of the font icons is impractical, as most folks adding the icons are
> >>>>> not
> >>>>> code savvy, they just use the WYSWYG editor.
> >>>>>
> >>>>> <a class="ts-font-icons-link " href="http://*/news/rss.html"
> >>>> target="_blank"
> >>>>> title="RSS Feed"><i class="ts-font-icon icon-rss_ko"
> >>>>> style="background-color:#ffffff; width: auto; height: auto;
> >> font-size:
> >>>> 31px;
> >>>>> line-height: 100%;color:#353a3d;"></i></a>
> >>>>>
> >>>>> Wouldn't it have be better to add the Title element to AT instead of
> >>>>> removing it from the Specification?
> >>>>>
> >>>>> Joseph
> >>>>>
> >>>>>
> >>>>>