Wcag: What is an "input field"? (1.3.5 Identify Input Purpose)

[JAWS-test]

I don't think the term "input field" is defined in WCAG. That's why I ask myself: what is an input field?

All input fields:

• <input type=text/email/tel etc.>
• <textarea>
• <div contenteditable>
• <div role=textbox>
• <div role=searchbox>

Also comboboxes (because text input is possible).

• <input role=combobox>
• <input list=ID>

All form fields, e.g.

• <select>
• <input type=checkbox>
• <div role=listbox>
• <div role=checkbox>

Currently, only autocomplete technology is available for 1.3.5. The attribute is not allowed for all of the elements I mentioned. But: in the future there might be another markup option for 1.3.5 - should this then also be limited to HTML inputs or apply to different form fields? It should be noted that the individual display of form fields already works independently of the HTML element used (From the Understanding: "People with cerebral palsy, stroke, head injury, motor neuron disease or learning disability sometimes prefer images for communication. They can employ assistive technology which adds icons to input fields to communicate the purpose of the fields visually ... Assistive technology can offer a customized way of identifying particular input fields, for example drawing on a set of symbols / icons that is familiar to the user, to communicate the purpose of the fields visually")

According to the HTML specification, autocomplete is currently allowed for

• input type=color, date, datetime-local, email, hidden, month, number, password, range, search, tel, text, time, url, or week
• textarea
• select

[alastc]

Hi @JAWS-test, I'm not sure if there is a problem here?

If you look at the required input purposes, the vast majority are things you have to type in to a text input. Only birth date and sex are things which I've seen done with select elements. As you said, that is allowed for in the spec.

[JAWS-test]

I'm not sure if there is a problem here?

What about form fields with ARIA roles where autocomplete is not possible? These are very widespread. Hardly anyone uses the HTML-select element, almost all pages use role=combobox instead.

[johnfoliot]

Hi @JAWS-test https://github.com/JAWS-test,

As you've noted, the @autocomplete attribute can only be applied to certain
types of inputs today. We are seeking to augment that by introducing the
(DRAFT!!) @data-purpose attribute in the emergent Personalization
TF specification:
https://www.w3.org/TR/personalization-semantics-content-1.0/#purpose-explanation

The need is very real, but the technology to address that need is still
quite young (or non-existent), so please note that the draft spec is our
attempt at breaking the chicken and egg cycle, and that at this time there
is a huge need for PoC tooling that can leverage the emergent spec.

HTH

JF

On Thu, Mar 11, 2021 at 6:41 AM JAWS-test @.*> wrote:

I'm not sure if there is a problem here?

What about form fields with ARIA roles where autocomplete is not possible?
These are very widespread. Hardly anyone uses the HTML-select element,
almost all pages use role=combobox instead.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/w3c/wcag/issues/1652#issuecomment-796675685, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJL446Q2ZYD43HLZGC4NLDTDCT5NANCNFSM4YD4ERAA
.

--
​John Foliot | Principal Accessibility Specialist

"I made this so long because I did not have time to make it shorter." -
Pascal "links go places, buttons do things"

[JAWS-test]

@johnfoliot The problem is that since 2018 we have to review applications on SC 1.3.5 and 1.3.6 and it is quite unclear what should be required from developers here that actually improves accessibility....

[johnfoliot]

@JAWS-test ,

*The intent of this Success Criterion is to ensure that the purpose of a
form input collecting information about the user can be programmatically
determined, so that user agents can extract and present this purpose to
users using different modalities. The ability to programmatically declare
the specific kind of data expected in a particular field makes filling out
forms easier, especially for people with cognitive disabilities. *(source:
https://www.w3.org/WAI/WCAG21/Understanding/identify-input-purpose.html)

Today, the only technique that scales is to use the @autocomplete
attribute (you COULD also use Microdata
https://html.spec.whatwg.org/#introduction-7, but the syntax for
Microdata is complex & verbose, and the required taxonomy is incomplete.)

Right now, the primary benefit of using @autocomplete to satisfy SC 1.3.5
is that it aids users with mobility impairments in the completion of a
form, although the SC requirement initially came from the COGA Task Force.
(Using the @microdata method would put you in technical compliance, but
sadly there are no tools taking advantage of that technique today.)

The overarching goal however was to make form inputs machine readable, so
that tools could provide further assistance to users. There really aren't
any tools out there today that fully leverage the goal (a few password
managers support more than the limited set of input values that have native
browser support), although with the emergence of the Personalization
Specification
https://w3c.github.io/personalization-semantics/content/index.html#purpose-explanation,
we're seeing some tool vendors begin to push the boundaries and work on the
tooling side.

From the Personalization Working Draft:

A personalization agent may add a symbol, replace the text with a more
familiar term, or give it a specific presentation. Note that there is no
default value.

The user experience may include filling in the field (autocomplete) or
adding an icon to augment the input label.

The purpose values that would typically be on form inputs should provide
context for the user. For example tel would relate to the user's
telephone number.

During A11y TO 2012 I also offered a bounty
https://www.slideshare.net/johnfoliot/135-more-than-autocomplete (of
sorts - a bottle of your prefered booze) to any tinkerer who wanted to try
their hand on leveraging the SC to do something useful besides fill out
the inputs. (Recognize as well that SC 1.3.5 was a real attempt to break
the chicken and egg cycle, in a fashion similar to how @aria attributes
were developed first, THEN the W3C Working group chased after browsers and
screen reader vendors to get implementation. This too is a common path -
for example the Pronunciation Task Force
https://w3c.github.io/pronunciation/technical-approach/ is taking a
similar approach, where we're working out the coding details first, then
getting tools on board - or at least that's the plan/hope.)

"...what should be required from developers..."

Today? Use @automplete and the appropriate attribute value on any of the
enumerated form inputs found in Section 7 of WCAG 2.1
https://www.w3.org/TR/WCAG21/#input-purposes

JF

On Thu, Mar 11, 2021 at 10:35 AM JAWS-test @.*> wrote:

@johnfoliot https://github.com/johnfoliot The problem is that since
2018 we have to review applications on SC 1.3.5 and 1.3.6 and it is quite
unclear what should be required from developers here that actually improves
accessibility....

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/w3c/wcag/issues/1652#issuecomment-796823885, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJL44ZWJEODZ55JHZ7NUCLTDDPK3ANCNFSM4YD4ERAA
.

--
​John Foliot | Principal Accessibility Specialist

"I made this so long because I did not have time to make it shorter." -
Pascal "links go places, buttons do things"

[johnfoliot]

Typo: my presentation at AllyTO was in 2018, not 2012...

JF

On Thu, Mar 11, 2021 at 11:52 AM John Foliot @.*> wrote:

@JAWS-test ,

*The intent of this Success Criterion is to ensure that the purpose of a
form input collecting information about the user can be programmatically
determined, so that user agents can extract and present this purpose to
users using different modalities. The ability to programmatically declare
the specific kind of data expected in a particular field makes filling out
forms easier, especially for people with cognitive disabilities. *(source:
https://www.w3.org/WAI/WCAG21/Understanding/identify-input-purpose.html)

Today, the only technique that scales is to use the @autocomplete
attribute (you COULD also use Microdata
https://html.spec.whatwg.org/#introduction-7, but the syntax for
Microdata is complex & verbose, and the required taxonomy is incomplete.)

Right now, the primary benefit of using @autocomplete to satisfy SC
1.3.5 is that it aids users with mobility impairments in the completion of
a form, although the SC requirement initially came from the COGA Task
Force. (Using the @microdata method would put you in technical compliance,
but sadly there are no tools taking advantage of that technique today.)

The overarching goal however was to make form inputs machine readable,
so that tools could provide further assistance to users. There really
aren't any tools out there today that fully leverage the goal (a few
password managers support more than the limited set of input values that
have native browser support), although with the emergence of the Personalization
Specification
https://w3c.github.io/personalization-semantics/content/index.html#purpose-explanation,
we're seeing some tool vendors begin to push the boundaries and work on the
tooling side.

From the Personalization Working Draft:

A personalization agent may add a symbol, replace the text with a more
familiar term, or give it a specific presentation. Note that there is no
default value.

The user experience may include filling in the field (autocomplete) or
adding an icon to augment the input label.

The purpose values that would typically be on form inputs should provide
context for the user. For example tel would relate to the user's
telephone number.

During A11y TO 2012 I also offered a bounty
https://www.slideshare.net/johnfoliot/135-more-than-autocomplete (of
sorts - a bottle of your prefered booze) to any tinkerer who wanted to try
their hand on leveraging the SC to do something useful besides fill out
the inputs. (Recognize as well that SC 1.3.5 was a real attempt to break
the chicken and egg cycle, in a fashion similar to how @aria attributes
were developed first, THEN the W3C Working group chased after browsers and
screen reader vendors to get implementation. This too is a common path -
for example the Pronunciation Task Force
https://w3c.github.io/pronunciation/technical-approach/ is taking a
similar approach, where we're working out the coding details first, then
getting tools on board - or at least that's the plan/hope.)

"...what should be required from developers..."

Today? Use @automplete and the appropriate attribute value on any of the
enumerated form inputs found in Section 7 of WCAG 2.1
https://www.w3.org/TR/WCAG21/#input-purposes

JF

On Thu, Mar 11, 2021 at 10:35 AM JAWS-test @.*>
wrote:

@johnfoliot https://github.com/johnfoliot The problem is that since
2018 we have to review applications on SC 1.3.5 and 1.3.6 and it is quite
unclear what should be required from developers here that actually improves
accessibility....

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/w3c/wcag/issues/1652#issuecomment-796823885, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJL44ZWJEODZ55JHZ7NUCLTDDPK3ANCNFSM4YD4ERAA
.

--
​John Foliot | Principal Accessibility Specialist

"I made this so long because I did not have time to make it shorter." -
Pascal "links go places, buttons do things"

--
​John Foliot | Principal Accessibility Specialist

"I made this so long because I did not have time to make it shorter." -
Pascal "links go places, buttons do things"

[JAWS-test]

@johnfoliot

autocomplete to satisfy SC 1.3.5 is that it aids users with mobility impairments in the completion of a form

To my knowledge this is not correct, because browsers use their own heuristics for autocomplete function and do not rely on the autocomplete attribute, but even ignore it

what should be required from developers?

For 1.3.5 it's clear: autocomplete (even if it doesn't help much and even if it's not clear if it should also be used on ARIA form fields - that was my initial question). But what about 1.3.6? The only technique currently published recommends landmark regions. They are certainly useful, but with them I do not fulfill all the wording of 1.3.6

[JAWS-test]

@alastc

Only birth date and sex are things which I've seen done with select elements. As you said, that is allowed for in the spec

honorific-prefix, honorific-suffix, sex, language are sometimes also requested with radio buttons or checkboxes and then no autocomplete is possible.

Can the term "input field" not be defined? This would be very helpful to understand what 1.3.5 refers to and what is currently technically possible

[awkawk]

I think that it is important to not read "input" in WCAG and think that means just the HTML input element. In WCAG a select element is regarded as an element that accepts user input as well.

If you look at SC 3.2.2 On Input it speaks to changing the setting of any UIC, and in 1.1.1 for "controls, input" it reads:

If non-text content is a control or accepts user input, then it has a name that describes its purpose. (Refer to Success Criterion 4.1.2 for additional requirements for controls and content that accepts user input.)

So for 1.3.5 I read it as any control that accepts user input, whether typed, checked, or selected.

[mraccess77]

So I think what folks are saying is that if you have radio buttons or ARIA role based input that takes info about the user and autocomplete is not available then you'd have to use micro data to pass the SC. I just want to make sure that there is a clear path to pass for these situations. If there is no way to pass then I think we need an exception.

[awkawk]

@mraccess77 thanks for that clarification. I was focusing mostly on the select element aspect, but I see the point re: radios and ARIA role inputs.

[patrickhlauke]

1.3.5 was, in my view, undercooked when it was made part of the standard. it's good that the "chicken and egg" problem is aknowledged, just sad that regardless of whether or not technologies aren't available or implemented yet, it's still a hard requirement...

but you've probably heard me say that a few times before already.

[alastc]

So to summarise:

• 1.3.5 SC text talks about 'inputs', and could be read narrowly (as HTML inputs) or widely (as anything which takes user-input).
• The standard approach of using the autocomplete attribute is not valid across all forms of user-input, which impacts things like aria-listbox elements used in place of select drop-downs.

The logical options appear to be:

• Open a bug on the HTML spec requesting autocomplete to be valid across more types of input. (I think that would also require opening bugs on each browser to support it.)
• Update the understanding doc to make it more focused on HTML input and other valid elements.
• Update the SC text to include an exception for elements where the appropriate markup/technique is not available.

[JAWS-test]

I would prefer this:

Update the SC text to include an exception for elements where the appropriate markup/technique is not available.

[johnfoliot]

...and while this is still quite immature, can we perhaps also look to
reference the emergent Personalization work? Specifically the
proposed @purpose attribute in the first module (https://www.w3.org/TR/personalization-semantics-content-1.0/#purpose-explanation)?

FWIW, I'd also support an exception as @JAWS-test suggested:

Update the SC text to include an exception for elements where the
appropriate markup/technique is not available.

Finally, I think we might also want to look at "content-editable" as a
different yet not-uncommon type of "input":

 <div contenteditable="true"> This text can be edited by the user. </div>

JF

On Tue, Mar 16, 2021 at 10:12 AM Alastair Campbell @.*>
wrote:

So to summarise:

• 1.3.5 SC text talks about 'inputs', and could read narrowly (as HTML
  inputs) or widely (as things which take user-input).
• The standard approach of using the autocomplete attribute is not
  valid across all forms of user-input, which impacts things like
  aria-listbox elements used in place of select drop-downs.

The logical options appear to be:

• Open a bug on the HTML spec requesting autocomplete to be valid
  across more types of input.
• Update the understanding doc to make it more focused on HTML input
  and other valid elements.
• Update the SC text to include an exception for elements where the
  appropriate markup/technique is not available.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/w3c/wcag/issues/1652#issuecomment-800290712, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJL446UCVE3U2GETDRPVBTTD5RM3ANCNFSM4YD4ERAA
.

--
​John Foliot | Principal Accessibility Specialist

"I made this so long because I did not have time to make it shorter." -
Pascal "links go places, buttons do things"

[alastc]

can we perhaps also look to reference the emergent Personalization work? Specifically the proposed @purpose attribute

What is the browser support like? We can write a technique for it, but I don't think it could be classed as "sufficient" until it's accessibility supported.

Finally, I think we might also want to look at "content-editable" as a different yet not-uncommon type of "input"

Isn't that another case of it being an element which doesn't take the autocomplete attribute? Is there something else different?

I know it's used for content areas, usually with some form of WYSIWYG interface, but the principle seems the same?

[johnfoliot]

Alastair,

What is the browser support like?

non-existent, and do not anticipate that changing in the short-term. There
is a real expectation that this will be handled by help-tools, in the same
way that screen readers and screen magnifiers are not "browsers" either.

I know it's used for content areas, usually with some form of WYSIWYG
interface, but the principle seems the same?

Yup. I believe it is out of scope for 1.3.5 (the purpose of an input
region like that is not one of the enumerated 'purposes' found in Section
7), but relevant to 1.3.6.
To see an example of content editable that actually also serves a cool
accessibility need (sorta), see:
https://hemingwayapp.com

JF

On Tue, Mar 16, 2021 at 5:35 PM Alastair Campbell @.*>
wrote:

can we perhaps also look to reference the emergent Personalization work?
Specifically the proposed @purpose https://github.com/purpose attribute

What is the browser support like? We can write a technique for it, but I
don't think it could be classed as "sufficient" until it's accessibility
supported.

Finally, I think we might also want to look at "content-editable" as a
different yet not-uncommon type of "input"

Isn't that another case of it being an element which doesn't take the
autocomplete attribute? Is there something else different?

I know it's used for content areas, usually with some form of WYSIWYG
interface, but the principle seems the same?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/w3c/wcag/issues/1652#issuecomment-800622067, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJL446MMYJ32R7MTXSFXULTD7FL3ANCNFSM4YD4ERAA
.

--
​John Foliot | Principal Accessibility Specialist

"I made this so long because I did not have time to make it shorter." -
Pascal "links go places, buttons do things"

[alastc]

There is a real expectation that this will be handled by help-tools, in the same way that screen readers and screen magnifiers are not "browsers" either.

Sorry, I should have said "user agents". That's fine, but we'll need some movement there to progress.