Muchas personas usan el desarrollo basado en componentes con guías de estilo de patrones, bibliotecas de componentes o sistemas de diseño completos en su proceso de flujo de trabajo de desarrollo. Incluso si no usaste estas herramientas de manera formal, es probable que uses un proceso similar para dividir un diseño grande para un sitio web, una app o algún otro producto digital en partes manejables.
Al igual que cuando se construye una estructura física, es importante construir una pieza a la vez. Primero, los cimientos, la estructura, las paredes, las ventanas, el techo y todo lo demás. Las herramientas de desarrollo basado en componentes nos permiten hacer esto para sitios web, apps y otros productos digitales.
Algunas ventajas del desarrollo basado en componentes incluyen dividir las cosas en partes manejables, por lo que hay menos tiempo de desarrollo con estos componentes reutilizables. Permite que los diseñadores, los desarrolladores de frontend y backend, y el equipo de QA trabajen de forma simultánea. A los clientes, diseñadores, administradores de proyectos y otros les gusta porque pueden obtener una vista previa del proceso de compilación y usar una guía de estilo dinámica como referencia después de que se lanza el sitio web.
Sin embargo, cuando observamos los patrones, los componentes y los sistemas de diseño teniendo en cuenta la accesibilidad, surgen algunas preguntas. ¿Cómo sabes qué patrones son los mejores cuando se trata de accesibilidad? ¿Deberías usar un patrón o una biblioteca establecidos, o crear unos nuevos? ¿Cómo sabes si estos patrones realmente ayudarán a tus usuarios?
Con la gran cantidad de opciones disponibles, es posible que te confundas con los patrones, los componentes y los sistemas de diseño. El objetivo de este módulo es brindarte información general sobre cómo evaluar patrones, componentes y sistemas de diseño para la accesibilidad, y darte un punto de partida para ayudarte a tomar decisiones más accesibles.
Piensa de forma crítica
Elegir un patrón, un componente o un sistema de diseño accesible no es ciencia espacial, pero requiere tiempo y pensamiento crítico. De hecho, no existe un "patrón perfecto", pero es posible que haya muchas opciones que podrían funcionar. Se trata de aprender a elegir la mejor opción para tu situación única.
En los módulos de prueba posteriores, leerás más sobre las técnicas y los métodos para evaluar patrones, componentes y sistemas de diseño para la accesibilidad. Antes de llegar allí, debes hacerte algunas preguntas fundamentales, como las siguientes:
- ¿Ya existe un patrón, un componente o un sistema de diseño accesible establecido?
- ¿Qué navegadores y tecnologías de accesibilidad (AT) admito?
- ¿Hay limitaciones de código o framework? ¿Hay otras integraciones, factores o necesidades del usuario que deba tener en cuenta?
Según tu entorno de desarrollo y las necesidades del usuario, es posible que tengas preguntas adicionales o diferentes a estas. Considera estas preguntas como tu punto de partida en la evaluación de accesibilidad.
Recursos establecidos
Antes de crear algo nuevo, haz la diligencia debida y revisa lo que ya existe en términos de patrones, componentes y sistemas de diseño accesibles. Con solo un poco de investigación, es posible que te sorprenda encontrar una solución (o varias) que se adapte a tus necesidades.
Algunos recursos excelentes para patrones, componentes y sistemas de diseño accesibles incluyen los siguientes:
- Accessible Components
- Deque University ARIA library
- Gov.UK Design System
- Inclusive Components
- MagentaA11y
- U.S. Web Design System (USWDS), creado para el gobierno federal de los Estados Unidos
- List of accessible patterns from Smashing Magazine
En el caso de los frameworks de JavaScript, los siguientes recursos son bastante accesibles de forma predeterminada o personalizables para la accesibilidad:
- When CSS Isn't Enough: JavaScript Requirements For Accessible Components
- React
- Angular: Material library
- Vue: Vuetensils
Sin embargo, y esto no se puede enfatizar lo suficiente, nunca debes copiar y pegar código y suponer que se ajustará a tu entorno y satisfará automáticamente las necesidades del usuario. Esto se aplica a todos los patrones, componentes y sistemas de diseño, incluso si se etiquetan como completamente accesibles.
Todos los recursos deben considerarse como un punto de partida. Asegúrate de probar todo.
Compatibilidad con navegadores y tecnologías de accesibilidad (AT)
Después de investigar algunos patrones base, componentes o un sistema de diseño completo que podría funcionar para tu entorno de desarrollo, puedes pasar a la compatibilidad con tecnologías de accesibilidad. Un tipo importante de AT en el que te enfocarás cuando evalúes patrones, componentes y sistemas de diseño son los lectores de pantalla.
Los lectores de pantalla se crearon teniendo en cuenta navegadores específicos y funcionan mejor cuando se combinan con ellos. Abordaremos este tema con mucho más detalle en el módulo sobre pruebas de AT, pero, para fines de evaluación de patrones, es útil comprender que existen estas combinaciones, de modo que sepas lo que necesitas en términos de compatibilidad.
| Lector de pantalla | SO | Compatibilidad del navegador | Costo |
|---|---|---|---|
| Job Access with Speech (JAWS) | Windows | Chrome, Firefox, Edge | Requiere licencia (existe una versión gratuita de 40 minutos) |
| Non-Visual Desktop Access (NVDA) | Windows | Chrome y Firefox | Gratuito (requiere descarga) |
| Narrador | Windows | Edge | Gratuito (integrado en máquinas Windows) |
| VoiceOver | macOS | Safari | Gratuito (integrado en máquinas macOS) |
| Orca | Linux | Firefox | Gratuito (integrado en distribuciones basadas en Gnome) |
| TalkBack | Android | Chrome y Firefox | Gratuito (integrado en ciertas versiones del SO Android) |
| VoiceOver | iOS | Safari | Gratuito (integrado en dispositivos iOS) |
La compatibilidad con navegadores suele ser complicada, y las cosas se vuelven aún más difíciles cuando agregas dispositivos AT y especificaciones ARIA a la mezcla.
Pero no todo son malas noticias. Afortunadamente, excelentes recursos como HTML5 Accessibility, Accessibility Support y WCAG's Custom Control Accessible Development Checklist nos ayudan a comprender mejor la compatibilidad actual con navegadores y dispositivos AT, e incluso cuándo usar ARIA en primer lugar.
Estos recursos describen los diferentes subelementos de patrones HTML y ARIA disponibles, incluidas las pruebas de la comunidad de código abierto. También puedes revisar algunos ejemplos de patrones para navegadores de computadoras, dispositivos móviles y dispositivos AT. Por lo tanto, estos recursos pueden ayudarte a tomar una decisión más accesible con respecto a los patrones, los componentes y los sistemas de diseño que quizás quieras usar.
Otras consideraciones
Una vez que hayas elegido algunos patrones o componentes base accesibles y hayas tenido en cuenta la compatibilidad con navegadores y dispositivos AT, puedes pasar a preguntas contextuales más específicas sobre el patrón, el componente, el sistema de diseño y el entorno de desarrollo.
Por ejemplo, si trabajas en un sistema de administración de contenido (CMS) o tienes código heredado, es posible que haya algunas limitaciones en cuanto a los patrones que puedes usar. Tras la revisión, varias opciones de patrones pueden reducirse rápidamente a una o dos opciones.
Muchos frameworks de JavaScript permiten que los desarrolladores usen casi cualquier patrón que elijan. En casos como estos, es posible que tengas menos restricciones y puedas elegir la opción de patrón más accesible.
Hay consideraciones adicionales que debes tener en cuenta cuando elijas un patrón, un componente o un sistema de diseño, como las siguientes:
- Rendimiento
- Seguridad
- Optimización para motores de búsqueda
- Compatibilidad con la traducción de idiomas
- Integraciones de terceros
Estos factores sin duda influirán en tu elección de patrones, pero también debes tener en cuenta a las personas que crean el contenido y el código. El patrón que elijas debe ser lo suficientemente sólido como para controlar las posibles limitaciones en torno al contenido generado por el editor o el contenido generado por usuarios, además de estar creado de manera que los desarrolladores de todos los conocimientos de accesibilidad puedan usarlo.