Hi Eric,
> a lot (all?) of the values seem to stem from this list in HTML for the autofill input fields
The first group (fields) overlap a lot after JamesN pointed out the overlap and Lisa aligned them, but the other 2/3rds do not overlap at all (links & buttons).
> I think it would be more than OK for WCAG2.1 to piggyback onto that established list (which provides enhancements for PwD and others).
Ok, but for the items it doesn’t address?
JF’s example:
> (using @title - English Example) <input type="text" aria-label="name"
> title="Provide your first or given name">
> The accessible name for both form fields would be “name” (as title would be overwritten) – barely sufficient for the English example but not for the Spanish one. I wonder if you meant another aria attribute (role?).
The idea is that it’s programmatically available, but not necessarily the name. A user-agent side thing (like an extension) would check for recognised meta-data or description, or that becomes the extended description anyway with title.
> I’d like to see a more general way of doing it, for example specifying
> <input type=“text name”> – I think we need to make sure to best not use accessibility specific prefixes where possible.
> Otherwise it might be seen as an afterthought.
I think JF was aiming for the most ‘general’ way, it could be better done in future but for 2.1 we’re aiming for ‘something useful’.
More generally, the aim for this SC (and hopefully successors in 2.2/3.0) is to identify common controls that a user-agent can then adapt. That is not the same thing as ARIA roles (e.g. a home-link is role=link, but that isn’t the conventional name for *that* link), and it isn’t the same as the accname (as we can’t force people to use particular names).
Cheers,
-Alastair