Verzoek om af te mogen wijken op WCAG-norm 3.2.2: Bij input, bij invoeren pincode in apps

[rianrietveld]

Dit issue is ingebracht in het overleg van de onderzoeksbureau's op 20 juni 2023 en daar besproken.

De situatie:

De toegang tot de functionaliteit van de DigiD app is beveiligd met een pincode bestaande uit 5 cijfers. De gebruiker dient deze tweemaal in te voeren bij het vastleggen en eenmaal bij het veranderen van de pincode, bij het opstarten van de DigiD app en om de DigiD app te unlocken als die na een time-out automatisch gelocked wordt. In al deze gevallen, wordt na het invoeren van het 5e cijfer, automatisch naar het volgende scherm gegaan.

Deze constructie is afgekeurd op grond van succescriterium 3.2.2: Bij Input: "Verandering van de instelling van een component van de gebruikersinterface veroorzaakt niet automatisch een contextwijziging, tenzij de gebruiker geïnformeerd is over het gedrag vóór het gebruik van de component."

Vrij vertaald stelt Cardan dat, of na invoering van het 5e cijfer er een bevestigingsknop zoals ‘Verder’ gebruikt moet worden, of dat vlak daarvoor de gebruiker geïnformeerd moet worden over de contextwijziging na invoering van het 5e cijfer.

Wat verwacht de gebruiker?
De gebruiker verwacht bij het invoeren van de pincode, het gedrag zoals de DigiD app het vertoont. Logius heeft in al de jaren dat de DigiD app gebruikt wordt (12 miljoen gebruikers) geen enkele opmerking gehad dat dit onverwacht zou zijn en problemen geeft bij welke groep dan ook, inclusief gebruikers die blind of slechtziend zijn. Naar onze mening is dit een WCAG eis die voor het web wel opgaat, ook bij het invoeren van een pincode in de browser, maar niet voor die van een app. Wij kennen ook geen app die een van bovenstaande maatregelen heeft geïmplementeerd.

Daarnaast zullen naar onze verwachting de voorgestelde oplossingen bij onze 12 miljoen gebruikers verbazing en zelfs contacten met de helpdesk gaan genereren omdat dergelijke teksten of de extra knop juist onverwacht zijn. Dit is ongewenst.

Discussie en in het overleg onderzoeksbureau's

De opmerking dat "we het al jaren doen en niemand klaagt" is geen sterk argument. Puur technisch: de cijfers die in invoert zijn bij een app knoppen en geen invoervelden. Dus als je het zo bekijkt is het indrukken van een cijfer al een submit an zich. Maar als je naar de intentie kijkt van het succescriterium: automatisch doorgaan na het invoeren van een pincode is bij een app verwacht gedrag. Dat gebeurt in alle gevallen als je een code moet invoeren. Wel is belangrijk aan te geven hoeveel cijfers de code bevat aan schermlezer-gebruikers. Zodat zij weten wanneer naar een volgend scherm wordt gegaan.

Conclusie: Automatisch doorgaan naar een volgend scherm na het invoeren van een pincode/inlogcode op een app wordt goedgekeurd. Mist de schermlezer-gebruiker van te voren wordt geïnformeerd over het aantal in te voeren cijfers.

[erikkroes]

Dus als ik het goed begrijp:

Invoer op een app wordt gezien als het activeren van knoppen, en dat wordt genoemd in de intentie, en daarom wordt het niet afgekeurd?

Mijn eerste indruk is dat dat nogal vergezocht is. De intentie is ten eerste niet normatief. Dat zou al genoeg reden moeten zijn.

En ten tweede, en dan zie ik waarom deze niet normatief is, de intentie ontwijkt juist vaak techniek. Om nu technische termen te koppelen aan een niet-technische tekst, lijkt me geen eerlijke benadering. Wel normatief is dit: https://www.w3.org/Translations/WCAG21-nl/#dfn-user-interface-components

Componenten zoals hier bedoeld zijn niet gebonden aan programmeertechnieken, maar aan wat de gebruiker waarneemt als aparte bedieningselementen.

Als het eruit ziet als een invoerveld, en je kan informatie invoeren, maar het is technisch een knop. Is het dan niet een 1.3.1-failure? (Hoe wordt het eigenlijk voorgelezen?) Als dit in de app mag, maar op het web niet. Dan is het per definitie niet consistent. Kun je het dan wel "verwacht gedrag" noemen?

En volgens mij heb ik wel degelijk apps waar je een code invoert en die moet submitten. Meestal gaat het om 2fa en bevestigingscodes, dus ik kan het even niet checken zo snel, maar volgens mij gaat het om apps die veel groter zijn dan 12 miljoen gebruikers. Ik vind het een zwaktebod om met dat getal te zwaaien.

[JeroenHulscher]

Dat vonden wij ook geen correcte argumenten, zoals je kunt teruglezen, Erik. Ik denk dat we de argumenten in bovengaande nog verder moeten verduidelijken om al te veel discussie te voorkomen, maar dit is in ieder geval de conclusie die gisteren met een grote groep experts is besproken en inmiddels ook met de betreffende partij is besproken. Je bent van harte welkom voortaan aan te haken bij de meetings overigens! :)

[JJdeGroot]

@erikkroes Bij zowel de pincode schermen van Android en iOS op besturingssysteemniveau wordt de pincode direct gecontroleerd na het invullen van het laatste cijfer. Zoals jij noemt zijn er ook apps die wel gebruik maken van een submit-knop. Maar de meeste apps doen dit automatisch. Op mijn telefoon zijn dat naast DigiD, o.a.: ING, Rabobank, Regiobank en Yivi.

Ik denk dan ook dat de meeste gebruikers de verwachting hebben dat een pincode direct wordt gecontroleerd na invoer. Als er bij een pincode scherm wordt aangegeven hoeveel cijfers je moet invullen, dan is het mijn insziens ook in de lijn de verwachtingen dat er na invoer van het laatste cijfer iets gebeurd.

Dat was in ieder geval een van de conclusies waardoor je voldoet aan deze uitzondering van 3.2.2: "unless the user has been advised of the behavior before using the component."

[Aircl0wn]

Geen "Changing the setting of any user interface component"

We hebben geconcludeerd dat de normatieve tekst in letterlijke zin niet van toepassing is, omdat je hier niet te maken hebt met een "verandering van de instelling van een component". Dat heeft dus niets met de UD te maken. Het gaat hier (voor de app!) niet om een feitelijke invoer in invoerveld(en) maar door de implementaties in de app heb je te maken hebt met een serie van knop activaties. Zo worden ze ook opgemaakt in de app en voorgelezen door screenreaders. er moet dus actief nog naar een andere knop genavigeerd worden.

Het zou een andere situatie zijn als je, zoals bij een gewoon invoerveld, je native toetsenbord krijgt en daar je invoer doet.

Over consistentie tussen twee verschillende technieken (web en app) kun je niet spreken. Die zijn wezenlijk anders. Dat kan dus betekenen dat de interpretatie voor een app wisselt ten opzichte van web.

Begeleidend schrijven

Een begeleidend schrijven is aanwezig voorafgaand aan de interactie i.i.g. in de screens die ik gezien heb, ik heb niet de hele DigiD app gereset. Besproken is dat die uitbreiden met de hoeveelheid verwachtte cijfers wenselijk is om het nog duidelijker te maken.

contextwijziging

We hebben ook besproken of het door een pincode scherm heengaan wel een context switch zou zijn. Gezien de voorbeelden bij de definitie van "change of context" is de conclusie dat je dit wel als een change of context moet zien. Je gaat immers naar een nieuwe, en ook substantieel andere, pagina. Ook al is die verwachting er bij de gebruiker mogelijk(!) wel al.

Opening a new window, moving focus to a different component, going to a new page (including anything that would look to a user as if they had moved to a new page) or significantly re-arranging the content of a page are examples of changes of context.

Aanvragen van uitzonderingen

Ik denk dat we het allemaal wel eens zijn dat niet de bedoeling is dat organisaties individuele uitzonderingen gaan aanvragen, maar dat het komen tot een breed gedragen consensus zoals hier een goede oplossing is. Ofwel ze kunnen een second opinion of in dit geval een group opinion vragen.

Daarnaast zijn er wettelijke verplichtingen en daarin zijn enkele (tijdelijke) uitzonderingen bepaald. Die zijn echter ook niet op Nederlands niveau vastgesteld. De vrijheid is er om daaraan toe te voegen (meen ik), maar dat lijkt me een lange weg via de wetgever. De WCAG, interpretaties en wetgeving gaan immers veel verder dan onze landsgrenzen.

[erikkroes]

Dat vonden wij ook geen correcte argumenten, zoals je kunt teruglezen, Erik. Ik denk dat we de argumenten in bovengaande nog verder moeten verduidelijken om al te veel discussie te voorkomen, maar dit is in ieder geval de conclusie die gisteren met een grote groep experts is besproken en inmiddels ook met de betreffende partij is besproken. Je bent van harte welkom voortaan aan te haken bij de meetings overigens! :)

@JeroenHulscher Als mijn interpretatie niet goed aansluit bij de gesprekken hierover, dan is dat misschien inderdaad een teken dat verduidelijking welkom is 😄 Bedankt voor de uitnodiging. Als er een datum en tijd bekend is, dan overweeg ik graag of m'n energieniveau het dan toelaat!

[rianrietveld]

Conclusie en consensus binnen de vergadering van onderzoeksbureau's: Automatisch doorgaan naar een volgend scherm na het invoeren van een pincode/inlogcode op een app wordt goedgekeurd. Mist de schermlezer-gebruiker van te voren wordt geïnformeerd over het aantal in te voeren cijfers.