Open PaulvanWorkum opened 1 year ago
BartCardan
commented
1 year ago WCAG 2.2 sc 2.4.11 komt te vervallen op niveau AA, tenzij iemand weer besluit om 'm terug te brengen. Is je voorstel 1 voor de focusindicator dan nog wel relevant?
Persoonlijk lijkt het me niet dat we een belangrijk SC voor toetsenbordnavigatie zomaar moeten schrappen. Ik voel dus niet heel veel voor je voorstel 2.
PaulvanWorkum
commented
1 year ago Dag Bart,
Voorstel 1 gaat over zowel SC 2.4.7, als ook SC 2.4.11. Ik heb me nog onvoldoende verdiept in WCAG 2.2, maar 2.4.11 staat zover ik kan zien nog op niveau AA: https://www.w3.org/TR/WCAG22/#focus-not-obscured-minimum. Of is dat verouderde informatie? Maar dan zou SC 2.4.7 nog steeds van toepassing zijn.
Voorstel 2 zegt niet dat we de eisen van toetsenbordnavigatie moeten schrappen, dat lijkt me niet wenselijk. Het gaat over de situatie dat het alleen toetsen met een extern toetsenbord zorgt voor afkeur van apps. De vraag is of dit terecht is. Aangezien het toetsenbordinterface bij stembediening en schermlezer wel gewoon werkt kunnen we niet uitsluiten dat dit aan het hulpmiddel (extern toetsenbord) ligt. Wij hebben na onderzoek van de documentatie van Apple/Google en door met diverse hulpmiddelen te testen namelijk niet kunnen vaststellen dat het aan de code/app ligt. Zeker omdat meerdere apps (ook die van Apple en Google) hetzelfde probleem ondervinden.
Gisteren heb ik o.a. de Google Agenda app aan Jeroen laten zien op Android. Met toetsenbord kun je niet naar de titlebar navigeren met Tab en pijlen. Hierdoor is o.a. het menu, kiezen van maand en zoekfunctie niet bereikbaar met externe toetsenbord.
BartCardan
commented
1 year ago Of is dat verouderde informatie?
Klopt. https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/ let op: de nummering is ook veranderd. 2.4.11 is nu 2.4.13 op niveau AAA.
JeroenHulscher
commented
1 year ago Voorstel 1: volgens mij kun je dat niet zomaar schrappen, want 2.4.7 is wel haalbaar toch?
Voorstel 2: Ik denk dat ik het er min of meer mee eens ben, maar je argumenten zijn niet de juiste. Volgens mij moeten we niet kijken naar reeds bestaande (al dan niet native) apps van Apple en Google. Maar als het technisch niet mogelijk is om het te implementeren, of beter gezegd; technisch niet mogelijk is om externe hulpapparatuur te supporten, dan is dat wel iets dat simpelweg niet op te lossen lijkt. Of zie jij dat anders, @BartCardan? En heb jij hier nog een visie op, @hidde?
BartCardan
commented
1 year ago Ik omschrijf het even in mijn eigen woorden om te kijken of ik het probleem goed begrijp.
Ik speel even advocaat van de duivel om de discussie wat aan te zwengelen. Ik vind het namelijk wel een goede discussie, waar tot op zekere hoogte best wel iets voor te zeggen is. Ik ben het alleen nog niet helemaal eens met de argumenten (zoals Jeroen ook al aangeeft).
Native iOS en Android apps ondersteunen wel een extern toetsenbord en kan daarmee de app voor een zeer groot deel bezocht worden. Er zijn hierin een paar twijfelpunten. Ik kan me voorstellen dat we deze twijfelpunten niet afkeuren ALS dit bijvoorbeeld wel met schakelbediening te bereiken is.
Apps ontwikkeld op andere frameworks zoals React Native ondersteunen geen extern toetsenbord, waardoor dit soort apps niet te bedienen zijn. Dit is een technisch probleem, maar heeft de keus voor het framework dan niet meteen impact op de toegankelijkheid? En zegt de wetgeving niet min of meer dat bij een inkoop / aanbesteding gekozen moet worden voor toegankelijke oplossingen? Ik begrijp dat dit leidt tot grote frustraties bij app-ontwikkelaars en productowners, maar bij aanvang van het project is er gekozen voor een ontoegankelijke oplossing, terwijl er ook (beter) toegankelijke oplossingen zijn (native iOS en Android).
Ik vertaal het even naar een website-variant. Stel ik zou er nu voor kiezen om een website te maken met een javascript-library die geen tekstalternatieven ondersteunt, gewoon puur omdat dat er niet technisch in zit. Dan gaan we toch ook niet zeggen dat tekstalternatieven niet meer onderzocht hoeven te worden op alle websites? In dat geval zou je het ook afkeuren en zeg je ook dat de developer een andere keus had moeten maken. Ook hiervan begrijp ik dat het qua tijd, kennis, etc nogal een verschil is of je moet switchen van een andere javascript library voor een specifieke component OF dat je moet wisselen naar een compleet andere app-taal.
JJdeGroot
commented
1 year ago Deze issues zijn vandaag besproken bij het inspectieinstellingenoverleg (mooi galgje woord).
Inzichten:
2.4.7: is technisch haalbaar door het uiterlijk van een element aan te passen bij focus state. Dus dat moeten apps doen. Oplossing: Appt 2.4.7
2.1.1: als een app via 'een manier' volledig met het toetsenbord te bedienen is, dan voldoet dit. Dus het voldoet als je Tab + G + Arrow Key Down nodig hebt om de scrollen, in plaats van alleen Arrow Key Down.
Als een bepaald framework geen ondersteuning heeft voor native API's om het gedrag van toetsenbordbediening aan te passen, dan keur je dit af. Het is aan het framework om ondersteuning toe te voegen, of aan de ontwikkelaars om over te stappen naar een ander framework, of native. Dit heeft grote impact maar bij websites is dit ook zo als je moet overstappen van bijvoorbeeld React naar Angular.
Als het aantoonbaar native niet mogelijk is om bepaald toetsenbordbediening gedrag voor elkaar te krijgen, dan kun je overwegen om het probleem niet af te keuren.
julezrulez
commented
4 months ago Onder SC 2.4.7 staat onder Sufficient Techniques: G165: Using the default focus indicator for the platform so that high visibility default focus indicators will carry over Dat betekent zoveel dat als de ontwikkelaar niets wijzigt aan de focusindicator, dit ook niet afkeurbaar is in een audit. Ik zie daarom het probleem niet en lijkt voorstel 1 niet nodig.
Toetsenbordbediening. Je schrijft: "Gebruikers worden geacht om deze snelkoppelingen te kennen." Dat klopt, en als daarmee elke native component te bedienen is met toetsenbord, dan is er toch geen probleem? Of zijn er native onderdelen op Android of iOS die nooit te bedienen zijn met toetsenbord en waarvoor ook geen alternatief voor wordt aangeboden? Is dat ergens inzichtelijk terug te vinden?
Tot slot: Beschrijf altijd één probleem hier in github - we willen graag een eindoordeel vellen over één probleem. Hierboven worden er nu meerdere beschreven waardoor de discussie alle kanten op gaat en er niet gericht op één probleem ingegaan kan worden en besloten kan worden.
rianrietveld
commented
3 months ago Consensus is bereikt in de meeting van de onderzoeksbureau's op 20 juni '23 Zie comment https://github.com/WCAG-Audit-Discussions/NL-BE/issues/52#issuecomment-1598910471
De onderstaande vraag is ontstaan nav gesprekken met diverse app ontwikkelaars. Zij geven aan dat het werkend krijgen van het externe toetsenbord niet altijd kan.
De EN 301 549 / WCAG 2.1 stelt eisen aan het toetsenbordinterface voor mobiele apps.
De bedoeling van Richtlijn 2.1 Toetsenbordtoegankelijk is om alle functionaliteit beschikbaar te maken via het toetsenbord. Omdat niet alle toestellen een fysiek toetsenbord hebben, wordt de bredere term ‘toetsenbordinterface’ gebruikt.
Toetsenbordinterface
Het toetsenbordinterface omvat toetsaanslagen die afkomstig kunnen zijn van een toetsenbord, maar ook van andere hardware of software die toetsenbordinvoer genereert. Onder het toetsenbordinterface vallen ook hulpmiddelen zoals de schermlezer, stembediening en schakelbediening. Deze hulpmiddelen zijn ingebouwd op zowel Android als iOS.
Extern toetsenbord
Mobiele telefoons hebben een ‘on-screen keyboard’ die je via touchscreen kunt bedienen. Maar het is ook mogelijk om een extern toetsenbord aan te sluiten om te typen. Je kunt ook navigeren via een extern toetsenbord.
Android schrijft: “Android supports physical keyboards attached to the device. A keyboard offers not only a convenient mode for text input, but also offers a way for users to navigate and interact with your app.“
Apple schrijft: “On a Mac, some people prefer using a keyboard instead of a mouse or a trackpad, and VoiceOver users require it. People can also connect an external keyboard to their iPhone, iPad, or TV.”
Toetsenbordbediening
Op Android kun je direct navigeren wanneer je een extern toetsenbord aansluit. Er is geen online handleiding beschikbaar voor Android. Op Android toestellen kun je via Instellingen > Systeem > Toetsenbord > Fysiek toetsenbord een overzicht vinden van snelkoppelingen.
Op iOS kun je navigeren met een extern toetsenbord als je ‘Uitgebreide toetsenbordfuncties’ aan zet. Deze functie is standaard uitgeschakeld. Er is een korte handleiding voor iOS beschikbaar. Op iOS toestellen kun je via Instellingen > Toegankelijkheid > Toetsenborden > Uitgebreide toetsenbordfuncties > Commando’s een overzicht vinden van snelkoppelingen.
Je kunt o.a. navigeren met Tab en de Pijltjestoetsen, en elementen activeren met de Spatiebalk en Enter.
Dit is vergelijkbaar met websites bedienen via een toetsenbord op een computer.
Maar: op Android en iOS zijn er aanvullende snelkoppelingen beschikbaar om apps te bedienen. Deze snelkoppelingen heb je regelmatig nodig om de focus op de juiste plek te krijgen.
Op iOS heb je bijvoorbeeld ‘Ctrl + Tab’ nodig om de focus naar het volgende onderdeel te verplaatsen. Denk bijvoorbeeld aan het verplaatsen van Navigation Bar (navigatiebalk) naar een TableView (lijst), of van een TableView naar een Tab Bar (tabbladen). Deze componenten worden als los benaderbare onderdelen gezien.
Er zijn ook snelkoppelingen beschikbaar om touchgebaren uit te voeren, zoals een ‘veeg gebaar’ om te scrollen in een lijst. Bij een native lijst op iOS kan je niet met de pijltjestoetsen scrollen maar moet je gebruik maken van het veeg omlaag gebaar.
Deze snelkoppelingen zijn nodig wanneer je gebruik maakt van native componenten. Gebruikers worden geacht om deze snelkoppelingen te kennen.
Eisen aan toetsenbordinterface
Uit succescriterium 2.1.1 volgt de eis dat alle functionaliteit met een toetsenbordinterface te bedienen moet zijn.
Uit succescriterium 2.4.7 volgt de eis dat er een focus indicator zichtbaar moet zijn wanneer er een toetsenbordinterface wordt gebruikt.
In WCAG 2.2 volgen extra eisen uit succescriterium 2.4.11, namelijk minimaal 3:1 contrast en de focus indicator moet het element omkaderen.
Focus indicator niet aanpasbaar
App ontwikkelaars kunnen de eigenschappen van de native focus indicator niet aanpassen op Android en iOS. Een app ontwikkelaar kan dus niet zorgen dat de native focus indicator voldoende contrast heeft en kan ook de wijze van omkadering niet aanpassen.
Gebruikers kunnen de kleur wel aanpassen via de systeeminstellingen. Dit geldt op Android en iOS voor alle hulpmiddelen, dus het externe toetsenbord, de schermlezer, stembediening en schakelbediening. Het is voor app ontwikkelaars ook niet mogelijk om uit te lezen welke kleur de gebruiker heeft gekozen.
Voorstel 1: De eisen voor focus indicatoren schrappen voor mobiele apps zolang er geen native API’s beschikbaar zijn gesteld om dit op een behoorlijke wijze te implementeren.
Beperkte ondersteuning extern toetsenbord
Een extern toetsenbord gedraagt zich anders dan andere ingebouwde hulpmiddelen, zoals de schermlezer, stembediening en schakelbediening. Hoe je dit gedrag kan corrigeren is niet, of beperkt gedocumenteerd.
Voor native Android en iOS ontwikkelaars is het hierdoor vrijwel onmogelijk om alle functionaliteit beschikbaar te stellen voor een extern toetsenbord. De ingebouwde apps van Google en Apple zijn zelf ook niet volledig bedienbaar met een extern toetsenbord.
Een aanvullend probleem is dat cross-platform frameworks zoals React Native, Flutter en Xamarin helemaal geen ondersteuning hebben ingebouwd voor het externe toetsenbord. Hierdoor is het voor app ontwikkelaars die hier gebruik van maken onmogelijk om alle functionaliteit beschikbaar te stellen via een extern toetsenbord.
Dit is voor andere hulpmiddelen, zoals de schermlezer, stembediening en schakelbediening wél mogelijk. Zowel voor native Android en iOS apps, als apps ontwikkeld met cross-platform frameworks. Deze hulpmiddelen hebben alle drie hetzelfde, voorspelbare gedrag.
Voorstel 2: De eis om alle functionaliteit van mobiele apps beschikbaar te stellen via een extern toetsenbord schrappen, zolang er geen API’s en documentatie beschikbaar zijn om dit op een behoorlijke wijze te implementeren. Wel moet alle functionaliteit beschikbaar zijn via een andere toetsenbordinterface, zoals de schermlezer, stembediening of schakelbediening.
Conclusie
Bij mobiele apps werkt het externe toetsenbord anders dan bij websites. Het is niet mogelijk om de native focus indicator aan te passen. Het gedrag van het externe toetsenbord is onvoorspelbaar en beperkt te corrigeren.
Voor auditors is het hierdoor niet accuraat vast te stellen of de ontwikkelaar een fout heeft gemaakt, of dat het gedrag veroorzaakt wordt door het besturingssysteem.
Het advies is om de eisen voor focus indicatoren (tijdelijk) te schrappen voor mobiele apps. Daarnaast is het advies om de eisen voor toetsenbordinterfaces (tijdelijk) niet toe te passen op het externe toetsenbord van mobiele apps.
Hierdoor worden apps niet afgekeurd op technische beperkingen van het besturingssysteem of ontwikkelomgeving.
We zijn erg benieuwd naar jullie reactie. Mochten er vragen zijn horen we het graag.
Mede namens Jan Jaap de Groot. Alvast bedankt.