E-mail List Archives

Search E-mail List Archives for

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

From: avik modi
Date: Tue, Sep 25 2018 2:11AM
Subject: WCAG 2.1 SC 1.3.5 Identify Input Purpose - Testing Methodology
No previous message | Next message →

Hi,

WCAG 2.1 Success Criteria (SC) "1.3.5 Identify Input Purpose" does not have
a Failure Technique mentioned in the W3 site. Moreover the SC talks about
support and maturity of the user agent and assistive tool to extract and
present the input purpose to user using different modalities. So in this
case how does an accessibility tester test for this SC in a website
conforming for WCAG 2.1 Level AA compliance since currently not all
browsers has good support for HTML 5.2 autocomplete attributes which is
defined as the Sufficient Technique for this SC. If any website does not
have these auto-complete attributes defined in code should the tester raise
it as an accessibility violation per WCAG 2.1.
Please suggest

*URL *-
https://www.w3.org/WAI/WCAG21/Understanding/identify-input-purpose.html

Thanks,
Avik

From: glen walker
Date: Tue, Sep 25 2018 11:39AM
Subject: Re: WCAG 2.1 SC 1.3.5 Identify Input Purpose - Testing Methodology
← Previous message | Next message →

If you have a couple of hours, read the discussion on this topic from July.

"WCAG 2.1 - 1.3.5 - How to capture a violation?" -
https://webaim.org/discussion/mail_thread?thread=8864

From: Isabel Holdsworth
Date: Wed, Sep 26 2018 2:05AM
Subject: Re: WCAG 2.1 SC 1.3.5 Identify Input Purpose - Testing Methodology
← Previous message | Next message →

Wow! My interpretation of this contentious subject is that if a form
element has a type that uniquely describes the required input (email,
tel, password, etc), and there's only one field of each type in the
form, this would be enough to identify its purpose programmatically.
But that if more complex data such as a street address is being
captured, autocomplete might be the only way of making each field
programmatically determinable.

It'll be interesting to see how the Understanding document mutates.

On 25/09/2018, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
> If you have a couple of hours, read the discussion on this topic from July.
>
> "WCAG 2.1 - 1.3.5 - How to capture a violation?" -
> https://webaim.org/discussion/mail_thread?thread=8864
> > > > >

From: John Foliot
Date: Wed, Sep 26 2018 8:04AM
Subject: Re: WCAG 2.1 SC 1.3.5 Identify Input Purpose - Testing Methodology
← Previous message | Next message →

Hi Avik,

Having been quite involved in the evolution of this SC, I can offer you my
(rather in formed) opinion. (Apologies in advance for the length of this
email)

Understanding the purpose of this SC is the first important step. The clue
is in the numbering: it is a 1.x.x SC (perceivable), as opposed to a 2.x.x
SC (operable) or 3.x.x SC (understandable). The goal of this SC is to make
those inputs *capable* of personalization, so that people with different
types of cognitive issue could "transform" (and be careful there, that is a
broad and loosely defined concept) the inputs (and labels) into different
presentation modes or modalities. The easiest possible solution there would
be to transform text labels into icons/symbols for users with reading
issues or who use symbol-based communication as part of their personal
communication strategy, *so that they can perceive the purpose of the input*
.

So the goal is to "tag" the inputs with a common, tightly defined token
value, so that the purpose of the input can be machine determined. To
accomplish that, we need to have a schema of metadata values (the
unambiguous token values) that can be attached at the element level: *in
other words, at the highest level we needed to attach a specific,
previously defined token value to the element, using an attribute.*

Form inputs can take a number of different attributes already: type, name,
id, aria-*, class, etc. However, almost all of the current attributes that
can be attached to an input element either take a string text value
(name="segundo nombre" , id="1d7rw9") or boolean values
(aria-required="true").

What we needed however was an attribute that instead took from a fixed and
defined list of token values, yet at the same time, the W3C group (AGWG -
Accessible Guidelines Working Group) did not have the mandate to 'invent'
our own new attribute or taxonomy. (I won't go into the why of that, but we
couldn't).

So... At one point, there was an exploration of using the microdata syntax (
https://www.w3.org/TR/microdata/) and values found at Schema.org, but we
discovered that there weren't all of the taxonomy values we needed at
schema.org at this time, and the authoring syntax of microdata is somewhat
'heavy'. Similar investigations also looked at using RDFa and other
metadata markup techniques.

But one possible solution, one that already had all the piece-parts we
required, was the somewhat newly minted autocomplete attribute from HTML5.

It was an attribute intended to be added to form inputs. It only is
'allowed' to take from one of 40+ token values, and each of those token
values was already unambiguously defined, so that machines "know" without
question the purpose of the input, even if it's accessible name - the label
- is more ambiguous, or is written in a non-English language. As the added
bonus, that attribute *ALSO* has some additional machine
'translation'/functionality today: because the browser knows beyond any
doubt what the input is for, it can now offer up a proposed value string to
insert into the input field - the "autofilling" part.

And so while the autofilling functionality appears to be the value outcome
of using the autocomplete attribute, the real value *with regard to this SC*
is actually at a slightly higher, conceptual level: we're now tagged the
inputs with clearly defined taxonomy terms that machines can further act
upon, whether that's provide hints and the ability to autocomplete the
input, or unambiguously convert a text label to an icon.

Do we have the tools today to do all that? Sorta.

Of course, the fact that browsers do *something* with the metadata
taxonomical term that is the token value used with that attribute, it was
sufficient evidence of a machine-readable value transforming the element
(the input goes from blank to filled) and was thus enough to be published
as a SC. However, there are also a few experimental browser extensions that
perform *other* functions beyond just autofilling the inputs, and it is
anticipated that now that web content will start to adopt the metadata
schema that *is* the autocomplete token values, that other tools will start
to emerge that takes advantage of that fact.

Today then, the principle technique for meeting SC 1.3.5 then is to use
autocomplete. However, in the future, the door has been left open that
other similar metadata taxonomies could also stand in. (Conceptually, think
of it this way: the original method of adding a textual alternative to an
image is to use the alt attribute, but today we can now also use aria-label
and aria-labelledby to achieve the same functional outcome. For SC 1.3.5,
@autocomplete is the "alt attribute technique" for meeting this SC today,
but in the future we may have alternative "aria-* -like" mechanisms as
well.)

You also asked about testing.

While it is true that native support in browsers is not complete against
all of the values, there are also a number of password tools that have very
good support for the "autofilling" bit (see:
https://www.w3.org/WAI/GL/wiki/WCAG_2.1_Implementations/JF/research). But,
more importantly, from a testing perspective what we are looking for is the
*condition*, as opposed to a specific outcome. In other words, the criteria
for pass or fail isn't based on functionality today, but rather via code
inspection: has the form input been tagged with an attribute that takes a
fixed token value that has been previously defined? (Once again, when we
test for SC 1.1.1, yes, we start by looking for alt=, but we cannot stop
there, as today we also test for aria-label or aria-labelledby). And while
it is true today that the preferred technique for SC 1.3.5 is to use
autocomplete, that isn't the end of the testing: the question you need to
ask is: "*Is this input tagged with a previously defined metadata term?*"
That takes code/DOM inspection.

The long term goal of Personalization - the holy grail for people with
cognitive issues - is to start adding additional element-level metadata to
our code.

But that is something of a chicken and egg problem, because we don't have
any tools today that could act on the addition of that metadata, so no
authors are adding the metadata; and so even if there were tools, there is
no content. But because there is no content, there are no tools (and 'round
and 'round we go). This is no different than when (back in the day for us
old timers) we struggled with using CSS (due to lack of browser support
back then), or the early days of using ARIA (when again, there was little
to no support) - somebody has to blink first. And so while this SC is very
limited in scope, it is also preparing authors with the notion that to meet
COGA requirements, start getting ready to be adding element level metadata
to our code - like you currently do with form inputs and @autocomplete.

And so Avik, simply put, to test this SC today, do a code inspection on the
form inputs looking for the autocomplete attribute. If there is no
autocomplete attribute, then more closely examine the input element - does
it have another attribute that is using a fixed token value? If yes (highly
unlikely today, but in the future..) then it will pass. But for the
foreseeable future, I personally am anticipating seeing either autocomplete
(Pass) or nothing (Fail).

(As an ancillary thought, with more forms using *all* of the autocomplete
attributes, perhaps browser will expand and improve their native support
for actually autofilling the forms - the "if we build it they will come"
approach.)

HTH

JF
--
*John Foliot* | Principal Accessibility Strategist
Deque Systems - Accessibility for Good
deque.com

From: Mark Rogers
Date: Thu, Sep 27 2018 3:22AM
Subject: Re: WCAG 2.1 SC 1.3.5 Identify Input Purpose - TestingMethodology
← Previous message | Next message →

Hi

> But for the foreseeable future, I personally am anticipating seeing either autocomplete (Pass)
> or nothing (Fail).

Doesn't the failure only happen when the input field purpose matches one of the input purposes listed:
https://www.w3.org/TR/WCAG21/#input-purposes
Otherwise, any form input fields that don't match any of the 40+ input purposes always fail (e.g. a Grade Point Average input field). I don't think autocomplete='on' counts as a pass, because ‘on' is the default if autocomplete is not specified, and means user agents use heuristics to guess the input type which seems at odds with the SC.
https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#autofill-detail-tokens
https://www.w3.org/TR/2017/REC-html52-20171214/sec-forms.html#autofilling-form-controls-the-autocomplete-attribute

I think having more documented successes and failures would help clarify this.

Is this password reset form with old and new passwords without autocomplete a fail of this SC?
<form>
<label>Old Password: <input type="password" name="old_password" ></label>
<label>New Password: <input type="password" name="new_password" ></label>
</form>

Is this password reset form with old and new passwords and autocomplete='on' a fail of this SC?
<form>
<label>Old Password: <input type="password" name="old_password" autocomplete="on" ></label>
<label>New Password: <input type="password" name="new_password" autocomplete="on" ></label>
</form>

Is this password reset form with old and new passwords and matching autocomplete tokens a pass of this SC?
<form>
<label>Old Password: <input type="password" name="old_password" autocomplete="current-password" ></label>
<label>New Password: <input type="password" name="new_password" autocomplete="new-password" ></label>
</form>

Is this a pass of the SC, given there's no matching input purpose?
<form>
<label>Grade Point Average: <input type="number" name="gpa" ></label>
</form>

Best Regards
Mark

--
Mark Rogers - = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >
PowerMapper Software Ltd - www.powermapper.com
Registered in Scotland No 362274 Quartermile 2 Edinburgh EH3 9GL



From: John Foliot < = EMAIL ADDRESS REMOVED = >
Date: Thursday, 27 September 2018 at 08:49
To: Mark Rogers < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] WCAG 2.1 SC 1.3.5 Identify Input Purpose - TestingMethodology

Hi Avik, Having been quite involved in the evolution of this SC, I can offer you my (rather in formed) opinion. (Apologies in advance for the length of this email) Understanding the purpose of this SC is the first important step. The clue is in the numbering: it is a 1.x.x SC (perceivable), as opposed to a 2.x.x SC (operable) or 3.x.x SC (understandable). The goal of this SC is to make those inputs *capable* of personalization, so that people with different types of cognitive issue could "transform" (and be careful there, that is a broad and loosely defined concept) the inputs (and labels) into different presentation modes or modalities. The easiest possible solution there would be to transform text labels into icons/symbols for users with reading issues or who use symbol-based communication as part of their personal communication strategy, *so that they can perceive the purpose of the input* . So the goal is to "tag" the inputs with a common, tightly defined token value, so that the purpose of the input can be machine determined. To accomplish that, we need to have a schema of metadata values (the unambiguous token values) that can be attached at the element level: *in other words, at the highest level we needed to attach a specific, previously defined token value to the element, using an attribute.* Form inputs can take a number of different attributes already: type, name, id, aria-*, class, etc. However, almost all of the current attributes that can be attached to an input element either take a string text value (name="segundo nombre" , id="1d7rw9") or boolean values (aria-required="true"). What we needed however was an attribute that instead took from a fixed and defined list of token values, yet at the same time, the W3C group (AGWG - Accessible Guidelines Working Group) did not have the mandate to 'invent' our own new attribute or taxonomy. (I won't go into the why of that, but we couldn't). So... At one point, there was an exploration of using the microdata syntax ( https://www.w3.org/TR/microdata/) and values found at Schema.org, but we discovered that there weren't all of the taxonomy values we needed at schema.org at this time, and the authoring syntax of microdata is somewhat 'heavy'. Similar investigations also looked at using RDFa and other metadata markup techniques. But one possible solution, one that already had all the piece-parts we required, was the somewhat newly minted autocomplete attribute from HTML5. It was an attribute intended to be added to form inputs. It only is 'allowed' to take from one of 40+ token values, and each of those token values was already unambiguously defined, so that machines "know" without question the purpose of the input, even if it's accessible name - the label - is more ambiguous, or is written in a non-English language. As the added bonus, that attribute *ALSO* has some additional machine 'translation'/functionality today: because the browser knows beyond any doubt what the input is for, it can now offer up a proposed value string to insert into the input field - the "autofilling" part. And so while the autofilling functionality appears to be the value outcome of using the autocomplete attribute, the real value *with regard to this SC* is actually at a slightly higher, conceptual level: we're now tagged the inputs with clearly defined taxonomy terms that machines can further act upon, whether that's provide hints and the ability to autocomplete the input, or unambiguously convert a text label to an icon. Do we have the tools today to do all that? Sorta. Of course, the fact that browsers do *something* with the metadata taxonomical term that is the token value used with that attribute, it was sufficient evidence of a machine-readable value transforming the element (the input goes from blank to filled) and was thus enough to be published as a SC. However, there are also a few experimental browser extensions that perform *other* functions beyond just autofilling the inputs, and it is anticipated that now that web content will start to adopt the metadata schema that *is* the autocomplete token values, that other tools will start to emerge that takes advantage of that fact. Today then, the principle technique for meeting SC 1.3.5 then is to use autocomplete. However, in the future, the door has been left open that other similar metadata taxonomies could also stand in. (Conceptually, think of it this way: the original method of adding a textual alternative to an image is to use the alt attribute, but today we can now also use aria-label and aria-labelledby to achieve the same functional outcome. For SC 1.3.5, @autocomplete is the "alt attribute technique" for meeting this SC today, but in the future we may have alternative "aria-* -like" mechanisms as well.) You also asked about testing. While it is true that native support in browsers is not complete against all of the values, there are also a number of password tools that have very good support for the "autofilling" bit (see: https://www.w3.org/WAI/GL/wiki/WCAG_2.1_Implementations/JF/research). But, more importantly, from a testing perspective what we are looking for is the *condition*, as opposed to a specific outcome. In other words, the criteria for pass or fail isn't based on functionality today, but rather via code inspection: has the form input been tagged with an attribute that takes a fixed token value that has been previously defined? (Once again, when we test for SC 1.1.1, yes, we start by looking for alt=, but we cannot stop there, as today we also test for aria-label or aria-labelledby). And while it is true today that the preferred technique for SC 1.3.5 is to use autocomplete, that isn't the end of the testing: the question you need to ask is: "*Is this input tagged with a previously defined metadata term?*" That takes code/DOM inspection. The long term goal of Personalization - the holy grail for people with cognitive issues - is to start adding additional element-level metadata to our code. But that is something of a chicken and egg problem, because we don't have any tools today that could act on the addition of that metadata, so no authors are adding the metadata; and so even if there were tools, there is no content. But because there is no content, there are no tools (and 'round and 'round we go). This is no different than when (back in the day for us old timers) we struggled with using CSS (due to lack of browser support back then), or the early days of using ARIA (when again, there was little to no support) - somebody has to blink first. And so while this SC is very limited in scope, it is also preparing authors with the notion that to meet COGA requirements, start getting ready to be adding element level metadata to our code - like you currently do with form inputs and @autocomplete. And so Avik, simply put, to test this SC today, do a code inspection on the form inputs looking for the autocomplete attribute. If there is no autocomplete attribute, then more closely examine the input element - does it have another attribute that is using a fixed token value? If yes (highly unlikely today, but in the future..) then it will pass. But for the foreseeable future, I personally am anticipating seeing either autocomplete (Pass) or nothing (Fail). (As an ancillary thought, with more forms using *all* of the autocomplete attributes, perhaps browser will expand and improve their native support for actually autofilling the forms - the "if we build it they will come" approach.) HTH JF -- *John Foliot* | Principal Accessibility Strategist Deque Systems - Accessibility for Good deque.com

From: Patrick H. Lauke
Date: Thu, Sep 27 2018 3:27AM
Subject: Re: WCAG 2.1 SC 1.3.5 Identify Input Purpose - TestingMethodology
← Previous message | Next message →

On 27/09/2018 10:22, Mark Rogers wrote:
[...]
> I think having more documented successes and failures would help clarify this.

Agree.

> Is this password reset form with old and new passwords without autocomplete a fail of this SC?
> <form>
> <label>Old Password: <input type="password" name="old_password" ></label>
> <label>New Password: <input type="password" name="new_password" ></label>
> </form>

Fail?

> Is this password reset form with old and new passwords and autocomplete='on' a fail of this SC?
> <form>
> <label>Old Password: <input type="password" name="old_password" autocomplete="on" ></label>
> <label>New Password: <input type="password" name="new_password" autocomplete="on" ></label>
> </form>

Fail?

> Is this password reset form with old and new passwords and matching autocomplete tokens a pass of this SC?
> <form>
> <label>Old Password: <input type="password" name="old_password" autocomplete="current-password" ></label>
> <label>New Password: <input type="password" name="new_password" autocomplete="new-password" ></label>
> </form>

Pass

> Is this a pass of the SC, given there's no matching input purpose?
> <form>
> <label>Grade Point Average: <input type="number" name="gpa" ></label>
> </form>

Pass / Not applicable

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Jared Smith
Date: Thu, Sep 27 2018 11:16AM
Subject: Re: WCAG 2.1 SC 1.3.5 Identify Input Purpose - TestingMethodology
← Previous message | Next message →

Mark Rogers wrote:

> Doesn't the failure only happen when the input field purpose matches one of the input purposes listed:
> https://www.w3.org/TR/WCAG21/#input-purposes

Yes, and only when collecting information directly from and about the
user completing the form.

This makes it a bit difficult to test this automatically. It's
difficult to surmise whether a form is collecting information about
THE user vs. information about SOME OTHER user. This SC would only
apply to the former.

> I don't think autocomplete='on' counts as a pass, because ‘on' is the default if autocomplete is not specified, and means user agents use heuristics to guess the input type which seems at odds with the SC.

Correct. This would not provide the level of field purpose
identification necessary for this success criterion.

> I think having more documented successes and failures would help clarify this.

Yep. I know the documentation for this is still in the works.

For what it's worth, I agree with Patrick's assessment of the examples
you provided.

Jared

From: Mark Rogers
Date: Fri, Sep 28 2018 5:52AM
Subject: Re: WCAG 2.1 SC 1.3.5 Identify Input Purpose - TestingMethodology
← Previous message | Next message →

This makes it a bit difficult to test this automatically. It's
difficult to surmise whether a form is collecting information about
THE user vs. information about SOME OTHER user. This SC would only
apply to the former.

The 'about the user' requirement being hard for software to determine presents an interesting problem for plug-ins (or any other user agent) consuming autocomplete to enhance presentation. They have no way of knowing if the autocomplete attribute is 'about the user' or about something else.

For example, an online tax form for non-profits might use autocomplete='organization' and autocomplete='street-address' to make it easier to complete. That seems like it could interfere with the input purpose autocomplete use outlined in SC 1.3.5 and cause problems with the WCAG Non-Interference requirement (e.g. if the AT overlays an icon indicating 'Your home address here' on the autocomplete='street-address' element.) But removing autocomplete from the form makes filling it harder for anyone who finds typing difficult due to Parkinson's or Arthritis.

Chrome deals with ambiguity of the autocomplete tokens by presenting a dropdown containing alternatives for autocomplete fields - an autocomplete='street-address' field might show addresses for home, work and a relative because you ordered them a gift last birthday.

Is this a problem, or am I missing something here?

Best Regards
Mark

--
Mark Rogers - = EMAIL ADDRESS REMOVED =
PowerMapper Software Ltd - www.powermapper.com
Registered in Scotland No 362274 Quartermile 2 Edinburgh EH3 9GL




On 27/09/2018, 18:16, "WebAIM-Forum on behalf of Jared Smith" < = EMAIL ADDRESS REMOVED = on behalf of = EMAIL ADDRESS REMOVED = > wrote:

Mark Rogers wrote:

> Doesn't the failure only happen when the input field purpose matches one of the input purposes listed:
> https://www.w3.org/TR/WCAG21/#input-purposes

Yes, and only when collecting information directly from and about the
user completing the form.

This makes it a bit difficult to test this automatically. It's
difficult to surmise whether a form is collecting information about
THE user vs. information about SOME OTHER user. This SC would only
apply to the former.

> I don't think autocomplete='on' counts as a pass, because ‘on' is the default if autocomplete is not specified, and means user agents use heuristics to guess the input type which seems at odds with the SC.

Correct. This would not provide the level of field purpose
identification necessary for this success criterion.

> I think having more documented successes and failures would help clarify this.

Yep. I know the documentation for this is still in the works.

For what it's worth, I agree with Patrick's assessment of the examples
you provided.

Jared

From: John Foliot
Date: Fri, Sep 28 2018 10:57AM
Subject: Re: WCAG 2.1 SC 1.3.5 Identify Input Purpose - TestingMethodology
← Previous message | Next message →

> The 'about the user' requirement being hard for software to determine
presents an interesting problem for plug-ins (or any other user agent)
consuming autocomplete to enhance presentation. They have no way of knowing
if the autocomplete attribute is 'about the user' or about something
else... Is this a problem, or am I missing something here?

Hi Mark,

You are essentially correct, and for the *functionality* assigned to
autocomplete, it is true that user-agents (browsers and password managers)
allow the end user to select appropriate stored data to complete the
fields. My current configuration(s) across multiple browsers actually
stores multiple 'personas' (i.e. I have a faked-out user: Mr. Joe. Q.
Tester, complete with a fake address, phone number and email address that I
use for testing, as well as my *actual* configurations - of which I have
both a Home profile with my personal email address, as well as a second
Work profile with my work address.)

However, I think the concern Jared is thinking of (a real concern) is that
it adds complexity to the testing, in that a tool alone cannot determine
"compliance" because that compliance is conditional on what type of data is
being collected (i.e. "of the specific user"). There are a number of other
use-cases that have surfaced that also add to "manual inspection
complexity" (imagine an online HR form that collects multiple "First
names"). As a representative of a company that also provides accessibility
compliance tools (Deque), we understand that every time you have to include
a more manual inspection, it adds to complexity, potential
"false-positives", and potentially additional cost/time to evaluate. While
not show-stoppers, they are real concerns, especially at large volume
(enterprise) scale. However, like many other SC in WCAG, at this time I
cannot see a why around the need for manual intervention in the test
process.

Not sure if this adds anything new to the discussion, but wanted to reply
to your thoughts.

JF

On Fri, Sep 28, 2018 at 6:52 AM, Mark Rogers < = EMAIL ADDRESS REMOVED = >
wrote:

> This makes it a bit difficult to test this automatically. It's
> difficult to surmise whether a form is collecting information about
> THE user vs. information about SOME OTHER user. This SC would only
> apply to the former.
>
> The 'about the user' requirement being hard for software to determine
> presents an interesting problem for plug-ins (or any other user agent)
> consuming autocomplete to enhance presentation. They have no way of knowing
> if the autocomplete attribute is 'about the user' or about something else.
>
> For example, an online tax form for non-profits might use
> autocomplete='organization' and autocomplete='street-address' to make it
> easier to complete. That seems like it could interfere with the input
> purpose autocomplete use outlined in SC 1.3.5 and cause problems with the
> WCAG Non-Interference requirement (e.g. if the AT overlays an icon
> indicating 'Your home address here' on the autocomplete='street-address'
> element.) But removing autocomplete from the form makes filling it harder
> for anyone who finds typing difficult due to Parkinson's or Arthritis.
>
> Chrome deals with ambiguity of the autocomplete tokens by presenting a
> dropdown containing alternatives for autocomplete fields - an
> autocomplete='street-address' field might show addresses for home, work and
> a relative because you ordered them a gift last birthday.
>
> Is this a problem, or am I missing something here?
>
> Best Regards
> Mark
>
> --
> Mark Rogers - = EMAIL ADDRESS REMOVED =
> PowerMapper Software Ltd - www.powermapper.com
> Registered in Scotland No 362274 Quartermile 2 Edinburgh EH3 9GL
>
>
>
>
> On 27/09/2018, 18:16, "WebAIM-Forum on behalf of Jared Smith" <
> = EMAIL ADDRESS REMOVED = on behalf of = EMAIL ADDRESS REMOVED = > wrote:
>
> Mark Rogers wrote:
>
> > Doesn't the failure only happen when the input field purpose matches
> one of the input purposes listed:
> > https://www.w3.org/TR/WCAG21/#input-purposes
>
> Yes, and only when collecting information directly from and about the
> user completing the form.
>
> This makes it a bit difficult to test this automatically. It's
> difficult to surmise whether a form is collecting information about
> THE user vs. information about SOME OTHER user. This SC would only
> apply to the former.
>
> > I don't think autocomplete='on' counts as a pass, because ‘on' is
> the default if autocomplete is not specified, and means user agents use
> heuristics to guess the input type which seems at odds with the SC.
>
> Correct. This would not provide the level of field purpose
> identification necessary for this success criterion.
>
> > I think having more documented successes and failures would help
> clarify this.
>
> Yep. I know the documentation for this is still in the works.
>
> For what it's worth, I agree with Patrick's assessment of the examples
> you provided.
>
> Jared
> > > > >
>
> > > > >



--
*​John Foliot* | Principal Accessibility Strategist
Deque Systems - Accessibility for Good
deque.com

From: Mallory
Date: Tue, Oct 02 2018 9:20AM
Subject: Re: WCAG 2.1 SC 1.3.5 Identify Input Purpose - TestingMethodology
← Previous message | Next message →

Hi,

I actually wonder about this:

>(imagine an online HR form that collects multiple "First names").

As a manual tester, should each of these get the "given-name" and or some with "additional-name" even though there may be more than one of each of these, and if they are present is that a pass even if in practicality any AT/browser/software which would be assisting someone wouldn't know the differentiation either (the label string would have to do that)?
Would be good to know.

cheers,
_mallory

On Fri, Sep 28, 2018, at 6:57 PM, John Foliot wrote:
> > The 'about the user' requirement being hard for software to determine
> presents an interesting problem for plug-ins (or any other user agent)
> consuming autocomplete to enhance presentation. They have no way of knowing
> if the autocomplete attribute is 'about the user' or about something
> else... Is this a problem, or am I missing something here?
>
> Hi Mark,
>
> You are essentially correct, and for the *functionality* assigned to
> autocomplete, it is true that user-agents (browsers and password managers)
> allow the end user to select appropriate stored data to complete the
> fields. My current configuration(s) across multiple browsers actually
> stores multiple 'personas' (i.e. I have a faked-out user: Mr. Joe. Q.
> Tester, complete with a fake address, phone number and email address that I
> use for testing, as well as my *actual* configurations - of which I have
> both a Home profile with my personal email address, as well as a second
> Work profile with my work address.)
>
> However, I think the concern Jared is thinking of (a real concern) is that
> it adds complexity to the testing, in that a tool alone cannot determine
> "compliance" because that compliance is conditional on what type of data is
> being collected (i.e. "of the specific user"). There are a number of other
> use-cases that have surfaced that also add to "manual inspection
> complexity" (imagine an online HR form that collects multiple "First
> names"). As a representative of a company that also provides accessibility
> compliance tools (Deque), we understand that every time you have to include
> a more manual inspection, it adds to complexity, potential
> "false-positives", and potentially additional cost/time to evaluate. While
> not show-stoppers, they are real concerns, especially at large volume
> (enterprise) scale. However, like many other SC in WCAG, at this time I
> cannot see a why around the need for manual intervention in the test
> process.
>
> Not sure if this adds anything new to the discussion, but wanted to reply
> to your thoughts.
>
> JF
>
> On Fri, Sep 28, 2018 at 6:52 AM, Mark Rogers < = EMAIL ADDRESS REMOVED = >
> wrote:
>
> > This makes it a bit difficult to test this automatically. It's
> > difficult to surmise whether a form is collecting information about
> > THE user vs. information about SOME OTHER user. This SC would only
> > apply to the former.
> >
> > The 'about the user' requirement being hard for software to determine
> > presents an interesting problem for plug-ins (or any other user agent)
> > consuming autocomplete to enhance presentation. They have no way of knowing
> > if the autocomplete attribute is 'about the user' or about something else.
> >
> > For example, an online tax form for non-profits might use
> > autocomplete='organization' and autocomplete='street-address' to make it
> > easier to complete. That seems like it could interfere with the input
> > purpose autocomplete use outlined in SC 1.3.5 and cause problems with the
> > WCAG Non-Interference requirement (e.g. if the AT overlays an icon
> > indicating 'Your home address here' on the autocomplete='street-address'
> > element.) But removing autocomplete from the form makes filling it harder
> > for anyone who finds typing difficult due to Parkinson's or Arthritis.
> >
> > Chrome deals with ambiguity of the autocomplete tokens by presenting a
> > dropdown containing alternatives for autocomplete fields - an
> > autocomplete='street-address' field might show addresses for home, work and
> > a relative because you ordered them a gift last birthday.
> >
> > Is this a problem, or am I missing something here?
> >
> > Best Regards
> > Mark
> >
> > --
> > Mark Rogers - = EMAIL ADDRESS REMOVED =
> > PowerMapper Software Ltd - www.powermapper.com
> > Registered in Scotland No 362274 Quartermile 2 Edinburgh EH3 9GL
> >
> >
> >
> >
> > On 27/09/2018, 18:16, "WebAIM-Forum on behalf of Jared Smith" <
> > = EMAIL ADDRESS REMOVED = on behalf of = EMAIL ADDRESS REMOVED = > wrote:
> >
> > Mark Rogers wrote:
> >
> > > Doesn't the failure only happen when the input field purpose matches
> > one of the input purposes listed:
> > > https://www.w3.org/TR/WCAG21/#input-purposes
> >
> > Yes, and only when collecting information directly from and about the
> > user completing the form.
> >
> > This makes it a bit difficult to test this automatically. It's
> > difficult to surmise whether a form is collecting information about
> > THE user vs. information about SOME OTHER user. This SC would only
> > apply to the former.
> >
> > > I don't think autocomplete='on' counts as a pass, because ‘on' is
> > the default if autocomplete is not specified, and means user agents use
> > heuristics to guess the input type which seems at odds with the SC.
> >
> > Correct. This would not provide the level of field purpose
> > identification necessary for this success criterion.
> >
> > > I think having more documented successes and failures would help
> > clarify this.
> >
> > Yep. I know the documentation for this is still in the works.
> >
> > For what it's worth, I agree with Patrick's assessment of the examples
> > you provided.
> >
> > Jared
> > > > > > > > > >
> >
> > > > > > > > > >
>
>
>
> --
> *​John Foliot* | Principal Accessibility Strategist
> Deque Systems - Accessibility for Good
> deque.com
> > > >

From: Jonathan Avila
Date: Tue, Oct 02 2018 10:49AM
Subject: Re: WCAG 2.1 SC 1.3.5 Identify Input Purpose - TestingMethodology
← Previous message | Next message →

Mallory, in your example I think none of them would get the autocomplete.

Jonathan

Sent from my iPhone

> On Oct 2, 2018, at 11:21 AM, Mallory < = EMAIL ADDRESS REMOVED = > wrote:
>
> Hi,
>
> I actually wonder about this:
>
>> (imagine an online HR form that collects multiple "First names").
>
> As a manual tester, should each of these get the "given-name" and or some with "additional-name" even though there may be more than one of each of these, and if they are present is that a pass even if in practicality any AT/browser/software which would be assisting someone wouldn't know the differentiation either (the label string would have to do that)?
> Would be good to know.
>
> cheers,
> _mallory
>
> On Fri, Sep 28, 2018, at 6:57 PM, John Foliot wrote:
>>> The 'about the user' requirement being hard for software to determine
>> presents an interesting problem for plug-ins (or any other user agent)
>> consuming autocomplete to enhance presentation. They have no way of knowing
>> if the autocomplete attribute is 'about the user' or about something
>> else... Is this a problem, or am I missing something here?
>>
>> Hi Mark,
>>
>> You are essentially correct, and for the *functionality* assigned to
>> autocomplete, it is true that user-agents (browsers and password managers)
>> allow the end user to select appropriate stored data to complete the
>> fields. My current configuration(s) across multiple browsers actually
>> stores multiple 'personas' (i.e. I have a faked-out user: Mr. Joe. Q.
>> Tester, complete with a fake address, phone number and email address that I
>> use for testing, as well as my *actual* configurations - of which I have
>> both a Home profile with my personal email address, as well as a second
>> Work profile with my work address.)
>>
>> However, I think the concern Jared is thinking of (a real concern) is that
>> it adds complexity to the testing, in that a tool alone cannot determine
>> "compliance" because that compliance is conditional on what type of data is
>> being collected (i.e. "of the specific user"). There are a number of other
>> use-cases that have surfaced that also add to "manual inspection
>> complexity" (imagine an online HR form that collects multiple "First
>> names"). As a representative of a company that also provides accessibility
>> compliance tools (Deque), we understand that every time you have to include
>> a more manual inspection, it adds to complexity, potential
>> "false-positives", and potentially additional cost/time to evaluate. While
>> not show-stoppers, they are real concerns, especially at large volume
>> (enterprise) scale. However, like many other SC in WCAG, at this time I
>> cannot see a why around the need for manual intervention in the test
>> process.
>>
>> Not sure if this adds anything new to the discussion, but wanted to reply
>> to your thoughts.
>>
>> JF
>>
>> On Fri, Sep 28, 2018 at 6:52 AM, Mark Rogers < = EMAIL ADDRESS REMOVED = >
>> wrote:
>>
>>> This makes it a bit difficult to test this automatically. It's
>>> difficult to surmise whether a form is collecting information about
>>> THE user vs. information about SOME OTHER user. This SC would only
>>> apply to the former.
>>>
>>> The 'about the user' requirement being hard for software to determine
>>> presents an interesting problem for plug-ins (or any other user agent)
>>> consuming autocomplete to enhance presentation. They have no way of knowing
>>> if the autocomplete attribute is 'about the user' or about something else.
>>>
>>> For example, an online tax form for non-profits might use
>>> autocomplete='organization' and autocomplete='street-address' to make it
>>> easier to complete. That seems like it could interfere with the input
>>> purpose autocomplete use outlined in SC 1.3.5 and cause problems with the
>>> WCAG Non-Interference requirement (e.g. if the AT overlays an icon
>>> indicating 'Your home address here' on the autocomplete='street-address'
>>> element.) But removing autocomplete from the form makes filling it harder
>>> for anyone who finds typing difficult due to Parkinson's or Arthritis.
>>>
>>> Chrome deals with ambiguity of the autocomplete tokens by presenting a
>>> dropdown containing alternatives for autocomplete fields - an
>>> autocomplete='street-address' field might show addresses for home, work and
>>> a relative because you ordered them a gift last birthday.
>>>
>>> Is this a problem, or am I missing something here?
>>>
>>> Best Regards
>>> Mark
>>>
>>> --
>>> Mark Rogers - = EMAIL ADDRESS REMOVED =
>>> PowerMapper Software Ltd - www.powermapper.com
>>> Registered in Scotland No 362274 Quartermile 2 Edinburgh EH3 9GL
>>>
>>>
>>>
>>>
>>> On 27/09/2018, 18:16, "WebAIM-Forum on behalf of Jared Smith" <
>>> = EMAIL ADDRESS REMOVED = on behalf of = EMAIL ADDRESS REMOVED = > wrote:
>>>
>>> Mark Rogers wrote:
>>>
>>>> Doesn't the failure only happen when the input field purpose matches
>>> one of the input purposes listed:
>>>> https://www.w3.org/TR/WCAG21/#input-purposes
>>>
>>> Yes, and only when collecting information directly from and about the
>>> user completing the form.
>>>
>>> This makes it a bit difficult to test this automatically. It's
>>> difficult to surmise whether a form is collecting information about
>>> THE user vs. information about SOME OTHER user. This SC would only
>>> apply to the former.
>>>
>>>> I don't think autocomplete='on' counts as a pass, because ‘on' is
>>> the default if autocomplete is not specified, and means user agents use
>>> heuristics to guess the input type which seems at odds with the SC.
>>>
>>> Correct. This would not provide the level of field purpose
>>> identification necessary for this success criterion.
>>>
>>>> I think having more documented successes and failures would help
>>> clarify this.
>>>
>>> Yep. I know the documentation for this is still in the works.
>>>
>>> For what it's worth, I agree with Patrick's assessment of the examples
>>> you provided.
>>>
>>> Jared
>>> >>> >>> >>> >>>
>>>
>>> >>> >>> >>> >>>
>>
>>
>>
>> --
>> *​John Foliot* | Principal Accessibility Strategist
>> Deque Systems - Accessibility for Good
>> deque.com
>> >> >> >> > > > >

From: Jared Smith
Date: Tue, Oct 02 2018 10:58AM
Subject: Re: WCAG 2.1 SC 1.3.5 Identify Input Purpose - TestingMethodology
← Previous message | No next message

> >(imagine an online HR form that collects multiple "First names").
>
> As a manual tester, should each of these get the "given-name" and or some with "additional-name" even though there may be more than one of each of these

I'm not sure. This is why John presented this as an edge case. It can
be difficult to know *which* autocomplete values are correct in this
case. By a strict interpretation, it's a failure if all of the first
name fields don't have an autocomplete attribute value, and it's also
a failure if an incorrect autocomplete value is defined (such as
given-name or additional-name for more than one field?).

> and if they are present is that a pass even if in practicality any AT/browser/software which would be assisting someone wouldn't know the differentiation either (the label string would have to do that)?

This is precisely the problem. If the end user relies on the
autocomplete attribute to guide their browser or software to complete
the form, and if the autocomplete values are ambiguous (e.g., multiple
given-name or additional-name), then it could actually lead to errant
input, even if interpreted to be WCAG conformant.

Jared