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 forma formal, es probable que uses un proceso similar para dividir un diseño grande de un sitio web, una app o cualquier otro producto digital en partes fáciles de manejar.
Al igual que cuando se construye una estructura física, es importante crear una pieza a la vez. Primero, los cimientos, la estructura, las paredes, las ventanas, el techo y todo lo que hay en medio. Las herramientas de desarrollo basadas en componentes nos permiten hacer esto para sitios web, apps y otros productos digitales.
Algunas de las ventajas del desarrollo basado en componentes incluyen dividir los elementos en partes fáciles de administrar, de modo que se dedique menos tiempo al desarrollo con estos componentes reutilizables. Permite que los diseñadores, los desarrolladores de frontend y backend, y el control de calidad trabajen de forma simultánea. A los clientes, diseñadores, PM 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 patrones, componentes y sistemas de diseño teniendo en cuenta la accesibilidad, surgen algunas preguntas. ¿Cómo sabes cuáles son los mejores patrones en términos de accesibilidad? ¿Debes usar un patrón o una biblioteca establecidos, o crear otros nuevos? ¿Cómo sabes si estos patrones realmente ayudarán a tus usuarios?
Con la gran cantidad de opciones disponibles, es fácil confundirse 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 te ofrece 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 pruebas posteriores, obtendrás más información 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ía de accesibilidad (AT) admito?
- ¿Hay limitaciones de código o framework? ¿Hay otras integraciones, factores o necesidades de los usuarios que deba tener en cuenta?
Según tu entorno de desarrollo y las necesidades de los usuarios, es posible que tengas preguntas adicionales o distintas a estas. Considera estas preguntas como tu punto de partida en la evaluación de accesibilidad.
Recursos establecidos
Antes de crear algo nuevo, haz tu debida diligencia y revisa lo que ya existe en términos de patrones, componentes y sistemas de diseño accesibles. Con un poco de investigación, es posible que te sorprendas al encontrar una solución (o varias) que se adapte a tus necesidades.
Estos son algunos recursos excelentes para patrones, componentes y sistemas de diseño accesibles:
- Componentes accesibles
- Biblioteca ARIA de Deque University
- Sistema de diseño de Gov.UK
- Componentes inclusivos
- MagentaA11y
- Sistema de diseño web de EE.UU. (USWDS), creado para el gobierno federal de Estados Unidos
- Lista de patrones accesibles de Smashing Magazine
En el caso de los frameworks de JavaScript, los siguientes recursos son bastante accesibles de forma predeterminada o se pueden personalizar para la accesibilidad:
- Cuando CSS no es suficiente: requisitos de JavaScript para componentes accesibles
- React
- Angular: Biblioteca de Material
- Vue: Vuetensils
Sin embargo, y no podemos enfatizarlo lo suficiente, nunca debes copiar y pegar código y suponer que se ajustará a tu entorno y satisfará automáticamente las necesidades de los usuarios. Esto es cierto para todos los patrones, componentes y sistemas de diseño, incluso si están etiquetados como completamente accesibles.
Todos los recursos deben considerarse un punto de partida. Asegúrate de probar todo.
Compatibilidad con navegadores y tecnología de accesibilidad (AT)
Después de investigar algunos patrones básicos, componentes o un sistema de diseño completo que podría funcionar para tu entorno de desarrollo, puedes pasar a la compatibilidad con la tecnología de accesibilidad. Un tipo importante de AT en el que te debes enfocar 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 usan con ellos. Analizaremos este tema con mucho más detalle en el módulo sobre pruebas de AT, pero, a los efectos de la evaluación de patrones, es útil comprender que existen estas combinaciones para que sepas qué necesitas en términos de asistencia.
| Lector de pantalla | SO | Compatibilidad del navegador | Costo |
|---|---|---|---|
| Job Access with Speech (JAWS) | Windows | Chrome, Firefox y Edge | Se requiere una licencia (existe una versión gratuita de 40 minutos) |
| Acceso a escritorio no visual (NVDA) | Windows | Chrome y Firefox | Gratis (requiere descarga) |
| Narrador | Windows | Edge | Gratuito (integrado en máquinas de Windows) |
| VoiceOver | macOS | Safari | Sin cargo (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 complican aún más cuando se agregan dispositivos de accesibilidad y especificaciones de ARIA.
Pero no todo son malas noticias. Por suerte, existen excelentes recursos, como Accesibilidad de HTML5, Compatibilidad con accesibilidad y la Lista de tareas de desarrollo accesible para controles personalizados del WCAG, que nos ayudan a comprender mejor la compatibilidad actual con navegadores y dispositivos de AT, y hasta cuándo usar ARIA.
En estos recursos, se 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 computadoras de escritorio, navegadores para 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 podrías querer usar.
Otras consideraciones
Una vez que hayas elegido algunos patrones o componentes básicos accesibles y hayas tenido en cuenta la compatibilidad con el navegador y el dispositivo de 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 (CMS) o tienes código heredado, es posible que haya algunas limitaciones en los patrones que puedes usar. Después de la revisión, es posible que varias opciones de patrones se reduzcan rápidamente a una o dos.
Muchos frameworks de JavaScript permiten a los desarrolladores usar 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
Sin duda, estos factores 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 en sí. El patrón que elijas debe ser lo suficientemente sólido como para manejar cualquier limitación potencial en torno al contenido generado por el editor o por el usuario, además de compilarse de una manera que puedan usar los desarrolladores con todo el conocimiento de accesibilidad.
Verifica tu comprensión
Pon a prueba tus conocimientos sobre los patrones
¿Los componentes accesibles siempre son accesibles para los usuarios?