Skip to content
This repository has been archived by the owner on Jun 30, 2018. It is now read-only.

Using for SC1.3.4 #653

guyhickling opened this issue Jan 3, 2018 · 4 comments

Using for SC1.3.4 #653

guyhickling opened this issue Jan 3, 2018 · 4 comments


Copy link

One of the proposed "sufficient techniques" for SC 1.3.4 "Identify Common Purpose" is to use the item types to tell browsers and AT what interactive items are for, so that they can provide extra cues to users - such as displaying symbols on screen to further identify interactive fields to the user.

However was created for the search engines. Up to now has had no relevance to browsers that I know of - they presumably just ignore those items.

So I have to ask the same questions that I asked recently about the suggestion of using the HTML5 autocomplete attribute for the same purpose. Have any browsers started to do anything with item types for accessibility purposes? Do they plan to? Is anyone at W3C working with them to achieve this? If browsers - and AT - are to provide extra cues to users when they find types, that will be a huge new project for the browsers. Is that project underway yet?

The primary question in all this is, in telling developers to use types when WCAG 2.1 goes live, will we be telling developers to do something that will have no practical accessibility value whatsoever and just mean extra work for developers to no purpose?

There is no need here to ask developers to do this entirely on spec. Given that markup is already out there on many web pages for SEO purposes, let the browsers first do the job of picking up that data and using it for accessibility purposes. If they do that - and I suspect that might be a big if - that will be the time to start asking developers to do all the extra work to implement it as a technique under this SC.

Copy link

johnfoliot commented Jan 3, 2018 via email

Copy link

Hi John, thank you for answering, and I do appreciate the difficulty.

My problem is that I have clients who pay me to do accessibility audits and tell them what to do to make their sites accessible. If I start telling them to use item types, some of the more aware clients are likely come at me and say "What browsers do anything with this?" And I will have to admit, well, actually none of them do! At which point no doubt some of them will go and find a new audit consultant!

I can see your argument about the chicken and egg situation. But is already in use for SEO, so (and assuming SEO people apply schema to input fields, the elements this SC is targeting) the browsers have a base of websites to apply their developments to. Then once the browsers have done that developers can start using it on all sites.

I don't think asking developers and IT departments, and testers and auditors, to go to a load of extra trouble to use any of the technologies mentioned in this SC is the right way to go about it - purely on spec that maybe 3 or 4 or more years down the road browsers will wake up and make some use of it in some way not currently clear. We already have enough trouble getting developers to use ARIA correctly, or even at all, and that's been around for years. (A good many of my clients, even ones really serious about accessibility, still can't get their heads around something as simple as the h1 to h6 hierarchy!!)

I am sorry to sound pessimistic, but I seriously think we may be in danger of subjecting developers to accessibility overload. (Let's face it, some are only grudgingly implementing the accessibility principles we already have under pressure from management.) Let's get the world all up to speed with ARIA before trying to move them on further!

In fact, I would suggest maybe a much better approach to this SC would be to add new attributes for this SC to ARIA, a tried and tested technology that people are already at least familiar with (and much less typing for developers than, say and some of the others). Rather than introducing several whole new technologies before they have learned the current one.

Copy link

lseeman commented Jan 11, 2018

Hi Guy

I agree with your suggestion that it should be supported by ARIA. In fact an ARIA module has been drafted for that purpose. See

Copy link

awkawk commented Jan 21, 2018

(Official WG response)
The SC has been changed to focus on currently supported attributes, so browsers support this across the board: (There are some issues with browser implementations, but they do not appear to affect the autofill part of autocomplete.)

This aspect alone is very helpful to some people with cognitive issues.

For the aspect of adding icons for users (another goal of the SC) It is also worth noting that there are several implementations already: Chrome extension: Script: Website based implementation:

These are at early stages and have been using the COGA semantics spec, but these can be updated to cover the autofill attributes as well, while the other aspects mature.

Overall, there is basic support for the proposal already, and people committed to expanding the functionality during the CR stage.

Given the user-need, and that this new version is far easier to implement, there does not seem to be an issue with including this SC at level AA.

@awkawk awkawk closed this as completed Jan 21, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet

No branches or pull requests

4 participants