Weekly Nerd 2: Enhancing Website Accessibility

Fenna de Wilde heeft zelf ook Communicatie & Multimedia Design gestudeerd en daarbij ook de minor Web Development & Design gevolgd. Nu werkt ze als creative developer bij Bakken & Baeck, een tech en design bedrijf. Fenna vertelde hoe toegankelijkheid vaak wordt vergeten en als niet belangrijk wordt gezien. “Er is heel veel mogelijk om mooie dingen te maken, maar gebruikers moeten het wel kunnen gebruiken” zegt Fenna. Vaak geven bedrijven hier niet om, dan is het belangrijk om te laten zien hoe belangrijk het is. In deze weekly nerd, gaf Fenna hier een aantal voorbeelden van.

We bekeken de voorbeelden op basis van de website voor Phantom (een crypto wallet), die Fenna heeft gemaakt. De tech stack die ze gebruikt heeft is: NextJS, Emotion voor styling, Senity als CMS, en Framer Motion voor animaties.

Focus State

De focus state is zo'n voorbeeld van iets wat vaak wordt vergeten of expres verwijderd. Maar niet iedereen kan een muis gebruiken en je moet kunnen zien waar je bent. Dat de focus expres wordt verwijderd komt meestal omdat de focus-state ook verschijnt als je met een muis iets focust. Hiervoor kan je :focus-visible gebruiken, die is alleen voor met toetsenbord. De gewone :focus is ook voor met muis.

Fenna maakt een standaard focus-state, zodat alle elementen in ieder geval een focus-state hebben. Dit doet ze voor alle elementen die niet de class .custom-focus hebben.

*:focus-visible:not(.custom-focus) {
    outline: 4px solid var(--red);
    border-radius: 32px;
}

Zo kan ze vervolgens element een eigen specifieke focus opmaak geven met de .custom-focus class.

Dit vind ik eigenlijk wel een hele handige manier, omdat je echt alleen de focus van elementen opmaakt die niet hun eigen specifieke focus state hebben. Tot nu toe liet ik dit soort dingen altijd aan specificity over, maar dat betekende dat de selectoren van je specifieke focus-states altijd specifieker moeten zijn dan de standaard focus-state. Al zegt de naam specifieke focus-state misschien wel dat ze dat toch bijna altijd wel zijn.

ARIA

ARIA is om aanvullende informatie te geven voor hulp technologieën. Fenna gaf wat voorbeelden die ze gebruikt:

aria-label is voor beschrijvende tekst. Bijvoorbeeld voor icoontjes of logos. Dit kan ook state afhankelijk zijn en worden aangepast met JavaScript
aria-controls is om aan te geven dat elementen in verbinding staan. Dit zet je op een element wat een ander element aanstuurt.
aria-expended geeft aan dat het gekoppelde element uitgeklapt is of niet.
aria-live geeft aan of een element gaat veranderen of niet. Dit kan drie waardes hebben: off betekend dat het niet veranderd, polite betekend dat de hulptechnologie eerst mag afmaken waar het mee bezig is en dan update geeft en assertive geeft aan de hulptechnologie gelijk de update aan moet geven.
aria-atomic gaat samen met aria-live en geeft aan hoe de verandering moet worden aangegeven. Als de waarde true is, betekent het dat het hele element opnieuw moet worden gelezen, in plaats van alleen de verandering

Vaak gaan verschillende aria-attributen samen.

Toegankelijke carrousel

Volgens Fenna zijn carrousels voor toegankelijkheid het vreselijkste wat er is. Ook al ben ik het hier mee eens, denk ik toch dat we ze daarom niet minder zouden moeten gebruiken. Visueel vind ik ze namelijk wel heel erg handig. Daarom zouden we ze zo goed mogelijk toegankelijk kunnen maken. Fenna geeft de volgens haar beste oplossing:

Gebruik een section of role="region" voor de container en geef die een aria-roledescription="carrousel".
Geef de slides die niet zichtbaar zijn aria-hidden en update dit met JavaScript wanneer ze wel zichtbaar worden.
Gebruik geen lijst met list items, want het aantal list items, wat dan wordt voorgelezen door de screenreader, komt dan niet meer overeen met het daadwerkelijk aantal list items.
Gebruik aria-controls op de knoppen van de carrousel zoals de pijltjes en de stipjes. De knoppen die actief zijn, geef je een aria-disabled.

<section aria-roledescription="carrousel" id="carrousel">
    <div class="slide"><img src="https://unsplash.it/640/360?image=0" alt=""></div>
    <div class="slide"><img src="https://unsplash.it/640/360?image=10" alt=""></div>
    <div class="slide"><img src="https://unsplash.it/640/360?image=20" alt=""></div>
    <div class="controls">
        <button aria-label="vorige dia" aria-controls="carrousel" id="prev">◀︎</button>
        <div>
            <button aria-label="dia 1" aria-controls="carrousel">◎</button>
            <button aria-label="dia 2" aria-current="dia" aria-controls="carrousel" aria-disabled="true">◉</button>
            <button aria-label="dia 3" aria-controls="carrousel">◎</button>
        </div>
        <button aria-label="volgende dia" aria-controls="carrousel" id="next">▶︎</button>
        </div>
</section>

Tips

Verder geeft Fenna nog een paar algemene tips voor toegankelijkheid.

Leesbaarheid

Let voor zichtbaarheid op kleurcontrasten en lettergroottes. Voor contrast is een formule waarbij zwart-op-wit 21 op 1 is. Tekst moet minimaal 4,5 op 1 zijn. Dit kan je simpel checken in de dev-tools van je browser, die geeft aan of het wel of niet goed is. Hier kan je ook de lettergrootte zien, die moet minimaal 16 pixels zijn. Hierbij is ook de regellengte belangrijk, die moet tussen 50 en 75 karakters lang zijn.

Semantiek voor de screenreader

Goede semantiek is belangrijk voor de screenreader. Fenna's tip is om zelf de screenreader te gebruiken om te controleren of de semantiek goed is.