Re: Finding agreement on common purpose

I would say that like providing equivalent text for images, there are a variety of theoretically possible techniques, but the catch will be whether there is accessibility support.

If browsers/AT supported Microdata, then sure.
If Browsers/AT supported language-specific strings in the accessibility name, then sure. I think that the reality is that an AT with support for <input autocomplete=”first-name”> might also built in support for “first name” from the accessibility name property, but will they also do it for cc-name and other tokens? Taking this path probably represents more work for the author, but I’m sure people will do studies of the support over time, and maybe a different way other than the autocomplete attribute gains traction.

Today, I believe that the support exists in the browsers for the autocomplete/autofill values, so that is the closest thing to a “safe harbor” that we have and we will be able to construct a technique around that (in HTML). As the situation evolves additional techniques are possible.


Andrew Kirkpatrick
Group Product Manager, Accessibility

From: David MacDonald <>
Date: Tuesday, January 16, 2018 at 09:33
To: Andrew Kirkpatrick <>
Cc: "" <>, Joshue O Connor - InterAccess <>, WCAG <>
Subject: Re: Finding agreement on common purpose

Can someone answer if these will pass the new SC

<label>First Name<input ...></label>

The AccName would supply the purpose


<input aria-describedby="p1" ...></label>
<span id="p1" class="offscreen">credit card</span>

the AccDescription supplies the purpose

I think it should... and I think mapping AT should be able to map it. This is what understood during a call between Lisa, John, me and a couple of others early on as we were trying to find a way forward...

David MacDonald

CanAdapt Solutions Inc.

Tel:  613.235.4902



  Adapting the web to all users
            Including those with disabilities

If you are not the intended recipient, please review our privacy policy<>

On Tue, Jan 16, 2018 at 8:58 AM, Andrew Kirkpatrick <<>> wrote:
If the intent of this SC is to enable an AT to concretely determine the
    purpose of qualifying controls, then we need to define the set of
    possible tokens. If we say that any token can be used providing it maps
    to the HTML tokens, we're creating a situation where the best an AT can
    do is use heuristics and guesswork to make the determination.

That’s not how I see it Leonie.

The tokens defined in the PDF/OOXML/EPUB/etc specifications to convey purposes of input controls are the tokens that can be used for that technology. The tokens in each of those technologies that are mapped to tokens in the HTML list to represent the same purpose are the ones that the author is required to use.

AT will need to know what tokens are supported in a given technology, and the AT will look at the PDF/OOXML/EPUB/etc spec to implement support.

Authors looking to the right thing will determine if there is a means to convey the purposes for inputs for their technology and implement all of the tokens fully. Some of these may go beyond what HTML 5.2 indicates.
Authors looking to do as little as possible will compare the set of tokens for their technology with the HTML set and only implement the overlap.

There may be some interpretation and debate about whether the purpose of the token in one technology is mapped to a token in HTML, but the set of HTML tokens is pretty tight, so I don’t think that will be significant.


Received on Tuesday, 16 January 2018 15:40:31 UTC