Por qué el cumplimiento de la Sección 508 es en realidad solo una mejor ingeniería

etiquetas `` a una licuadora y presionó Pulse. La llamamos «sopa de div». Es un lío para los desarrolladores mantenerlo, pero para alguien que usa un lector de pantalla, es una auténtica pesadilla. Cuando hablamos del cumplimiento de la Sección 508, la gente suele empezar a quejarse de las listas de verificación y los requisitos legales. Lo tratan como un impuesto que tienen que pagar para trabajar con el gobierno federal.

Pero nosotros lo vemos de manera diferente.

Si tu sitio no cumple con la normativa 508, básicamente no funciona. No publicarías un sitio en el que el botón «Enviar» no funcione para los usuarios de Chrome, ¿verdad? Entonces, ¿por qué está bien publicar un sitio web que no funciona para los usuarios que utilizan un teclado o una pantalla braille? La sección 508 no es una capa adicional de funciones que sea agradable tener. Es la base del software funcional. En Sweent LLC, hemos creado muchos sistemas de nivel empresarial, desde herramientas de parches para dispositivos médicos para Kaiser Permanente hasta sitios web de marketing para Deloitte, y la lección es siempre la misma: código accesible es mejor código.

¿De qué estamos hablando en realidad?

La sección 508 es parte de la Ley de Rehabilitación de 1973. Establece que las agencias federales tienen que hacer que su tecnología electrónica y de la información sea accesible para las personas con discapacidades. En el mundo web, esto generalmente significa seguir las Pautas de accesibilidad al contenido web (WCAG).

Para una empresa como la nuestra, este es nuestro sustento. Somos una pequeña empresa propiedad de veteranos discapacitados en el servicio militar (SDVOSB) y tenemos un contrato con la GSA MAS (47QRAA25D0024). Cuando construimos para el gobierno, cumplir con las normas 508 no es una sugerencia. Es la ley. Pero incluso si no busca contratos federales, los principios en los que se basa la 508 hacen que su software sea mejor para todos.

Piénsalo. ¿Alguna vez has intentado usar tu teléfono a plena luz del sol y no has podido ver el texto de bajo contraste? Se trata de un problema de accesibilidad. ¿Alguna vez has tenido una lesión temporal y has tenido que navegar por un sitio web con una sola mano? Problema de accesibilidad. Un mejor contraste y unos métodos abreviados de teclado ayudan a todos, no solo a las personas con discapacidades permanentes. Es la versión digital de un bordillo cortado en una acera. Fue diseñado para sillas de ruedas, pero también facilita la vida de las personas con cochecitos, patinetas y equipaje pesado.

La colina semántica del HTML en la que moriré

Uno de los mayores favores que puedes hacer por tu yo futuro es usar HTML semántico. Es la forma más fácil de lograr el 70% del cumplimiento sin siquiera intentarlo. Lo vemos todo el tiempo: los desarrolladores quieren que un botón tenga un aspecto determinado, por lo que escriben una <div> y añaden un controlador de clics.

<div class="my-custom-button" onclick="submitForm()">
 </div>Enviar

Para un usuario vidente con un ratón, parece un botón. Sin embargo, un lector de pantalla ve un contenedor genérico. No sabe que es interactivo. No aparecerá en la lista de botones. Tendrías que añadir manualmente tabindex="0", role="button" y gestionar los eventos clave «Enter» y «Space» para que funcione como... un botón.

O puedes simplemente usar la etiqueta ``.

<button class="my-custom-button" type="submit">
 </button>Enviar

El navegador ya sabe cómo manejar un botón. De forma predeterminada, se puede acceder a él con el teclado. Tiene incorporados los roles correctos. Esto es lo que quiero decir cuando digo que el cumplimiento de las normas 508 es simplemente una buena ingeniería. Estás usando las herramientas de la manera en que fueron diseñadas para usarse. Cuando apoyábamos al equipo de marketing empresarial de Deloitte, traducir diseños de Figma de alta fidelidad a código significaba garantizar que cada «botón» fuera en realidad un botón, no un espacio estilizado que no superara una auditoría.

Y va más allá de los botones. Si usas

para tus menús, <main> para tu contenido principal y <header> para tu marca, el navegador tiene un mapa. Cuando los usas correctamente, no solo ayudas a los lectores de pantalla, sino que haces que el código sea más fácil de leer para otros desarrolladores. Puedo ver un archivo HTML bien estructurado y saber exactamente lo que está sucediendo sin tener que abrir un navegador. Esto ahorra tiempo y dinero durante el mantenimiento.

La prueba sin ratón

He aquí un experimento rápido. Ve a tu proyecto actual, coloca el ratón en el suelo e intenta completar un flujo de usuario principal usando solo las teclas «Tab» e «Enter».

¿Puedes ver dónde está el foco? Si has ocultado el anillo de enfoque porque tu diseñador pensó que tenía un aspecto «feo», ya has fallado. Si el foco pasa del encabezado al pie de página y luego vuelve a la barra lateral, tu orden de DOM es un desastre.

Nos topamos con esto mientras trabajábamos en un proyecto para Kaiser Permanente. Estábamos creando una herramienta para gestionar la aplicación de parches a dispositivos médicos para miles de dispositivos mediante IBM BigFix. En un entorno sanitario, no puede darse el lujo de tener una interfaz de usuario confusa o difícil de navegar. Si un técnico tiene prisa y no puede encontrar el botón «Confirmar» porque el estado de enfoque es invisible, se trata de un verdadero problema. Dedicamos mucho tiempo a asegurarnos de que cada acción pudiera ejecutarse con el teclado con indicadores de enfoque claros y de alto contraste. No se trataba solo de cumplir, sino de seguridad.

Pero la gestión del enfoque se vuelve complicada en las aplicaciones modernas de React. Cuando cambias de «página» en una aplicación de página única (SPA), el navegador en realidad no se recarga. Para un usuario de lectores de pantalla, no pasó nada. Siguen en el enlace en el que acaban de hacer clic, pero el contenido que los rodea ha cambiado. Tienes que centrar la atención manualmente en el nuevo contenido o usar una región denominada «aria-live» para anunciar el cambio de página. Si no lo haces, tu aplicación «moderna» será un ladrillo para un usuario ciego.

ARIA no es una varita mágica

Los atributos de las aplicaciones de Internet enriquecidas y accesibles (ARIA) son eficaces, pero con frecuencia se utilizan de forma indebida. La primera regla de ARIA es: si puedes usar un elemento HTML nativo en su lugar, hazlo.

He visto a desarrolladores añadir aria-label y aria-live a todo como si estuvieran condimentando un filete. Termina creando una experiencia ruidosa y confusa para los usuarios de lectores de pantalla. ARIA debe usarse para llenar los vacíos que el HTML nativo no puede resolver, como los paneles de pestañas complejos o las actualizaciones de estado en tiempo real en un panel de control.

Si estás creando una visualización de datos personalizada (algo que hemos hecho con frecuencia para las suites de análisis de redes sociales), es posible que necesites ARIA para explicar lo que ocurre en un gráfico. ¿Pero para un formulario estándar? Mantenlo simple. Las etiquetas y las entradas son tus amigos.

Y por amor a todas las cosas sagradas, por favor, utiliza la etiqueta `` correctamente. No pongas texto simplemente al lado de una entrada. Usa el atributo for para vincularlos. Proporciona al usuario un objetivo de clics mayor y le indica al lector de pantalla para qué sirve exactamente esa entrada. Es un pequeño detalle que marca una gran diferencia en la profesionalidad de su sitio.

El mito del sitio accesible «feo»

Existe la extraña idea de que un sitio accesible tiene que parecerse a un documento de texto plano de 1994. Eso simplemente no es cierto. Puede tener una hermosa interfaz de usuario que también sea totalmente compatible. Solo requiere algo de intencionalidad.

Significa elegir paletas de colores que cumplan con la relación de contraste de 4,5:1 del texto normal. Significa no usar el color como la única forma de transmitir información. Si un mensaje de error es solo un borde rojo alrededor de un cuadro, es posible que un usuario daltónico no lo vea. Añade un icono o una etiqueta de texto como «Error:» para que quede claro.

Nuestro equipo de diseño, dirigido por Rita González, se centra en esto desde el primer día. Cuando estamos en Figma, comprobamos el contraste y el tamaño de las fuentes antes de escribir una sola línea de código. Es mucho más barato corregir un defecto de diseño en una maqueta que refactorizar un componente de React tres semanas antes del lanzamiento. En nuestro trabajo con la Universidad de Carolina del Sur y la NMSU, hemos comprobado que esto ha dado sus frutos: los diseños limpios y accesibles tienen un aspecto más profesional y fiable. Un buen diseño es un diseño inclusivo.

Herramientas que realmente utilizamos

Las pruebas automatizadas son excelentes, pero son solo el comienzo. Herramientas como WAVE, Axe y Lighthouse son fantásticas para atrapar lo más fácil: falta texto alternativo, contraste deficiente o ID duplicados. Las integramos en nuestras canalizaciones de CI/CD mediante GitHub Actions para detectar las regresiones en forma temprana. Incluso utilizamos «jest-axe» para realizar comprobaciones de accesibilidad durante nuestras pruebas unitarias.

Sin embargo, las herramientas automatizadas solo detectan entre el 30 y el 40% de los problemas de accesibilidad. Pueden decirte si una imagen tiene texto alternativo, pero no pueden decirte si ese texto es realmente útil.

<!-- Bad: Not helpful -->
<img src="chart.png" alt="image">

<!-- Good: Descriptive -->
<img src="chart.png" alt="Bar chart showing a 20% increase in social media engagement over Q3.">

Esta es la razón por la que las pruebas manuales no son negociables. Usamos lectores de pantalla como NVDA en Windows y VoiceOver en Mac. También hacemos pruebas sin usar el ratón y pruebas de zoom. ¿Alguna vez has intentado usar tu sitio con un zoom del 400%? Las WCAG 2.1 requieren que tu sitio siga siendo funcional sin necesidad de desplazarte horizontalmente a ese nivel. Esto te obliga a escribir un CSS con mejor capacidad de respuesta. No es solo para personas con problemas de visión; es para cualquiera que use un dispositivo pequeño o una ventana de navegador de tamaño extraño. Si tu sitio deja de funcionar con un zoom del 400%, es probable que tu lógica de diseño sea demasiado frágil de todos modos.

El argumento empresarial (más allá de la ley)

Si los argumentos morales y legales no lo conmueven, hablemos de dinero. Cuando construyes un sitio accesible, estás expandiendo tu mercado. Solo en los EE. UU., millones de personas tienen algún tipo de discapacidad. Si tu sitio es inutilizable para ellos, estás literalmente rechazando clientes. ¿Por qué querrías reducir tu audiencia potencial?

A los motores de búsqueda también les encantan los sitios accesibles. Los rastreadores de Google actúan de forma muy parecida a los lectores de pantalla. Buscan encabezados, texto alternativo y estructura semántica para entender de qué trata tu página. Si lo has optimizado para cumplir con las normas 508, básicamente has realizado una enorme cantidad de trabajo de SEO de forma gratuita. Obtienes mejores clasificaciones porque has creado un sitio mejor.

Y luego está el aspecto del mantenimiento. El código semántico y bien estructurado es más fácil de leer y depurar. Cuando un nuevo desarrollador se une al equipo y ve un <nav>, un <main> y un <footer>, entiende inmediatamente el diseño. Si ven div-1, div-2 y div-3, tienen que dedicar una hora a averiguar dónde termina la navegación y dónde comienza el contenido. La accesibilidad es una forma de documentación que nunca pasa de moda.

Por qué nos importa en Sweent

Hemos estado en las trincheras con estas cosas. Ya sea integrando Adobe Analytics para Deloitte o creando paneles complejos para NMSU, hemos visto cómo la accesibilidad repercute en los resultados finales.

En el proyecto de modernización de las aplicaciones de TI de la NMSU, estamos migrando las aplicaciones antiguas de Rails a una pila moderna de React y Node.js. Uno de nuestros principales objetivos es corregir la seguridad y el cumplimiento. Las aplicaciones antiguas se crearon en una era en la que la accesibilidad era una idea de último momento. Al incorporar 508 estándares en los nuevos componentes de React desde el principio, nos aseguramos de que la universidad no tenga que lidiar con estos mismos quebraderos de cabeza dentro de cinco años. Estamos arreglando la deuda técnica del pasado construyendo un futuro más inclusivo.

Se trata del orgullo por la artesanía. Como empresa propiedad de veteranos, no nos gusta tomar atajos. No queremos construir cosas que solo funcionen para algunas personas. Queremos crear cosas que funcionen para todos. Julian Tejera, nuestro fundador, pasó un tiempo en la Infantería de Marina, donde el éxito de la misión depende de que cada detalle sea correcto. Incorporamos esa misma disciplina a nuestro código.

¿Cómo empezar

Si estás viendo un sitio antiguo masivo y te sientes abrumado, no intentes arreglarlo todo de una vez. Empieza con los elementos globales: el encabezado, el pie de página y la navegación principal. Si no se puede acceder a ellos, el resto del sitio ni siquiera importa porque los usuarios no pueden pasar por la puerta principal.

A continuación, revisa tus formularios. ¿Alguien puede inscribirse? ¿Pueden comprar algo? ¿Pueden ponerse en contacto contigo? Primero arregla las rutas de mayor valor.

¿Es difícil? A veces. ¿Existe una respuesta perfecta para cada componente complejo de la interfaz de usuario? No siempre. Pero el esfuerzo vale la pena. ¿Cuándo fue la última vez que intentaste navegar por tu propio sitio con un lector de pantalla? Si no lo has hecho últimamente, pruébalo hoy. Es una experiencia reveladora y probablemente cambiará la forma en que escribes código para siempre. Es posible que descubras que los «errores» que has estado persiguiendo eran en realidad solo síntomas de una base rota.