- From: Andrew Kirkpatrick <akirkpat@adobe.com>
- Date: Tue, 16 Jan 2018 13:58:58 +0000
- To: "tink@tink.uk" <tink@tink.uk>, Joshue O Connor - InterAccess <josh@interaccess.ie>, "w3c-waI-gl@w3. org" <w3c-wai-gl@w3.org>
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.
AWK
Received on Tuesday, 16 January 2018 13:59:23 UTC