WAI-ARIA: Accesibilidad en Aplicaciones Web Modernas (2)

WAI-ARIA se basa en tres pilares: roles (qué es un elemento), propiedades (cómo es y cómo se nombra) y estados (su situación dinámica). Estos atributos solo afectan al árbol de accesibilidad y no sustituyen a CSS ni JavaScript. Los roles permiten estructurar la página y definir widgets complejos; las propiedades aseguran nombres accesibles y ocultan elementos irrelevantes; y los estados comunican cambios dinámicos. ARIA requiere soporte completo de teclado y correcta gestión del foco. No reemplaza al HTML semántico, sino que lo complementa, y su correcta implementación debe validarse con herramientas automáticas y lectores de pantalla.

WAI-ARIA: Accesibilidad en Aplicaciones Web Modernas (1)

WAI-ARIA es una especificación del W3C destinada a mejorar la accesibilidad de aplicaciones web dinámicas e interactivas cuando el HTML nativo resulta insuficiente. Proporciona atributos que añaden semántica, roles y estados comprensibles para los lectores de pantalla, actuando como puente entre JavaScript y los productos de apoyo. Su uso debe ser excepcional y seguir cinco reglas fundamentales: priorizar elementos nativos, no alterar semántica innecesariamente, garantizar operación por teclado, no ocultar elementos interactivos y asegurar un nombre accesible. WAI-ARIA modifica el árbol de accesibilidad del navegador, no la presentación visual.

Undécima encuesta del WebAIM sobre el uso de lectores de pantalla

Durante los últimos años, el WebAIM ha realizado varias encuestas online destinadas a analizar los hábitos de uso de los lectores de pantalla. Por ejemplo, los resultados de la última encuesta están disponibles en Screen Reader User Survey #10 Results.

Ahora ya está abierta la undécima edición: Screen Reader User Survey #11.

La encuesta estará disponible hasta el 31 de agosto de 2024 y la pueden contestar todos los usuarios de lectores de pantalla, incluso los que los usan únicamente para evaluación y pruebas.

Directrices para la contratación pública de productos y servicios TIC en la Unión Europea: criterios de adjudicación relativos a accesibilidad y evaluación de la conformidad

Los organismos europeos CEN, CENELEC y ETSI han publicado el informe técnico CEN-CLC-ETSI/TR 101551 V2.1.1 (2026-02) que actualiza y unifica dos documentos de 2014 sobre accesibilidad en la contratación pública de productos y servicios TIC.

El título de CEN-CLC-ETSI/TR 101551 V2.1.1 (2026-02) es "Guidelines for public procurementof ICT products and services in the EU;Accessibility award criteria and conformity assessment". Este informe técnico responde a los desafíos que plantean la European Accessibility Act (EAA) y la Web Accessibility Directive (WAD), proporcionando orientación a las administraciones públicas para incorporar requisitos de accesibilidad en sus procesos de contratación.

Las directrices explican cómo definir especificaciones técnicas alineadas con la legislación europea de accesibilidad, establecer criterios de selección y exclusión adecuados, y diseñar criterios de adjudicación que promuevan niveles más altos de accesibilidad. Además, incluyen orientaciones sobre la evaluación de la conformidad de los productos y servicios contratados.

El informe se complementa con anexos que ofrecen ejemplos prácticos y herramientas para integrar la accesibilidad en la contratación pública, destacando especialmente el uso de la norma EN 301 549, que establece los requisitos de accesibilidad para los productos y servicios TIC en Europa.

Más información: CEN, CENELEC and ETSI release revised guidance on the EAA and WAD

Novedades de ARIA 1.3

En el artículo Cool new stuff coming in ARIA 1.3, escrito por Karl Groves, uno de los guruses de la accesibilidad web, se exploran las novedades de Accessible Rich Internet Applications (WAI-ARIA) 1.3 (borrador del 4 de junio de 2026).

El borrador de WAI-ARIA 1.3 introduce nuevas capacidades orientadas principalmente a mejorar la accesibilidad de aplicaciones web complejas, especialmente editores colaborativos, sistemas de anotación, flujos de revisión documental y formularios avanzados. A diferencia de versiones anteriores, no se centra en crear nuevos widgets, sino en representar mejor el significado de contenidos complejos para las tecnologías de asistencia.

No obstante, hay que recordar que ARIA no sustituye a HTML y que siempre deben utilizarse primero los elementos semánticos nativos cuando existan equivalentes adecuados.

Entre las principales novedades destacan:

• role="suggestion": permite identificar cambios propuestos en documentos (inserciones, eliminaciones o modificaciones), facilitando que los usuarios de tecnologías de asistencia comprendan que se trata de sugerencias y no de contenido definitivo.
• role="comment": identifica comentarios, anotaciones o revisiones asociados a una parte concreta del contenido.
• role="mark": representa contenido resaltado con significado semántico, similar al elemento HTML <mark>.

También se incorporan nuevos atributos:

• aria-description: proporciona una descripción accesible directamente mediante texto, sin necesidad de referenciar otro elemento del DOM. Debe utilizarse solo cuando no exista texto visible adecuado para emplear aria-describedby.
• aria-braillelabel: permite definir una etiqueta específica para dispositivos braille, optimizada para sus limitaciones de espacio.
• aria-brailleroledescription: ofrece una descripción del rol adaptada a la salida braille.

Además, ARIA 1.3 introduce mejoras en atributos existentes:

• aria-details podrá referenciar múltiples elementos, permitiendo asociar varias explicaciones o detalles estructurados a un mismo componente.
• aria-errormessage también admitirá múltiples referencias, facilitando mostrar simultáneamente varios errores de validación asociados a un campo.
• Se aclara que aria-haspopup="false" no debe exponerse a las tecnologías de asistencia, ya que aporta información redundante.
• Se refuerza la recomendación de utilizar niveles de encabezado coherentes mediante aria-level, preferiblemente recurriendo a los elementos HTML <h1>–<h6>.

El borrador también incorpora nuevos roles relacionados con la semántica documental, como code, deletion, insertion, strong, emphasis, subscript, superscript y time, especialmente útiles en editores personalizados donde no es posible emplear HTML nativo.

Dado que ARIA 1.3 aún se encuentra en desarrollo, el artículo recomienda no adoptar estas funcionalidades en entornos de producción sin realizar pruebas exhaustivas, ya que tanto la especificación como su soporte por navegadores y tecnologías de asistencia pueden cambiar. En cualquier caso, ARIA 1.3 representa un avance hacia una representación más precisa de documentos complejos, revisiones, anotaciones y contenidos enriquecidos en aplicaciones web modernas.

Taller sobre cómo auditar la accesibilidad de diseños UX

Que haya algún curso sobre usabilidad, accesibilidad o experiencia de usuario en Madrid o Barcelona no es una novedad. Lo que sí que es una novedad es un curso sobre esos temas fuera de los dos polos económicos de España.

El próximo 27/6/2026 en Valencia se organiza el Accessibility Lab Workshop - Aprende a auditar tus diseños, un taller de dos horas y media sobre cómo aprender a identificar y corregir las barreras de accesibilidad antes de enviar los diseños a desarrollo.

Estudio de la accesibilidad de un sitio web creado mediante inteligencia artificial

En Lovable’s AI built a 100% accessible site – or did it? se explica que un sitio web construido con inteligencia artificial (usando la herramienta Lovable) obtuvo una puntuación perfecta del 100% en una prueba automática de accesibilidad. Sin embargo, al ser probado por un usuario real de lector de pantalla (VoiceOver en iPhone), mostró múltiples problemas graves.

Los principales problemas encontrados fueron:

• El lector de pantalla leía contenido oculto detrás de menús o ventanas modales.
• Un componente de seguridad (Cloudflare) se repetía sin control, interrumpiendo la navegación.
• Al ser una aplicación de una sola página (SPA), el foco no se movía correctamente al cambiar de sección.
• El botón de menú no indicaba si estaba expandido o colapsado (falta de aria-expanded).
• Se saltaban niveles de encabezados (de H1 a H3, sin H2).
• Etiqueta aria-label diferente al texto visible del botón, dificultando el control por voz.
• El selector de idiomas no permitía saber cuál estaba activo.

No obstante, un experto en accesibilidad corrigió muchos de estos problemas en solo 10 minutos desde su teléfono móvil. Según los autores de este artículo, esto demuestra que la IA puede funcionar bien si un humano especialista supervisa el proceso. Pero la mayoría de los sitios creados con estas herramientas no tendrán esa supervisión, por lo que aún están lejos de ser realmente accesibles por defecto.

La sesión ha caducado (session timeout)

El artículo Session Timeouts: The Overlooked Accessibility Barrier In Authentication Design es un excelente análisis de los problemas de accesibilidad que plantea la gestión de la sesión en una aplicación web.

El artículo analiza la gestión de sesiones en la web desde la perspectiva de la accesibilidad, destacando que los tiempos de expiración (session timeouts) no solo afectan a la experiencia de usuario y la seguridad, sino que constituyen una barrera significativa para las personas con discapacidad.

Se señala que una gran parte de la población (incluyendo las personas con discapacidades motoras, cognitivas o visuales, así como usuarios neurodivergentes) se ve desproporcionadamente afectada por límites de tiempo estrictos. Estos usuarios pueden necesitar más tiempo para interactuar con formularios, procesar información o navegar mediante productos de apoyo, lo que provoca que los sistemas interpreten erróneamente su actividad como inactividad.

El texto muestra varias situaciones en las que las personas con discapacidad experimentan problemas de accesibilidad:

• Las personas con discapacidades motoras pueden introducir datos más lentamente.
• Las personas con dificultades cognitivas requieren más tiempo para comprender o procesar información.
• Los usuarios con discapacidad visual dependen de lectores de pantalla, lo que incrementa el tiempo de navegación.

Además, el artículo critica prácticas habituales poco accesibles, como cierres de sesión sin aviso, avisos insuficientes, imposibilidad de extender la sesión y pérdida de datos al expirar. Como soluciones, se proponen buenas prácticas alineadas con las WCAG, como son:

• Proporcionar avisos previos claros y suficientes.
• Permitir extender el tiempo de sesión.
• Implementar guardado automático del progreso.
• Diseñar tiempos de expiración coherentes (preferiblemente basados en actividad).
• Informar desde el inicio sobre los límites de tiempo.

Finalmente, se subraya que mejorar la accesibilidad de los tiempos de sesión no solo beneficia a personas con discapacidad, sino a todos los usuarios, y constituye tanto una buena práctica técnica como un compromiso ético en el desarrollo web.

Las WCAG proporcionan recursos adicionales que los desarrolladores web pueden consultar para comprender mejor la accesibilidad de la gestión de sesiones:

• WCAG SC 2.2.1 Timing Adjustable
• WCAG SC 2.2.5 Re-authenticating
• WCAG SC 2.2.6 Timeouts

Día Mundial para Promover la Concienciación sobre la Accesibilidad Web (Global Accessibility Awareness Day)

El tercer jueves del mes de mayo se celebra el Global Accessibility Awareness Day (GAAD), Día Mundial para Promover la Concienciación sobre la Accesibilidad Web.

En la página principal podemos leer:

Thursday, May 21, 2026, help us celebrate the 15th Global Accessibility Awareness Day (GAAD)! The purpose of GAAD is to get everyone talking, thinking and learning about digital access and inclusion, and the more than One Billion people with disabilities/impairments.

Celebración del GAAD en varias universidades españolas

Cada año, el tercer jueves de mayo se celebra el Día Mundial para Promover la Concienciación sobre la Accesibilidad Web (Global Accessibility Awareness Day, GAAD). Este año se celebra el próximo jueves 21 de mayo.

Varias universidades españolas han organizado algunos eventos para ese año. Por ejemplo, la Universidad de Alicante organiza el 21 de mayo el Día de la Accesibilidad Digital en la UA 2026. En la descripción del evento se indica:

Este año, como novedad, contaremos con la participación de varios expertos en accesibilidad que se desplazarán hasta la UA para compartir sus conocimientos y experiencias. Su perspectiva enriquecerá el debate y ayudará a sensibilizar a todos los asistentes sobre la relevancia de la accesibilidad digital en nuestra sociedad.

Y la Universitat de Lleida organiza el 28 de mayo la Primera Jornada de Accesibilidad Digital, con la siguiente descripción:

Jornada para aprender sobre personas, diseño, desarrollo web, documentos, evaluación e inteligencia artificial en el ámbito de la accesibilidad digital.

La accesibilidad y la usabilidad se deben trabajar de forma conjunta

En Sometimes the Best Accessibility Fix is a Usability Fix se explica que la accesibilidad no debe considerarse un añadido separado de la experiencia de usuario (UX), sino una parte esencial del buen diseño. Muchas barreras de accesibilidad surgen de problemas de usabilidad que ya resultan molestos para usuarios sin discapacidad, aunque afectan de manera mucho más grave a personas con discapacidades visuales, motoras, cognitivas o neurodivergentes.

Se presentan varios ejemplos comunes para entender la relación entre accesibilidad y usabilidad:

• Errores prematuros en formularios: mostrar mensajes de error antes de que el usuario termine de escribir genera confusión y distracción. Retrasar la validación mejora tanto la usabilidad como la accesibilidad.
• Listas desplegables mal diseñadas: menús largos sin búsqueda por escritura (“typeahead”) o que se abren en posiciones arbitrarias dificultan enormemente la navegación con teclado o lectores de pantalla.
• Mensajes de confirmación que desaparecen rápido: los avisos temporales impiden que muchas personas terminen de leerlos. Mantenerlos visibles más tiempo o permitir cerrarlos manualmente mejora el control temporal.
• Campos que solo se pueden borrar con retroceso: obligar a eliminar texto carácter por carácter añade esfuerzo innecesario, especialmente para usuarios con limitaciones motoras o lectores de pantalla.
• Pérdida de posición en galerías de productos: volver al inicio de una lista tras consultar un producto crea frustración y obliga a repetir navegación.
• Mostrar contraseñas mediante “mantener pulsado”: este patrón exige precisión motora y temporal; un interruptor permanente resulta más accesible y usable.
• Fuentes de información duplicadas: repetir la misma información en varios formatos incrementa la carga cognitiva y genera redundancia para usuarios de tecnologías asistivas.
• Borrado de datos tras errores: eliminar información introducida, como números de tarjeta de crédito, obliga a repetir tareas complejas y aumenta la probabilidad de errores.

El artículo concluye que las organizaciones que realmente se preocupan por la accesibilidad también deben preocuparse por la usabilidad. Cuando las mejoras de accesibilidad se presentan como correcciones de usabilidad, suelen encontrar menos resistencia organizativa y benefician a todos los usuarios. Además de reducir riesgos legales, estas mejoras disminuyen la fricción, las quejas y las llamadas de soporte, aumentando la satisfacción del cliente mediante interacciones más estables y predecibles.

Extendidos los plazos de ADA Title II en EE UU

ADA Title II Rule on Web Content and Mobile App Accessibility estaba previsto que inicialmente entrase en vigor en 2026. Sin embargo, en DOJ Delays the Title II Web Accessibility Deadline - Don't Sit Back se explica que el 20 de abril de 2026 el Departamento de Justicia de EE. UU. publicó una norma provisional que retrasa un año los plazos de cumplimiento de la regla de accesibilidad web del Título II (2024). Las entidades públicas con más de 50.000 habitantes pasan a tener como fecha límite abril de 2027, mientras que las más pequeñas disponen hasta abril de 2028. Además, se abre un periodo de 60 días para comentarios públicos.

La norma justifica el retraso con varios argumentos. El más sólido es la limitación de recursos (personal y presupuesto) de muchas entidades, especialmente en educación. Sin embargo, el texto critica duramente otros razonamientos: la supuesta sobreestimación del papel de la inteligencia artificial (que no figuraba en la norma original), las dudas sobre la aplicabilidad de WCAG 2.1 (consideradas jurídicamente arriesgadas) y la idea de posibles demandas impulsadas por actores extranjeros, calificada como poco creíble. También se señala que el Departamento de Justicia estaría “premiando la ignorancia” al conceder más tiempo a instituciones que no comprendieron correctamente la normativa previa.

Aunque la medida solo modifica los plazos y no los requisitos, se anticipa una posible revisión futura de la norma que podría afectar aspectos clave como el uso de WCAG. En cualquier caso, se subraya que la obligación de garantizar la accesibilidad web sigue vigente y que las entidades deben continuar avanzando en su cumplimiento pese a la incertidumbre regulatoria.

ADA Title II Rule on Web Content and Mobile App Accessibility en Estados Unidos

ADA Title II Rule on Web Content and Mobile App Accessibility es una regulación publicada en abril de 2024 por el Departamento de Justicia de EE. UU. que concreta, por primera vez de forma explícita, cómo deben cumplir las administraciones públicas con las obligaciones de accesibilidad digital establecidas en la Americans with Disabilities Act (ADA).

La norma establece que:

• Ámbito de aplicación: Se aplica a todas las entidades públicas estatales y locales (incluyendo universidades públicas), así como a los servicios digitales que ofrecen, tanto directamente como a través de terceros.
• Obligación principal: Todos los sitios web, aplicaciones móviles y contenidos digitales públicos deben ser accesibles para las personas con discapacidad, garantizando el principio de “comunicación efectiva” y acceso equitativo a los servicios públicos.
• Estándar técnico exigido: Se adopta como referencia obligatoria WCAG 2.1 nivel AA, lo que implica cumplir criterios sobre estructura, navegación, alternativas textuales, subtitulado, etc.
• Alcance del contenido: Incluye prácticamente todo el contenido digital público: páginas web, documentos, plataformas educativas, aplicaciones móviles y servicios online, incluso cuando son proporcionados por terceros contratados.
• Excepciones limitadas: Existen algunas excepciones específicas (por ejemplo, contenido archivado o ciertos contenidos de terceros no controlados), pero son restringidas y no eliminan la obligación general de accesibilidad.
• Plazos de cumplimiento: Inicialmente fijados para 2026, han sido extendidos en 2026 mediante una norma intermedia:
• Entidades grandes (≥50.000 habitantes): hasta abril de 2027
• Entidades pequeñas: hasta abril de 2028

ADA Title II Rule on Web Content and Mobile App Accessibility transforma la accesibilidad web en el sector público estadounidense de una obligación genérica a un requisito técnico concreto y exigible, alineado con WCAG 2.1 AA, reforzando la rendición de cuentas y la inclusión digital.

Texto alternativo para el contenido generado desde CSS

A través de Tests for CSS generated content alternative text he aprendido que se puede definir un texto alternativo para el contenido generado desde CSS. Este artículo analiza el uso de la propiedad content en CSS para generar contenido visual (como texto o iconos) y su implicación en la accesibilidad. Cuando este contenido es relevante, debería contar con una alternativa accesible para personas que utilizan productos de apoyo como los lectores de pantalla. Para ello, la especificación de CSS permite incluir un texto alternativo mediante una barra (/) dentro de la propiedad content, donde lo anterior a la barra se muestra visualmente y lo posterior se destina a los productos de apoyo.

Según la especificación, este texto alternativo debe sustituir al contenido visual en lectores de pantalla y puede ser expuesto en el árbol de accesibilidad en navegadores compatibles.

Pero como suele ocurrir muchas veces, una cosa es la teoría (la especificación) y otra la práctica (lo que realmente funciona al combinar un navegador con un lector de pantalla en un sistema operativo específico). Se presentan cuatro casos de prueba: (1) solo contenido generado, que generalmente se anuncia correctamente; (2) solo texto alternativo, con resultados inconsistentes según navegador y lector de pantalla; (3) texto alternativo vacío, donde no debe anunciarse nada; y (4) combinación de contenido visual y texto alternativo, donde este último debería reemplazar al primero, aunque también con inconsistencias en algunos entornos.

En conjunto, los resultados muestran que el soporte de esta funcionalidad aún no es completamente fiable entre diferentes combinaciones de navegadores y lectores de pantalla. Por ello, se recomienda tratar esta técnica como experimental y, para información importante, seguir utilizando HTML semántico y atributos ARIA en lugar de depender únicamente del contenido generado por CSS para garantizar la accesibilidad.

Diseño web accesible para las personas con ansiedad

En el artículo Designing for people with anxiety se aborda cómo diseñar interfaces digitales teniendo en cuenta a las personas con ansiedad, una condición que puede afectar significativamente la capacidad de concentración, toma de decisiones y procesamiento de información. La ansiedad, al mantener al usuario en un estado constante de alerta, reduce sus recursos cognitivos y puede generar experiencias digitales abrumadoras si no se diseña adecuadamente.

El artículo propone una serie de recomendaciones centradas en reducir la carga cognitiva, minimizar el estrés y crear experiencias más claras, predecibles y controlables. Aunque las pautas de accesibilidad WCAG proporcionan una base, se enfatiza la necesidad de ir más allá del cumplimiento normativo hacia un diseño verdaderamente centrado en la persona.

Entre las principales consideraciones destacan:

• Evitar la presión temporal: los temporizadores y cuentas regresivas pueden generar ansiedad. Se recomienda permitir al usuario controlar el tiempo, ampliarlo o eliminarlo cuando sea posible, así como emplear mensajes tranquilos y comprensivos.
• Reducir la sensación de urgencia: elementos como la escasez artificial o la popularidad de productos pueden inducir decisiones apresuradas y estrés, especialmente en personas con ansiedad.
• Mantener interacciones predecibles: el uso de patrones de diseño familiares y consistentes ayuda a que los usuarios se sientan más seguros y en control. Interfaces inesperadas o engañosas incrementan la desconfianza y el malestar.
• Proporcionar información clara sobre el progreso: indicadores de avance en procesos complejos reducen la incertidumbre y permiten al usuario gestionar mejor su tiempo y esfuerzo.
• Ser transparente en la solicitud de datos: explicar por qué se pide cierta información genera confianza y evita preocupaciones innecesarias.
• Permitir la revisión antes de confirmar acciones: ofrecer opciones de vista previa o verificación reduce la inseguridad y aumenta la confianza del usuario.
• Facilitar la orientación (wayfinding): elementos como migas de pan, menús de navegación y buscadores ayudan a los usuarios a entender dónde están y cómo moverse dentro del sistema.

En conjunto, estas prácticas buscan diseñar experiencias digitales más inclusivas, que no solo eviten agravar la ansiedad, sino que contribuyan activamente a generar entornos más calmados, comprensibles y controlables para todos los usuarios.

Resultados del estudio The WebAIM Million 2026

Este es el octavo año que WebAIM publica The WebAIM Million. Los resultados son similares a los años anteriores.

El principal resultado es:

95.9% of home pages had detected WCAG 2 failures. This number increased from 94.8% in 2025—reversing a trend of small improvements each of the previous 6 years. Because only automatically detectable WCAG failures were considered, this suggests that the rate of full WCAG 2 A/AA conformance was certainly lower than 4.1%.

Errores de accesibilidad en webs de transporte público: barreras para moverse por la ciudad

 

¿Por qué son importantes los estilos alternativos en una página web?

 

Hola, soy Sergio Luján Mora, profesor de informática de la Universidad de Alicante, y en este vídeo que forma parte del curso “Introducción al desarrollo web”, te voy a hablar de la importancia de ofrecer estilos alternativos en una página web.

Si se les pregunta a los usuarios de la Web cómo es una página web “buena”, probablemente la mayoría pensará en un diseño visual atractivo, con colores armónicos, tipografías modernas y animaciones, muchas animaciones. Y no les faltaría razón. Pero ¿qué pasa cuando este diseño, pensado para la mayoría, no funciona para todos?

A las páginas web acceden miles de millones de usuarios, muchos de ellos con necesidades, preferencias y contextos de uso diferentes. En especial, las personas con discapacidad muchas veces experimentan problemas, barreras, al navegar por las páginas web.

Por ejemplo, este artículo del prestigioso periódico The New York Times tiene un importante problema de contraste en el título del artículo y en la entradilla. [P] Una persona sin discapacidad seguramente leerá con algunos problemas el título y la entradilla. Pero una persona con discapacidad visual o discapacidad cognitiva quizás sea incapaz de leerlo y entenderlo.

Este problema es muy fácil de resolver.

Los diseñadores web del periódico The New York Times podrían simplemente añadir un fondo semitransparente al título y a la entradilla que aumentase el contraste entre el texto y la fotografía de fondo.

¿Y esto cómo se hace? Seguramente pensarás que es difícil o requiere mucho tiempo y por eso no lo han hecho. Bueno, en realidad, en lo que he tardado en sacarme un moco de la nariz he añadido el código necesario para resolver este problema.

Y entonces, ¿por qué no lo han hecho? Bueno, podemos pensar en muchas razones, pero por mi experiencia, normalmente, el propietario o el diseñador del sitio quiere que su sitio web se vea exactamente de una forma concreta, aunque eso sea negativo para muchos usuarios.

La solución a esta situación es sencilla, podemos diseñar nuestro sitio web con un estilo principal y con todas las mierdas que queramos, aunque nos estemos pegando un tiro en el pie.

Pero a la vez, también debemos ofrecer estilos alternativos para desarrollar una web verdaderamente universal y robusta.

Los estilos alternativos son versiones de nuestra hoja de estilos principal que ofrecen una experiencia de usuario diferente. No son un sitio web nuevo, sino una adaptación del mismo contenido. Los más comunes son:

Estilo oscuro: para reducir la fatiga visual en entornos con poca luz o por preferencia personal.

Estilo de alto contraste: para usuarios con baja visión.

Estilo texto grande: para usuarios con baja visión.

Estilo daltonismo: que ajusta la paleta de colores para garantizar que la información se perciba correctamente.

Estilo de lectura: que elimina elementos superfluos como menús y publicidad para concentrarse en el contenido principal.

Estilo para impresión: elimina elementos superfluos como menús y adapta el contenido al tamaño de una hoja de papel.

Hoy en día, muchos sitios web ofrecen algunos de estos estilos alternativos. Por ejemplo, en mi sitio web sobre accesibilidad web ofrezco una opción de configuración que permite que el usuario seleccione un estilo que se adapte mejor a sus necesidades: el estilo principal, dos estilos de alto contraste (amarillo sobre negro y verde sobre negro), colores de bajo contrate y estilos con diferentes tipos de letra.

Aquí tenemos otro ejemplo, la web de La Moncloa, que por defecto aparece con el modo claro, pero que tiene una opción para cambiar al modo oscuro.

¿Y cómo se ofrecen los estilos alternativos en un sitio web? Existen varias formas, en el vídeo “CSS: definición y uso de estilos alternativos” te explico una forma que se puede emplear en Mozilla Firefox, de forma nativa, y en otros navegadores web con alguna extensión. Pero en la mayoría de los casos, tendrás que proporciona un selector de estilos como el que hemos visto en la web de La Moncloa.

Sobre el estilo para impresión te recomiendo los siguientes vídeos. Por un lado, te recomiendo que veas el vídeo “CSS: hoja de estilo para impresión”, del estudiante Samuel López Brufal. En este vídeo se enseña a crear un CSS correcto para imprimir las páginas web.

Muchos diseñadores no optimizan las páginas web para impresión, lo que genera confusión al imprimir.

Samuel propone los siguientes consejos para una correcta hoja de estilo para impresión:

Diseño adaptativo para impresión.

Uso de tonos blancos y negros (o colores originales si es necesario).

Incluir las URLs visibles para referencia posterior.

Y aplicar filtros CSS para mejorar los resultados.

En el vídeo de Samuel también se explica que se deben evitar las divisiones en tablas y listas con las siguientes propiedades de CSS: page-break-inside, page-break-before y page-break-after.

En realidad, estas propiedades de CSS están obsoletas y en su lugar se deben emplear las propiedades break-after, break-before y break-inside.

El tema de evitar las divisiones en tablas y listas lo tienes desarrollado con más profundidad en los siguientes vídeos. “CSS: cómo controlar los puntos de corte cuando se imprime una página”, parte 1 y parte 2. Y con esto finaliza este vídeo en el que te he explicado la importancia de los estilos alternativos en las páginas web.

Recuerda que este vídeo forma parte del curso “Introducción al desarrollo web” que está disponible en la dirección idesweb.es.

Muchas gracias por tu atención.

WAI-ARIA: Accesibilidad en Aplicaciones Web Modernas (2)

WAI-ARIA se basa en tres pilares: roles (qué es un elemento), propiedades (cómo es y cómo se nombra) y estados (su situación dinámica). Estos atributos solo afectan al árbol de accesibilidad y no sustituyen a CSS ni JavaScript. Los roles permiten estructurar la página y definir widgets complejos; las propiedades aseguran nombres accesibles y ocultan elementos irrelevantes; y los estados comunican cambios dinámicos. ARIA requiere soporte completo de teclado y correcta gestión del foco. No reemplaza al HTML semántico, sino que lo complementa, y su correcta implementación debe validarse con herramientas automáticas y lectores de pantalla.

WAI-ARIA: Accesibilidad en Aplicaciones Web Modernas (1)

WAI-ARIA es una especificación del W3C destinada a mejorar la accesibilidad de aplicaciones web dinámicas e interactivas cuando el HTML nativo resulta insuficiente. Proporciona atributos que añaden semántica, roles y estados comprensibles para los lectores de pantalla, actuando como puente entre JavaScript y los productos de apoyo. Su uso debe ser excepcional y seguir cinco reglas fundamentales: priorizar elementos nativos, no alterar semántica innecesariamente, garantizar operación por teclado, no ocultar elementos interactivos y asegurar un nombre accesible. WAI-ARIA modifica el árbol de accesibilidad del navegador, no la presentación visual.