RE: Question on techniques for Identify Common Purpose

Assuming that the situation described by John Foliot (namely that there appear to be no current implementations of all of the HTML5 autocomplete token values) holds, then the question put by Alex in the meeting today raises substantive issues.

Suppose that I write a form in HTML 5.2 containing a field with a purpose specified by one of the HTML5 autocomplete token values which is currently not supported. Assume further that I don’t include the autocomplete attribute. There are two ways of analyzing the situation:


  1.  HTML 5.2 is a technology “with support for identifying the expected meaning for form input data” (per 1.3.4), even though not all of the attribute values have implementations by user agents. Thus, failure to supply the attribute results in the form’s not conforming to 1.3.4. However, the required autocomplete token is not “accessibility-supported”, thus including the attribute would not bring the form into conformance with 1.3.4, because only accessibility-supported ways of using technologies can be relied upon to achieve conformance (per 5.2.4).
  2.  Alternatively, HTML 5.2 is not a technology “with support for identifying the expected meaning for form input data”, because some of the autocomplete tokens lack implementation by user agents and other tools. If this is the interpretation, then the form conforms to 1.3.4 (but not “actively”) on the basis that it is implemented in a technology which doesn’t satisfy the condition.

What type and level of “support” is enough? I think it’s ambiguous, and that it raises a problem concerning the testability of the success criterion. The form either conforms, or doesn’t, depending on your interpretation of the “technology” requirement in 1.3.4. Obviously, this issue arises for any technology that specifies all of the token values but only has partial implementations.

Also, and on a related topic, I recall expressing doubts earlier in the year that 1.3.5 can satisfy the CR exit criteria. I remain of that view, in as much as 1.3.5 seems to be in a worse position in relation to technology implementations than 1.3.4 currently is.

From: John Foliot [mailto:john.foliot@deque.com]
Sent: Thursday, February 15, 2018 11:59 AM
To: White, Jason J <jjwhite@ets.org>
Cc: Jonathan Avila <jon.avila@levelaccess.com>; Joshue O Connor - InterAccess <josh@interaccess.ie>; WCAG <w3c-wai-gl@w3.org>; lisa.seeman <lisa.seeman@zoho.com>
Subject: Re: Question on techniques for Identify Common Purpose

Hi Jason,

Comments inline.

> So far as I know, however, there’s no metadata schema available for achieving the desired mapping, even though, as John notes, formats for building such metadata do exist. Further, as I think we agree, no metadata-based approach is accessibility-supported – and this won’t happen in time for WCAG 2.1.

​I think in part that it depends on how you define metadata​. I would argue that the autocomplete attribute plus a predefined token value is a form of metadata, albeit of limited purpose (but suitable for our needs here).



> My basic idea, though, was that on my Web site I could declare that every form field with label “first name” maps to the given-name token.

​How? i.e. by what mechanism would the mapping occur? Part of the problem is that we require a shared common term ('handle'​) so that a mapping can begin to happen. Sure, you might create a number of forms with <label>First Name</label>, but what of other sites that use "Given Name"? "Christian Name"? or just "Name"? By relying on a random string of text to identify the purpose of the control, there is no way of doing a mapping or look-up table for any form of customization or modification / simplification.


> A user agent/assistive technology could then look for the string “given name” as the label and identify it as a field with the purpose specified by the token. The metadata for the same type of field on your Web site may need to be different, of course (e.g., different language used, or different terminology in the same language).

​Again Jason, if the AT is reliant on interpreting a token​, then the token value needs to be unambiguous across all use-cases. Currently, the @autocomplete attribute in HTML, along with the fixed list of token values, is the rudimentary metadata schema that allows for "looking up", and then potentially applying some mechanical processing to provide the customization or modification / simplification that is the larger goal of these SC (1.3.4 & 1.3.5), simply because the fixed list of token values have all been (unambiguously) defined.

Additionally, by using a "mechanical" (or fixed) term as opposed to a "random string term" we avoid any internationalization concerns, because every developer on the planet starts out by using the same "look up table" of token values: some developers could then use a localized version, so for example Makoto could promote and share a Japanese equivalent table<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmomdo.github.io%2Fhtml%2Fform-control-infrastructure.html%23autofill-field&data=02%7C01%7Cjjwhite%40ets.org%7Ce5e3792b63334361c3fb08d5749569bf%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636543107437737865&sdata=THK8FYVaJNmVxPngtVqH7tRmhkjzm3Nh7Z6r9zDPtpQ%3D&reserved=0> with the (english) token values, and then Japanese 'definitions', so that the developers know which value to use with the @autocomplete attribute.
​(From that link:
"name"

フルネーム

自由形式テキスト、改行なし

Sir Timothy John Berners-Lee, OM, KBE, FRS, FREng, FRSA

テキスト<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmomdo.github.io%2Fhtml%2Fform-control-infrastructure.html%23control-group-text&data=02%7C01%7Cjjwhite%40ets.org%7Ce5e3792b63334361c3fb08d5749569bf%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636543107437737865&sdata=jdzKFV%2BcwJCEvc%2BWU%2BKMcKo8Kwsipc%2Bepi7fvIjCJ2Q%3D&reserved=0>

​



> I don’t think using the title attribute will work – again, we don’t have a way to map it to the autocomplete tokens so that it can be “programmatically determined”, and (with or without such a mapping) there is no accessibility-supported way of using the information. Remember, the UA/AT is supposed to be the consumer of the information, which is then conveyed to the user in a way that is appropriate to facilitate understanding. We’re not exposing human-readable strings directly in the visual UI here in the hope that the user can interpret them effectively.

Agreed.


> Thus, my answer is that HTML autocomplete is currently the only known mechanism for implementing this SC which is accessibility-supported and hence available as a means of implementing this proposal.

​...today... (but who knows what the future might bring?)​


> It follows that any form field using contenteditable rather than a standard HTML form control will fail, until there’s an accessibility-supported metadata mechanism or equivalent functionality that can be implemented by content authors.

​Yes, today that is the current situation, because @autocomplete is only conformant on actual form inputs. However, it is not outside the realm of reasonability that we approach WebPlat about extending that attribute to any element that takes the @contenteditable attribute as well - if the browsers will support that then it should be easy to address.​


> I suspect that PDF will fail too, for the same reasons, even though a custom attribute in the structure tree could be created to hold the desired information.

Today, that is likely true. But now that we have a normative requirement (or at least we hope to) that today still isn't "legally mandated" (EU work on EN 301 549 notwithstanding), it is wholly reasonable that Adobe (or others) might add support for this down the road.


> So, I think this working group has negotiated itself into the “there’s only one currently viable way to do it” situation in developing 1.3.4.

Well, today, ya, I believe that is true, but I assert that once we get this on the books, better support will arrive. I'm still researching tooling and native support for the @autocomplete tokens, and part of that investigation uncovered a stand-alone "Password manager" that *might* support this beyond HTML, but even with limited techniques today, at least we get the ball rolling - it may not get to 100% of where we'd like to see it right away, but I believe we have enough that we can continue to advance forward today.

JF

On Thu, Feb 15, 2018 at 9:34 AM, White, Jason J <jjwhite@ets.org<mailto:jjwhite@ets.org>> wrote:


From: John Foliot [mailto:john.foliot@deque.com<mailto:john.foliot@deque.com>]
Sent: Wednesday, February 14, 2018 2:22 PM
Meanwhile, Jason wrote:

>  ...which maps, let’s suppose, accessible name strings used on my Web site to the corresponding tokens from the HTML autofill list. However, we don’t have a technology for doing this..."

​Not completely accurate Jason: we have a mechanism (technology) to attach​ metadata to specific elements (Microdata), and / but more importantly, it's not the "name" that we seek here, but rather the *purpose* - often tightly bound together, but not always the same. (i.e. a name that equals "screwdriver" has a purpose of "...a tool that drives screws", but you can also drive screws with other tools too, like an electric screw-gun, so name and purpose aren't always synonymous.)
[Jason] So far as I know, however, there’s no metadata schema available for achieving the desired mapping, even though, as John notes, formats for building such metadata do exist. Further, as I think we agree, no metadata-based approach is accessibility-supported – and this won’t happen in time for WCAG 2.1.
My basic idea, though, was that on my Web site I could declare that every form field with label “first name” maps to the given-name token. A user agent/assistive technology could then look for the string “given name” as the label and identify it as a field with the purpose specified by the token. The metadata for the same type of field on your Web site may need to be different, of course (e.g., different language used, or different terminology in the same language).
I don’t think using the title attribute will work – again, we don’t have a way to map it to the autocomplete tokens so that it can be “programmatically determined”, and (with or without such a mapping) there is no accessibility-supported way of using the information. Remember, the UA/AT is supposed to be the consumer of the information, which is then conveyed to the user in a way that is appropriate to facilitate understanding. We’re not exposing human-readable strings directly in the visual UI here in the hope that the user can interpret them effectively.
Thus, my answer is that HTML autocomplete is currently the only known mechanism for implementing this SC which is accessibility-supported and hence available as a means of implementing this proposal. It follows that any form field using contenteditable rather than a standard HTML form control will fail, until there’s an accessibility-supported metadata mechanism or equivalent functionality that can be implemented by content authors.

I suspect that PDF will fail too, for the same reasons, even though a custom attribute in the structure tree could be created to hold the desired information.
So, I think this working group has negotiated itself into the “there’s only one currently viable way to do it” situation in developing 1.3.4.

________________________________

This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.


Thank you for your compliance.

________________________________



--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com<mailto:john.foliot@deque.com>

Advancing the mission of digital accessibility and inclusion

________________________________

This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.


Thank you for your compliance.

________________________________