RE: Question on techniques for Identify Common Purpose

From: John Foliot [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.

________________________________