Andere manieren om het doel van een input in code aan te geven dan alleen autocomplete goedkeuren?

[rianrietveld]

Wat vinden jullie van het volgende:

Het gebruik van het juiste autocomplete-attribuut is een manier om te voldoen aan het WCAG-successcriterium 1.3.5 Identificeer het doel van de input (niveau AA). Er zijn ook andere manieren om het doel van een input in code aan te geven, zoals Schema.org attributen en inputtypes, ook die kunnen worden gebruikt om aan 1.3.5 te voldoen, mits ze voldoende “accessibility supported” zijn (zie conclusie van werkgroepdiscussie).

Dus: we keuren het goed als een autocomplete ontbreekt maar er toch een “accessibility supported” indicatie is van het doel van een invoerveld.

Voorbeeld: als er type="tel" is gebruikt.

Graag jullie mening.

[Aircl0wn]

In before de eeuwige discussies over de interpretatie van 'accessibility supported'...

Jokes aside, altijd voorstander van meerdere opties mits ze inderdaad goed ondersteund worden. Maar aangezien we hier ook al discussies over hebben rond het gebruik van headings en landmarks om content te omzeilen verwacht ik aardig wat onduidelijkheid.

[BartCardan]

Het gaat hier inderdaad over in hoeverre iets accessibility supported is. En dat blijft erg lastig.

Ik vind type="tel" (en vergelijkbaar) geen optie.
SC 1.3.5 gaat om het kunnen herkennen van persoonlijke gegevens. Het invoerveld met bijv. type="tel" geeft alleen aan dat er een telefoonnummer wordt vereist, maar niet om welk telefoonnummer. Dat hoeft niet altijd een persoonlijk telefoonnummer te zijn, zelfde problemen kunnen ook optreden met type="email" en type="url".

Als ik zo de discussie lees en ook de notitie op https://www.w3.org/2020/08/04-ag-minutes.html#item08 dan gaat het er voornamelijk om dat er extra opties (bijv. door metadata) zijn toegevoegd om toekomstige ontwikkelingen in het internet niet te beperken. Dat zien we vaker bij de WCAG.
Als de WCAG alleen autocomplete zou accepteren, dan zorgt dat voor een beperking als er in de toekomst betere oplossingen zijn.

Ik zie echter op dit moment nog geen "bewijslast" dat andere opties, zoals bijv. schema.org data / metadata, geaccepteerd worden en voldoende "supported" zijn.

[hidde]

(Reactie op persoonlijke titel)

Ik vind type="tel" (en vergelijkbaar) geen optie.
SC 1.3.5 gaat om het kunnen herkennen van persoonlijke gegevens. Het invoerveld met bijv. type="tel" geeft alleen aan dat er een telefoonnummer wordt vereist, maar niet om welk telefoonnummer. Dat hoeft niet altijd een persoonlijk telefoonnummer te zijn.

Ook in de autocomplete value tel is er geen onderscheid tussen persoonlijk en niet-persoonlijk, er zijn alleen afwijkende tel values voor bv local. Daarnaast: elk telefoonnummer dat in een formulier wordt opgevraagd is op een manier “information about the user” van de gebruiker die het formulier invult.

Als ik zo de discussie lees en ook de notitie op https://www.w3.org/2020/08/04-ag-minutes.html#item08 dan gaat het er voornamelijk om dat er extra opties (bijv. door metadata) zijn toegevoegd om toekomstige ontwikkelingen in het internet niet te beperken.

Ja, die discussie (ook in de samenvatting van Alastair in het comment dat Rian linkt) ging toen gaat inderdaad over schema… daar ben ik ook wat sceptisch over, dat is nog vooral een theoretische exercitie en wordt lang niet zoveel mee gedaan als zou kunnen.

Ik zie echter op dit moment nog geen "bewijslast" dat andere opties, zoals bijv. schema.org data / metadata, geaccepteerd worden en voldoende "supported" zijn.

type=tel heeft zeer breed support in browsers (>98%), ik zie in de demo's die ik heb gemaakt dat een deel van die browsers ze wel degelijk gebruikt als heuristiek om autocomplete te triggeren. Heb eens een (niet zo wetenschappelijk) polletje gedaan met link naar demo.

Bij twijfel is het natuurlijk eerder “niet accessibility supported”.

[hidde]

Ik heb het er met nog wat meer mensen over gehad, en nog wat dingen gevonden ter aanvulling:

• In de WebAIM mailing list lijkt de consensus ook dat type niet voldoende is
• Er was ook een discussie over type bij login fields, daarop is Understanding aangepast
• Dat het specifiek om info van de gebruiker gaat is volgens Patrick Lauke juist ook ivm COGA

In het Understanding doc staat expliciet dat input types niet voldoende zijn (geen normatief document, maar toch):

For some input fields, the type attribute already offers a way to broadly specify the intention of the input field, for example, input type="tel", input type="email", or input type="password". However, these are only very broad categories, describing the type of input, but not necessarily its purpose, especially as it relates to user-specific input fields. As an example, type="email" indicates that the field is for an e-mail address but does not clarify if the purpose is for entering the user's e-mail address or some other person's e-mail.

M'n polletje laat tot nu toe zien dat het op heel veel plekken werkt. Ik wilde kijken of ik dit systematisch kan testen met een aantal combinaties van veelgebruikte browsers/AT, maar als we met z'n allen vinden dat het sowieso om persoonlijk gaat, want COGA, dan maakt accessibility supported misschien niet echt meer verschil.

[BartCardan]

Dat is eigenlijk ook precies wat ik bedoelde. Eerlijk gezegd wist ik niet eens dat de verwijzing naar input type="tel" ook in de understanding stond als niet voldoende.

Persoonlijk zou ik willen dat we meer "native" manieren hebben om persoonsgegevens aan te kunnen duiden. Het autocomplete-attribuut is vanwege de Amerikaanse opzet natuurlijk in sommige gevallen voor de Nederlandse markt wat beperkt.

Ik ben ook best wel fan van het gebruik van de input type="tel" (varianten) en in andere gevallen het inputmode-attribuut om meer specifiek de vorm van input aan te kunnen geven. Dit verhoogt het gebruiksgemak voor alle gebruikers.

1.3.5 gaat echt om gegevens van de gebruiker en daar bieden de type-attributen helaas nog te weinig context voor. Theoretisch zou je in 1 formulier bijv. 3 velden met input type="tel" kunnen hebben voor gewoon telefoonnummer, mobielnummer en werknummer. Met het autocomplete-attribuut "tel" of "tel-national" kan je dan bij 1 van de eerste twee aangeven welke input je exact verwacht, namelijk het persoonlijk nummer van de gebruiker waar diegene mee wil communiceren.

Ik moet zeggen dat ik tot op heden echt geen enkele praktijkcase ben tegengekomen van een gebruiker die de autocomplete-attributen ook echt actief gebruikt. Dat wil zeggen:

• Om persoonlijke gegevens automatisch in te laten vullen, anders dan de slimmigheid van de browser waar je naar verwijst in je polletje https://cdpn.io/pen/debug/PoLjXBR
• Om extra info aan te geven bij de velden, bijv. in de vorm van kleuren of icoontjes.

[rianrietveld]

Is de conclusie en de concensus dat autocomplete kan niet vervangen kan worden door type of meta data?
Geef een 👍 voor mee eens.