¿Cómo asegurarte de que tu contribución sea accesible?

Sabes que quieres que tu contribución, ya sea un módulo, iniciativa, tema, parche o núcleo, sea accesible, pero no sabes cómo lograrlo.

El enfoque de BBC Accessibility Champions ha sido muy exitoso, y la comunidad Drupal puede usarlo como base para modelar nuestro propio proceso recomendado. La accesibilidad no es fácil y a menudo requiere creatividad, pruebas y apertura. Es más efectiva y elegantemente lograda cuando forma parte de todo el proceso desde el inicio.

Encuentra un campeón de accesibilidad (A11y) que forme parte de tu equipo (o sé tú mismo)

• Nuestra comunidad está llena de expertos que desean que Drupal sea lo más accesible posible; puedes encontrar campeones en la cola de lanzamiento, hablar con expertos en accesibilidad en campamentos y sprints, o unirte al canal #accessibility en Drupal Slack.
• Ya sea que seas un campeón dedicado o asumas ese rol junto con otras responsabilidades, es importante consultar regularmente con acompañantes para obtener retroalimentación sobre temas y enfoques complejos, y realizaremos horas de oficina mensuales para facilitar esto.
• Realiza regularmente tus propias revisiones de accesibilidad.
• Familiarízate con los fundamentos de WCAG 2.1 y ATAG 2.0.

Programa revisiones de accesibilidad en cada etapa

Todo lo que se integre al núcleo de Drupal debe pasar por el portal de accesibilidad, lo que significa que el administrador de temas de accesibilidad debe aprobarlo. Sin embargo, obtener esta aprobación al final del proyecto, cuando ya estás cerca de terminar, puede ser muy difícil si no has hecho de la accesibilidad parte del proceso desde el principio.

Tu mejor camino hacia la accesibilidad es planificar revisiones regulares con especialistas en soporte de temas. Como mínimo, recomendamos lo siguiente:

1. Revisión de diseño

• Diseño de interacción (incluido el visual).
• Diseño de ingeniería: cómo decidas implementar tus soluciones y código puede afectar significativamente la accesibilidad, y antes de comenzar, vale la pena revisar tu plan con un especialista en accesibilidad para destinatarios.

2. Revisión alfa

El especialista en accesibilidad del tema ha visto tu prototipo y hoja de ruta; el alcance está claro y los problemas de accesibilidad han sido identificados (aunque quizás aún no haya soluciones).
 
3. Revisión beta

Todos los problemas de accesibilidad han sido identificados y sabes cómo serán resueltos (aunque aún pueden no estar corregidos); el especialista en accesibilidad del tema ha aprobado tu enfoque planificado.
 
4. Revisión estable

Todos los problemas de accesibilidad han sido solucionados y verificados satisfactoriamente; el código ha pasado la puerta de accesibilidad para su lanzamiento al núcleo.

Nuestra sugerencia es que te esfuerces por obtener la aprobación oficial del mantenedor del tema de accesibilidad en cada una de estas etapas para facilitar un lanzamiento estable (también conocido como la puerta de acceso para ingresar al núcleo).

¿Pero qué pasa si no empezamos con el camino correcto?

• ¿Y si ya estamos trabajando y no comenzamos con este enfoque?

Empieza tan pronto como puedas. La comunidad está aquí para apoyarte.
 

• ¿Y si no sabemos lo suficiente?

Existen recursos para ayudarte en este camino, y los especialistas en accesibilidad de temas están aquí para ayudar, no para juzgar. También te podemos guiar hacia recursos adicionales.
 

• ¿Y si no podemos encontrar un campeón de accesibilidad?

Si quieres ser tu propio campeón de accesibilidad, encontrarás el rol útil y aprenderás mucho. Pero en el canal #accessibility de Slack hay muchos miembros activos de la comunidad con quienes puedes comenzar.
 

• ¿Y si cometemos errores?

Entonces alguien planteará el tema en la cola de problemas y trabajarás con ellos para resolverlo y mejorar tu trabajo. Eso es algo bueno.

¿Este artículo es para mí?

¿Participas en el desarrollo del núcleo, temas, módulos o parches de Drupal? Si es así, entonces sí, esto es relevante. Drupal se usa a menudo en universidades, gobiernos y grandes instituciones en todo el mundo, muchas de las cuales están legalmente obligadas a proporcionar acceso a tecnologías digitales.

Corregir funcionalidades no accesibles y refactorizar código inaccesible puede ser extremadamente laborioso y/o costoso.

Crear algo accesible desde cero es mucho más elegante, significativamente más fácil y más barato.