RE: SC 1.3.4 Another consideration?

> I would assume that the same token in a different attribute (e.g. 
aui-input) would be ok to fulfil the SC, which would be a longer term 
technique, but a rather complex solution at the moment (mixing 
autocomplete and aui-input).

Okay, that makes sense. So by using another technology, we can derive a 
broadened benefit from the meaning associated with the attribute values 
even where the html5 spec limits the use. 

Michael Gower
IBM Accessibility
Research

1803 Douglas Street, Victoria, BC  V8T 5C3
gowerm@ca.ibm.com
voice: (250) 220-1146 * cel: (250) 661-0098 *  fax: (250) 220-8034



From:   Alastair Campbell <acampbell@nomensa.com>
To:     Michael Gower <michael.gower@ca.ibm.com>
Cc:     "w3c-wai-gl@w3.org" <w3c-wai-gl@w3.org>
Date:   2018-02-28 03:54 PM
Subject:        RE: SC 1.3.4 Another consideration?



Hi Mike,
 
I think it might be ok, let’s see if I’ve understood: 
 
The crux of it seems to be that autocomplete does not apply to non-text 
inputs (e.g. select drop-downs), therefore can’t be applied to select 
drop-downs or radio buttons which match the criteria?
 
Also, the second bullet is:
“The content is implemented using technologies with support for 
identifying the expected meaning for form input data.”
 
I’d argue that the technology (HTML) doesn’t support the “expected 
meaning” unless it is a text input (or in some way covered by the spec & 
supported by user agents). 
This also speaks to the auto-fill benefit, rather than the personalisation 
benefit: It aligns with the first, not the second.
 
I would assume that the same token in a different attribute (e.g. 
aui-input) would be ok to fulfil the SC, which would be a longer term 
technique, but a rather complex solution at the moment (mixing 
autocomplete and aui-input).
 
Cheers,
 
-Alastair