Comment s’assurer que votre contribution est accessible

Vous savez que vous souhaitez que votre contribution (module, initiative, thème, patch ou noyau) soit accessible, mais vous ne savez pas comment vous y prendre.

L’approche des BBC Accessibility Champions a été très réussie, et la communauté Drupal peut s’en inspirer pour modéliser notre propre processus recommandé. L’accessibilité est complexe, demandant souvent créativité, tests et ouverture. Elle est plus efficace et élégante quand elle fait partie intégrante du processus dès le début.

Trouvez un champion A11y au sein de votre équipe (ou soyez le vôtre)

• Notre communauté regorge d’experts souhaitant rendre Drupal aussi accessible que possible ; vous pouvez trouver des champions dans les files de commit, échanger avec des experts accessibilité lors de camps et sprints, ou rejoindre le canal #accessibility sur Slack.
• Que vous soyez un champion dédié ou que vous portiez ce rôle en plus de vos autres responsabilités, il est important de solliciter régulièrement des retours sur les questions complexes et les approches envisagées. Des heures de travail mensuelles sont organisées pour faciliter cela.
• Réalisez régulièrement vos propres revues d’accessibilité.
• Familiarisez-vous avec les bases de WCAG 2.1 et ATAG 2.0.

Planifiez les vérifications d’accessibilité à chaque étape

Tout ce qui entre dans le noyau Drupal doit passer par la porte d’accès aux fonctionnalités, ce qui signifie que le responsable du thème accessibilité doit le valider. Obtenir cette validation à la fin d’un projet peut être difficile si l’accessibilité n’a pas été intégrée dès le départ.

Votre meilleure approche est de planifier des revues régulières avec les spécialistes accessibilité des thèmes. Nous recommandons au minimum :

1. Revue de design

• Design d’interaction (y compris visuel)
• Architecture technique : la façon dont vous implémentez votre code peut fortement influencer l’accessibilité, donc soumettez votre plan à un spécialiste accessibilité avant de commencer.

2. Revue alpha

Le spécialiste accessibilité a vu votre prototype et la roadmap ; le périmètre est clair, les problèmes d’accessibilité identifiés (sans nécessairement les solutions).

3. Revue bêta

Tous les problèmes sont identifiés, vous savez comment les résoudre (même si ce n’est pas encore fait) ; le spécialiste a validé votre approche.

4. Revue stable

Tous les problèmes d’accessibilité sont corrigés et vérifiés ; le code a passé la porte d’accessibilité pour intégration dans le noyau.

Nous vous encourageons à viser une validation officielle par le responsable accessibilité du thème à chacune de ces étapes, pour faciliter la validation finale (aussi appelée porte d’accès pour le noyau).

Et si nous n’avons pas commencé dans les règles ?

• Si votre travail est déjà en cours sans cette approche :

Commencez le plus tôt possible. La communauté est là pour vous soutenir.

• Si vous manquez de connaissances :

Des ressources existent pour vous accompagner, et les spécialistes accessibilité du thème sont là pour aider, pas pour juger. Ils pourront aussi vous orienter vers d’autres ressources.

• Si vous ne trouvez pas de champion accessibilité :

Si vous voulez devenir champion vous-même, le rôle est enrichissant et formateur. Sinon, le canal #accessibility sur Slack est très actif, un bon point de départ.

• Si vous faites des erreurs :

Alors quelqu’un soulèvera un problème sur la file, et vous collaborerez pour corriger et améliorer votre travail. C’est positif.

Cette page est-elle pour moi ?

Vous participez au développement du noyau, de thèmes, modules, ou patchs Drupal ? Alors oui, ce guide est pertinent. Drupal est largement utilisé par des universités, gouvernements et grandes institutions, soumis à des obligations légales d’accessibilité.

Corriger du code non accessible ou refondre une fonctionnalité inaccessible peut être très coûteux et long.

Créer dès le départ un contenu accessible est beaucoup plus élégant, simple et économique.