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://momdo.github.io/html/form-control-infrastructure.html#autofill-field>
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://momdo.github.io/html/form-control-infrastructure.html#control-group-text>
​



> 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> wrote:

>
>
>
>
> *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.
> ------------------------------
>



-- 
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion