Hoe ervoor te zorgen dat jouw bijdrage toegankelijk is

Je weet dat je wilt dat jouw module-/initiatief-/thema-/patch-/core-bijdrage toegankelijk is, maar je weet niet goed hoe je dat moet aanpakken.

De aanpak van BBC Accessibility Champions is zeer succesvol gebleken, en de Drupal-gemeenschap kan deze gebruiken als basis om ons eigen aanbevolen proces te modelleren. Toegankelijkheid is niet eenvoudig en vereist vaak creativiteit, testen en een open houding. Het wordt het meest effectief en elegant bereikt wanneer het vanaf het begin een integraal onderdeel van het hele proces is.

Vind een A11y-kampioen voor je team (of word er zelf een)

• Onze gemeenschap zit vol met experts die willen dat Drupal zo toegankelijk mogelijk is; je kunt kampioenen vinden in de issue queue, praten met toegankelijkheidsexperts op camps en meetups, of deelnemen aan de Drupal Slack en het kanaal #accessibility raadplegen.
• Of je nu een toegewijde kampioen bent of zelf de rol van kampioen op je neemt naast je andere taken, het is belangrijk om regelmatig contact op te nemen met maintainers voor feedback over complexe kwesties en benaderingen. We organiseren ook maandelijkse kantooruren om dit gemakkelijker te maken.
• Voer regelmatig je eigen toegankelijkheidsreviews uit.
• Maak jezelf vertrouwd met de basis van WCAG 2.1 en ATAG 2.0.

Plan toegankelijkheidsreviews op elke fase

Alles wat in de Drupal-core terechtkomt, moet door de toegankelijkheidspoort, wat betekent dat de Accessibility Theme Maintainer het moet goedkeuren. Die goedkeuring pas aan het einde van het project krijgen, als je bijna klaar bent, kan echter erg moeilijk zijn als toegankelijkheid niet vanaf het begin deel van het proces is geweest.

De beste manier om toegankelijkheid te garanderen, is om regelmatige reviews te plannen met de thematische toegankelijkheidsmaintainers. Wij raden ten minste de volgende stappen aan:

1. Ontwerpreview

• Interactieontwerp (inclusief visueel ontwerp)
• Technisch ontwerp: de manier waarop je je oplossingen en code implementeert, kan een grote invloed hebben op de toegankelijkheid. Het is de moeite waard om je plan vooraf te bespreken met een toegankelijkheidsspecialist.

2. Alpha-review

De toegankelijkheidspecialist heeft je prototype en roadmap gezien; de scope is duidelijk en toegankelijkheidsproblemen zijn geïdentificeerd (maar mogelijk nog niet opgelost).

3. Beta-review

Alle toegankelijkheidsproblemen zijn geïdentificeerd en je weet hoe ze worden opgelost (ook al zijn ze nog niet allemaal gefixt); de Accessibility Theme Maintainer heeft je voorgestelde aanpak goedgekeurd.

4. Stable review

Alle toegankelijkheidsproblemen zijn opgelost en succesvol getest; de code heeft de toegankelijkheidspoort voor opname in de core doorstaan.

Ons advies is om te streven naar een formele goedkeuring van de Accessibility Theme Maintainer in elk van deze fasen, om een soepele stabiele release te garanderen (ook bekend als de ‘accessibility gate’ voor opname in core).

Maar wat als we niet goed zijn begonnen?

• Wat als we al bezig zijn en niet met deze aanpak zijn gestart?

Begin zo snel mogelijk. De gemeenschap is er om je te ondersteunen.

• Wat als we niet genoeg weten?

Er zijn bronnen die je kunnen helpen, en de Accessibility Theme Maintainers zijn er om te ondersteunen, niet om te oordelen. We kunnen je ook naar nuttige bronnen verwijzen.

• Wat als we geen toegankelijkheidskampioen kunnen vinden?

Als je je eigen toegankelijkheidskampioen wilt worden, is dat een waardevolle en leerzame rol. Bovendien is er veel activiteit in het #accessibility-kanaal op Slack — een goed startpunt.

• Wat als we fouten maken?

Dan zal iemand het probleem aankaarten in de issue queue, en werk je samen om uit te zoeken hoe je het kunt oplossen en je werk nog beter kunt maken. Dat is iets positiefs.

Is dit artikel relevant voor mij?

Ben je betrokken bij de ontwikkeling van Drupal core, thema’s, modules of patches? Dan ja — dit is relevant voor jou. Drupal wordt vaak gebruikt door universiteiten, overheden en grote instellingen wereldwijd, waarvan velen wettelijk verplicht zijn digitale toegankelijkheid te bieden.

Het herstellen van ontoegankelijke functies en het refactoren van ontoegankelijke code kan extreem tijdrovend en kostbaar zijn.

Het vanaf het begin bouwen van iets dat toegankelijk is, is veel eleganter, eenvoudiger en goedkoper.