digdir
Describe 1.3.5 identify input purpose better in our documentation
As commented on the article Universell utforming i Designsystemet on UXNorge we should better describe how to comply with 1.3.5 Identify input purpose
A combination of correct use of input type and autocomplete is necessary. As of today we have written: (Norwegian)
Bruk gjerne inndatatyper som viser hva du ber om, for eksempel telefonnummer og e-post. Slike inndatatyper gir mobilbrukere et tastatur som passer til det de skal angi, for eksempel et numerisk tastatur for telefonnummer, men de kan også utløse validering på klientsiden.
This might be misleading. You should use input type email when appropriate.
Is correct use of input types actually a part of 1.3.5?
At this point I am not sure. I cant seem to see that this is said in the WCAG guidelines or in the norwegian interpretation. But I will read everything more closely before I conclude. One reason why I became uncertain about this is the input type="number" problem.
Lets say you are setting up a postal code text field. It makes sense to set the input type to "number". But according to the documentation "number" is actually a spinbutton. And is more incremental than actually just typing in a number. This introduce multiple problems. You can accidently scroll and change the number. When entering text you get no feedback that they are not allowed. They keypresses are just ignored. For postal code it makes no sense to use incremental numbers. As they are not incremental. They could be 0042 this is not a number in this context.
The solution is to use input type="text" and set inputmode="numeric" But if we interpret that 1.3.5 needs input type to be semanticly correct. We would fail, even though we actually read the documentation and set the correct attributes for our use case.
- [ ] Is correct use of input types a part of 1.3.5?
- [ ] Research what types are relevant to mention
- [ ] Write example on how it should be coded
- [ ] Write new documentation
- [ ] This should be visible on all relevant components. In the future it might be better to handle this in an article?
1.3.5 does not cover the type of input. The autocomplete is more relevant.
You have to take into account that a type number cant autocomplete name or email.
When I have to implement this i usually just follow this list:
https://www.w3.org/TR/WCAG21/#input-purposes
As for the support in screenreads I don't know, but most browsers support the fields. Super handy for people like me with different cognitive functions.
Its worth mentioning that autocomplete can be on input, textarea, select and form.
So if you input a username in a textarea it still needs the same autocomplete.
I could not find any info on:
Autocomplete works with these input types: text, search, url, tel, email, password, datepickers, range, and color.
Where did you find this? I could not find anything about this in the html spec.
Hi @poi33 This issue is a work in progress that I have neglected to finish. It is a part of a analysis based on the feedback we got from an accessibility review. You can read more about it here: #3379
And yes, I started documenting some issues with the comment that you always need to use a combination of a semanticly correct input type and autocomplete to comply with 1.3.5. For instance asking the user for their phonenumber. Should use type="number" and autocomplete="tel" As this was what we where critisized for, but I am not convinced that this is correct. And I have started documenting my thoughts on it, but its not complete yet. Its in the: "Is correct use of input types actually a part of 1.3.5?" part of the issue.
I could not find any info on:
Autocomplete works with these input types: text, search, url, tel, email, password, datepickers, range, and color.
Where did you find this? I could not find anything about this in the html spec.
I cant remember, but after searching I found it here https://www.w3schools.com/TAgs/att_autocomplete.asp W3Schools is not the best source, I will remove it 😊 But all input types that accept text and numbers support autocomplete.
Regarding input type: I do not think we should say that input type is required in regards to 1.3.5. I can not find this mentioned in the norwegian or the official WCAG guidelines. But we do want our users to use correct input types and our documentation mentions this. I would maybe consider adding a warning as Gov Uk has on their:
Avoid using inputs with a type of number Do not use unless your user research shows that there’s a need for it. With there’s a risk of users accidentally incrementing a number when they’re trying to do something else - for example, scroll up or down the page. And if the user tries to enter something that’s not a number, there’s no explicit feedback about what they’re doing wrong.
The other pont is auto-complete. I am not sure that it is obvious that auto-complete is required by WCAG if you are asking for the submitters data and it is in the list of approved autocomplete attributes. We should consider expanding on this.
You can find our documentation here: https://storybook.designsystemet.no/?path=/docs/komponenter-textfield--docs#inndata
Autocomplete
To make it clearer that Autocomplete can be a WCAG requirement we could do this:
Add link to UUTilsynet in this line:
autocomplete brukes i felter som mottar personlig informasjon. Hvis feltet skal be om personopplysninger om en annen person enn brukeren, må du sette autocomplete="off".
Like this:
autocomplete brukes i felter som mottar personlig informasjon. Hvis feltet skal be om personopplysninger om en annen person enn brukeren, må du sette autocomplete="off". WCAG 1.3.5: Identifiser formål med inndata
Input type number
We could have a section like Aksel have on their page where they give a warning on using this input type? Here is a first draft (in norwegian)
Input type="Number"Om man ønsker at det skal bli vist et numerisk tastatur for brukere på mobil har det vært vanlig å sette input typen til
numbermen dette kan skape noen utfordringer som er godt beskrevet i denne artikkelen. (Enten linke til Gov.uk sin artikkel eller stack overflow.) Bruk hellerinputMode="numeric"for å få riktig tastatur vist til brukere på mobil.