Patrones, componentes y sistemas de diseño

Muchas personas usan el desarrollo basado en componentes mediante 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 utilices un proceso similar para dividir un diseño grande de un sitio web, una app o algún otro producto digital en partes manejables.

Al igual que construir una estructura física, es importante construir de a una pieza por vez. Primero, los cimientos, la estructura, las paredes, las ventanas, el techo y todo lo demás. Las herramientas de desarrollo basadas en componentes nos permiten hacer esto para sitios web, aplicaciones y otros productos digitales.

Algunos de los beneficios del desarrollo basado en componentes incluyen el desglose en partes manejables, por lo que hay menos tiempo de desarrollo con estos componentes reutilizables. Permite a los diseñadores, desarrolladores de frontend y backend y QA trabajar de forma simultánea. Y a los clientes, diseñadores, gerentes de proyectos y demás les gusta porque pueden obtener una vista previa del proceso de compilación y usar una guía de estilo real como referencia después del lanzamiento del sitio web.

Sin embargo, cuando analizamos los patrones, los componentes y los sistemas de diseño teniendo en cuenta la accesibilidad, surgen algunas preguntas. ¿Cómo sabes qué patrones son mejores en lo que respecta a accesibilidad? ¿Deberías usar un patrón o una biblioteca establecidos o crear nuevos? ¿Cómo sabes si estos patrones realmente ayudarán a tus usuarios?

Con la gran cantidad de opciones disponibles, es fácil confundirse rápidamente sobre este tema. El objetivo de este módulo es brindarte información general sobre cómo evaluar patrones, componentes y sistemas de diseño para mejorar la accesibilidad. Además, te brinda un punto de partida para ayudarte a tomar decisiones más accesibles.

Pensar críticamente

Elegir un patrón, componente o sistema de diseño accesible no es una ciencia impresionante, pero requiere tiempo y pensamiento crítico. De hecho, no existe "un patrón perfecto", pero puede haber muchas opciones que podrían funcionar. Se trata de aprender a elegir la mejor opción según tu situación particular.

En los módulos de prueba posteriores, aprenderás más sobre las técnicas y los métodos para evaluar patrones, componentes y sistemas de diseño con fines de accesibilidad. Pero antes de esa etapa, debes dar un paso atrás y hacerte algunas preguntas fundamentales, como las siguientes:

  • ¿Ya existe un patrón, componente o sistema de diseño accesible establecido?
  • ¿Con qué navegadores y tecnologías de asistencia (AT) admito?
  • ¿Existe alguna limitación de código, framework o alguna otra integración, factor o necesidad de los usuarios que deba considerar?

En función de tu entorno de desarrollo y las necesidades de los usuarios, es posible que tengas preguntas adicionales o diferentes. Considera estas preguntas como punto de partida en tu evaluación de accesibilidad.

Recursos establecidos

Antes de crear algo nuevo, ten 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 múltiples) que se ajuste a tus necesidades.

Algunos grandes recursos para patrones, componentes y sistemas de diseño accesibles incluyen:

Para los frameworks de JavaScript, los siguientes recursos son bastante accesibles de inmediato o son fáciles de personalizar para mejorar la accesibilidad:

Sin embargo, y esto no es lo suficientemente estresado, nunca debes simplemente copiar y pegar código, y suponer que se ajustará a tu entorno y satisfará automáticamente las necesidades de los usuarios. Esto se aplica a todos los patrones, componentes y sistemas de diseño, incluso si están etiquetados como totalmente accesibles.

Todos los recursos deben considerarse como 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 en tu entorno de desarrollo, puedes pasar a la asistencia tecnológica de asistencia. Un tipo principal de AT en el que querrás enfocarte cuando evalúes los patrones, los componentes y los 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 vinculan con ellos. Abordaremos este tema con mucho más detalle en el módulo sobre las pruebas de AT, pero para fines de evaluación de patrones, es útil entender que estas combinaciones existen, de modo que sepas lo que necesitas en términos de asistencia.

Lector de pantalla SO Compatibilidad del navegador Costo
Acceso a trabajos con voz (JAWS) Windows Chrome, Firefox y Edge Requerimiento de licencia (existe una versión gratuita de 40 minutos)
Acceso no visual al escritorio (NVDA) Windows Chrome y Firefox Gratuito (requiere descarga)
Narrador Windows Conexión de integración Gratis (integrado en los equipos de Windows)
VoiceOver macOS Safari Gratis (integrado en máquinas macOS)
Orca Linux Firefox Gratis (integrado en las distribuciones basadas en Gnome)
TalkBack Android Chrome y Firefox Gratuito (integrado en algunas versiones del SO Android)
VoiceOver iOS Safari Gratis (integrado en dispositivos iOS)

La compatibilidad con navegadores suele ser complicada, y las cosas se complican aún más cuando se agregan dispositivos AT y especificaciones ARIA a la combinación.

Pero no todo son malas noticias. Afortunadamente, hay excelentes recursos, como la accesibilidad de HTML5, la Asistencia de accesibilidad y la Lista de tareas para el desarrollo accesible del control personalizado de WCAG, que nos ayudan a comprender mejor la compatibilidad actual con el navegador y el dispositivo de AT, y a saber 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 o dispositivos de AT (para navegadores móviles y de escritorio). Como tales, estos recursos pueden ayudarte a tomar una decisión más accesible con respecto a los patrones, componentes y sistemas de diseño que quieras 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 cuanto a los patrones que puedes usar. Tras la revisión, varias opciones de patrones pueden cortarse rápidamente en una o dos opciones.

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.

Existen consideraciones adicionales que debes tener en cuenta cuando eliges un patrón, componente o sistema de diseño, como las siguientes:

  • Rendimiento
  • Seguridad
  • Optimización para motores de búsqueda
  • Compatibilidad con traducción de idiomas
  • Integraciones de terceros

Sin duda, estos factores influirán en la elección del patrón, pero también debes considerar 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 posible limitación en torno al contenido generado por editores o usuarios. Además, se debe compilar de manera que los desarrolladores con todos los conocimientos sobre accesibilidad puedan usarlo.

Verifica tus conocimientos

Pon a prueba tus conocimientos sobre patrones

¿Los componentes accesibles siempre permanecen accesibles para los usuarios?

Sí, puedes usar estos componentes sin trabajo adicional.
Si bien es más probable que un recurso creado para la accesibilidad funcione automáticamente que otros, es esencial que sigas realizando pruebas de accesibilidad para asegurarte de que estos componentes funcionen para tus usuarios.
No, primero debes probar los componentes.
Incluso se deben probar los componentes y patrones diseñados para la accesibilidad. Es posible que sea inaccesible en combinación con otros componentes existentes.