WCAG 2.0: Toegankelijke formulieren
Richtlijn 2.1 Toetsenbordtoegankelijk: Maak alle functionaliteit beschikbaar vanaf een toetsenbord.
Meer specifiek: 2.1.1 Toetsenbord: Alle functionaliteit van de content is bedienbaar via een toetsenbordinterface zonder dat afzonderlijke toetsaanslagen aan tijd gebonden zijn, behalve als de onderliggende functie een invoer vereist die afhangt van het pad dat de gebruiker aflegt en niet alleen van de eindpunten. (Niveau A)
Na deze technisch neutrale richtlijn staan vervolgens bij de Afdoende technieken voorbeelden van HTML, scripting en Flash technieken waarmee je aan deze regel kunt voldoen.
In WCAG 2.0 wordt soepeler omgegaan met het gebruik van Javascript dan in WCAG 1.0. Dit is niet raar als je de uitkomsten ziet van de laatste screenreader-enquête. Hierin komt naar voren dat ruim 98% van de screenreader gebruikers javascript enabled heeft. Daarnaast is er ook qua usability wat voor te zeggen als je bijvoorbeeld in uitgebreide formulieren dynamisch de vragen en keuzemogelijkheden kan aanpassen, zodat ook iemand met een screenreader minder opties hoeft te doorlopen. Voor deze gebruikers is dit zelfs nog handiger, omdat het veel tijd kan schelen.
Hetzelfde geldt voor client-side validation. Via javascript kun je bij een verkeerd ingevuld veld een foutmelding invoegen via de DOM, met daarin een link naar het veld waar het gecorrigeerd moet worden. Zodoende hoef je niet het hele formulier te doorzoeken wanneer je niet in een oogopslag kunt zien waar de fout zit.
Eventueel kan het formulier dan nog uitgebreid worden met WAI-ARIA roles en states zoals 'role=alert' en 'aria-invalid' of 'aria-live'. En/of met HTML5 formuliervalidatie, eventueel met javascript-fallback.
Hoe maken jullie formulieren toegankelijk?
Reacties
- 1 Joko Ruwhof op 18-04-2011 om 11:24 uur:
- Toetsondersteuning. Ik ben er een fan van. Vooral in het gebruiken en stimuleren van veel gebruikte toetscombinaties (die haast tot richtlijnen verworden zijn).
Helaas wordt het door veel klanten niet als belangrijk gezien en is er dus vaak geen geld voor. - 2 Mallory op 18-04-2011 om 13:20 uur:
- Ik ben er met de WCAG eens. Formulieren moet kunnen gebruikt worden via toetsenbord, ja. Dus, help-teksten zitten nog steeds in een anchor bij mij (tekst komt met :focus). Voor velden die moeten verborgen worden, gebruik ik Javascript maar nu heb ik ook een skip link en uitlegtekst voor degene die met screen reader of zonder Javascript het formulier invult (want off-screen positioning of display: none toont nog in sommige screen readers in ieder geval).
Dat 98% van screen reader gebruikers javascript aan hebben maakt helemaal nix voor mij uit: ze moeten kunnen helemaal werken met OF zonder Javascript. Net zoals de rest van mijn pagina's.
De punten over Javascript validation (en/of HTML5 inputs): front-end validation is, geloof ik, een Good Thing: dat maakt alles duidelijker voor klanten, en kunnen zeker maken dat de juiste informatie in de juiste form in de juiste vaakje gaat, de eerste keer.
Je hoeft geen Javascript te hebben om een duidelijk "fout-melding-lijst" te maken, met skip links naar alleen de foute velden (wel, behalve in Safari en Chrome, die domme browsers kunnen geen skip links arg). Dat doe je in ieder geval. Waarom moet een klant doorzoeken? Dat is gewoon goede UI design. - 3 Luc De Brouwer op 18-04-2011 om 13:21 uur:
- Ik probeer eigenlijk ook altijd de WAI-ARIA roles en states er in mee te nemen, het ligt een beetje aan het project.