Auditoría de accesibilidad WCAG y mejoras de la experiencia de usuario

En este proyecto se analizó la accesibilidad de la web oficial del Roig Arena desde una perspectiva UI/UX, aplicando la metodología WCAG-EM y la normativa EN 301549. Se seleccionó este caso por su relevancia pública, su reciente lanzamiento y la incorporación visible de un widget de accesibilidad. El objetivo es identificar barreras reales en la experiencia digital y proponer mejoras que garanticen un uso inclusivo, eficiente y equitativo para todas las personas.

Proyecto
Roig Arena
Trabajo
Auditoría WCAG · Informe IRA · Recomendaciones
Metodologia
WCAG-EM · Evaluación manual · Revisión de código
Herramientas
VoiceOver Bookmarklets Colour Contrast Analyser DevTools HeadingsMap Lighthouse Axe WAVE

Contexto

¿Por qué Roig Arena?

La web del Roig Arena fue seleccionada por ser un sitio de creación reciente con alto impacto público en Valencia. Su widget de accesibilidad visible generó la hipotesis central: la accesibilidad estaba integrada estructuralmente o era una capa superficial añadida.

La auditoria se desarrolló siguiendo la metodología WCAG-EM, combinando evaluación manual y revisión técnica del código para identificar incumplimientos de los criterios WCAG 2.2. Como resultado se elaboró un Informe IRA con todas las incidencias y sus propuestas de remediación.

Paso 1. Definir el alcance de la evaluación. Paso 2. Explorar el sitio web. Paso 3. Seleccionar una muestra representativa. Paso 4. Auditar la muestra seleccionada. Paso 5. Registrar los resultados de la evaluación

Pasos del procedimiento de evaluación de accesibilidad siguiendo WCAG-EM

Objetivo

Qué queríamos conseguir

  1. Determinar si la accesibilidad estaba integrada estructuralmente o añadida como capa superficial.

  2. Analizar componentes dinámicos e interactivos bajo los cuatro principios WCAG.

  3. Detectar problemas estructurales que afectan a la navegación con tecnologías de apoyo.

  4. Traducir hallazgos técnicos en recomendaciones claras y accionables.

Hallazgos y recomendaciones

01 · Perceptible

Consideraciones sobre el color

Durante la auditoría detecté combinaciones de color que no cumplían los requisitos mínimos de contraste establecidos por las WCAG 2.1, afectando directamente la legibilidad del contenido para personas con baja visión o en condiciones de uso adversas. A continuación se detallan las principales:

#df5312 sobre #ffffff
3.87:1 — Cumple AA
#999999 sobre #ffffff
2.84:1 — Falla AA
#f90 sobre #ffffff
2.14:1 — Falla AA

Errores detectados

Estos casos se encuentran por debajo del contraste mínimo exigido de 4.5:1 para texto normal (nivel AA) y de 3:1 para texto de gran tamaño y componentes de interfaz. La única excepción es el color #DF5312, que solo cumpliría en determinados elementos UI y textos de gran tamaño. Sin embargo, en la web del Roig Arena se utiliza en combinaciones que no alcanzan el contraste requerido.

APCA y redefinición en OKLCH

Para complementar el análisis, incorporé APCA (Advanced Perceptual Contrast Algorithm), un modelo perceptual que evalúa el contraste en función de la legibilidad percibida y no únicamente mediante ratios estáticos. A diferencia de WCAG 2.1, APCA tiene en cuenta el tamaño y el peso tipográfico, y penaliza con más precisión los casos de bajo contraste en texto pequeño.

A partir de esta investigación, mi propuesta recoge tres líneas de actuación:

  1. Sustituir el negro puro #000000 por un tono cercano como #101010, para suavizar el contraste extremo y mejorar el confort visual.

  2. Ampliar la paleta mediante variantes adaptadas a fondos claros y oscuros, asignando a cada color un uso concreto según el contexto de interfaz.

  3. Reajustar luminosidad y contraste utilizando OKLCH, un espacio de color perceptualmente uniforme, para garantizar coherencia visual entre variantes sin alterar el matiz ni la identidad de marca. El naranja de Roig Arena se mantiene reconocible, lo que cambia es su luminosidad.

Paleta de colores original del Roig Arena vs. paleta de colores propuesta que cumple con ratios mínimos de contraste según WCAG

Paleta de colores original vs. paleta propuesta


Estados en elementos interactivos

El sistema de componentes no define adecuadamente los estados interactivos esenciales (hover, focus, active), generando inconsistencias de comportamiento y percepción entre componentes y contextos de uso. La ausencia de estados de foco claramente visibles dificulta la navegación mediante teclado y reduce la percepción de control e interacción. Asimismo, algunos estados hover y active no proporcionan suficiente diferenciación visual respecto al fondo.

Paleta de colores original del Roig Arena vs. paleta de colores propuesta que cumple con ratios mínimos de contraste según WCAG

Botones originales vs. Propuesta de botones

Recomendación

Definir los estados default, hovered, focused, pressed y disabled para cada elemento interactivo. El contraste mínimo es 3:1 respecto a todos los fondos donde puedan encontrarse. El estado disabled es la única excepción.


Consideraciones de imágenes e iconos

No se diferencia entre imágenes decorativas e informativas. Se encontraron iconos informativos sin texto alternativo (como el icono de inicio de sesión) e imágenes decorativas con alt redundante que genera ruido en lectores de pantalla.

Paleta de colores original del Roig Arena vs. paleta de colores propuesta que cumple con ratios mínimos de contraste según WCAG
Paleta de colores original del Roig Arena vs. paleta de colores propuesta que cumple con ratios mínimos de contraste según WCAG

Ejemplos de imágenes con nombre accesible incorrecto

Recomendación

Incluir aria-label descriptivo en iconos informativos. Las imágenes decorativas deben usar únicamente alt="" para evitar información redundante en tecnologías de apoyo.

Hallazgos y recomendaciones

02 · Operable

Navegación con teclado

Se detectaron diversos problemas relacionados con la navegación mediante teclado, incluyendo un orden de tabulación incoherente, focos no visibles y elementos no operables sin ratón. Durante la navegación secuencial, el foco en el menú de navegación pasaba del menú hamburguesa directamente al logotipo principal del sitio web, generando una secuencia ilógica y potencialmente desorientadora para las personas usuarias que dependen exclusivamente del teclado.

Asimismo, en los carruseles de restaurantes y eventos, la navegación obligaba a recorrer mediante TAB todos los elementos contenidos en cada carrusel, incluidos elementos no visibles en ese momento, dificultando significativamente una navegación eficiente y accesible.

Documentación del orden de foco en la página de inicio del Roig Arena

Recomendación

Asegurar un orden de foco lógico, que los elementos interactivos muestren foco con contraste de color adecuado (mínimo 3:1) y que todo lo accesible por ratón también lo sea por teclado.


Al utilizar el lector de pantalla VoiceOver, algunos enlaces mostraban textos genéricos como “+ info” o “Reservar” sin indicar claramente su destino. Además, otros enlaces no disponían de un nombre accesible, por lo que las personas usuarias de lector de pantalla no podían identificar su función o propósito. Esto dificultaba comprender y navegar correctamente por el contenido.

Menú "Enlaces" de la página de Restauración del Roig Arena en VoiceOver

En el primer caso, la solución consiste en proporcionar contexto suficiente al botón para que su propósito sea comprensible sin depender del texto circundante, o bien en asociar programáticamente su texto con dicho contexto mediante técnicas adecuadas de marcado accesible.

Código problemático

  <a
  href="/es/reservas-ultramarinos/"
class="m-banner__action">
<div class="a-button m-banner__button" role="button"
aria-disabled="false" tabindex="0">
<div class="a-button__container"> Reservar </div>
</div></a>
Solución propuesta

  <h2
  id="titulo-ultramarinos">Ultramarinos</h2>

  <a
  href="/es/reservas-ultramarinos/"
  
aria-labelledby="reservar-ultramarinos
titulo-ultramarinos"
> <span id="reservar-ultramarinos">Reservar</span></a>

También ocurre que algunos enlaces representados mediante iconos no disponen de un nombre accesible, lo que impide que los lectores de pantalla puedan identificar su propósito. En estos casos, la solución consiste en proporcionar dicho nombre accesible mediante el uso de aria-label o técnicas equivalentes de etiquetado accesible.

Código problemático


  <a
  href="https://www.instagram.com/roig.arena/"
  rel="noopener noreferrer"
  target="_blank"
  class="a-link o-footer__social__item-link">
<div class="o-footer__social__item">
<i class="o-footer__social__item-icon pi pi-instagram"></i> </div> </a>
Solución propuesta


  <a
  href="https://www.instagram.com/roig.arena/"
  rel="noopener noreferrer"
  target="_blank"
  class="a-link o-footer__social__item-link"
  aria-label="Visitar perfil de Instagram del Roig Arena (se abre en una nueva pestaña)">
<div class="o-footer__social__item">
<i class="o-footer__social__item-icon pi pi-instagram"></i> </div> </a>

Recomendación

Usar textos de enlace que describan claramente el propósito o destino, usar aria-label si el enlace es un icono o utilizar aria-labelledby para asociar el enlace con el título del contenido al que apunta cuando el texto del enlace es genérico.


Etiqueta visible distinta al nombre accesible

En varios elementos interactivos la etiqueta visible no coincide con el nombre accesible anunciado por las tecnologías de asistencia. Esto genera confusión especialmente en usuarios de navegación por voz, que deben pronunciar exactamente el texto visible para activar el elemento.

Recomendación

Asegurar que el nombre accesible incluya o coincida con la etiqueta visible. Preferir HTML semántico limpio: usar <label for="surname"> directamente asociado al input en lugar de aria-label sobre el elemento. No usar ARIA si ya se está usando HTML semántico.


Jerarquía incorrecta de encabezados

La estructura de encabezados presenta inconsistencias graves. Algunas páginas no tienen H1, en otras, está duplicado y en otras, el orden de encabezados es ilógico, saltando de H1 directamente a H3 e ignorando el H2. Esto rompe la navegación estructural para usuarios de lector de pantalla.

Paleta de colores original del Roig Arena vs. paleta de colores propuesta que cumple con ratios mínimos de contraste según WCAG
Paleta de colores original del Roig Arena vs. paleta de colores propuesta que cumple con ratios mínimos de contraste según WCAG

Página de Eventos y Experiencias VIP del Roig Arena con jerarquía de encabezados ilógica

Recomendación

Revisar el orden de los encabezados en todas las paginas. Cada página debe tener un único H1 y los niveles deben descender de forma lógica, sin saltos de nivel.

Hallazgos y recomendaciones

03 · Comprensible

Errores en la definición de idioma

Se identificaron fragmentos en idioma distinto al principal, por ejemplo, en una de las cartas de los restaurantes aparecían comidas en francés: Mini croissant, Mini pain au chocolat, sin el atributo lang correspondiente. Además, la versión de la página en valenciano tiene el idioma mal configurado en el head. Utiliza lang="val" en lugar del correcto lang="ca", según ISO 639-1.

Ejemplos de codificación incorrecta del idioma en la web del Roig Arena

Recomendación

Marcar los fragmentos en otro idioma con el atributo lang adecuado (por ejemplo lang="fr" para fragmentos en francés). Corregir el código de idioma de la versión en valenciano a lang="ca".


Errores en formularios

Varios campos del formulario de contacto carecen de etiquetas visibles correctamente asociadas, no implementan autocomplete y presentan mensajes de error poco claros o no anunciados a lectores de pantalla.

Errores de codificación en el formulario de suscripción a la newsletter del Roig Arena

Recomendación

Garantizar etiquetas correctas mediante <label for>, implementar autocomplete y gestionar errores con aria-describedby. Priorizar etiquetas semanticas HTML5 frente a ARIA.

Hallazgos y recomendaciones

04 · Robusto

Marcado HTML y roles ARIA incorrectos

Se detectaron errores de marcado HTML, roles ARIA inapropiados e inconsistencias entre nombre, rol y valor. Los componentes de acordeón de las "Preguntas frecuentes" carecen de asociación programática necesaria (aria-expanded, aria-controls), por lo que los lectores de pantalla no pueden anunciar su estado.

Código erróneo
               

  <div
  class="m-accordion__panel m-accordion__panel--open">
<div class="m-accordion__header" role="button" tabindex="0" aria-expanded="true">
<p class="m-accordion__title"> ¿Puedo entrar al recinto si el espectáculo ya ha comenzado? </p>
<button class="a-button m-accordion__toggle" type="button" tabindex="0">
<div class="a-button__container"> <i class="m-accordion__toggle__icon pi pi-minus"></i> </div></button></div>

<div class="m-accordion__content-wrapper">
<div class="m-accordion__content" style="">
<div class="a-rich-text m-accordion__content__text" style="--rich-text-font-weight:var(--font-normal);">
<p> <span style="color:"> Una vez comenzado el evento se permitirá la entrada al Arena hasta 15 minutos antes de su finalización. </span></p>
</div></div></div></div>
Solución propuesta
                
  <h3
  class="accordion__heading">
<button id="accordion-button-1" class="accordion__trigger" type="button" aria-expanded="true" aria-controls="accordion-panel-1">
<span class="accordion__title"> ¿Puedo entrar al recinto si el espectáculo ya ha comenzado? </span>
<span aria-hidden="true"> </span>
</button></h3>

<div id="accordion-panel-1" role="region" aria-labelledby="accordion-button-1">
<p> Sí, aunque dependerá de las normas del evento. </p>
</div>

Recomendación

No añadir role="button" a elementos <a>. Los enlaces deben reservarse para navegación. Si el elemento ejecuta una acción, es preferible usar <button>. En componentes como acordeones, se recomienda implementar aria-expanded y aria-controls. Siempre que exista un elemento HTML semántico adecuado, debe priorizarse frente al uso de ARIA.

💭 Reflexión

Aprendizajes del proyecto

Los widgets no son accesibilidad

La presencia de un widget de accesibilidad da una falsa sensación de cumplimiento. La auditoría confirmó que la accesibilidad real debe estar integrada en el código base desde el principio, no añadida como capa externa.

HTML semántico primero, ARIA después

Muchos problemas provenían de un uso incorrecto de ARIA para compensar HTML no semántico. Si el elemento HTML existe, hay que usarlo sobre ARIA.

Documentar también es diseñar

La elaboración del Informe IRA demostró que traducir hallazgos técnicos en recomendaciones claras y accionables para desarrollo es, en sí misma, una habilidad de diseño. Un buen handoff, junto con un enfoque Shift Left, puede facilitar la integración temprana de la accesibilidad y reducir incidencias en fases posteriores del desarrollo.

La accesibilidad aporta valor a personas y negocio

La accesibilidad no solo garantiza una experiencia inclusiva para todas las personas, sino que también ayuda a cumplir con la normativa vigente, mejora el SEO y reduce retrabajos y costes de mantenimiento. Integrarla desde el inicio beneficia tanto a las personas usuarias como al negocio.

Informe completo

Informe de accesibilidad

Este caso de estudio muestra solo una parte de los hallazgos identificados. En el informe completo se detallan todas las incidencias detectadas durante la auditoría, organizadas por principio WCAG, con evidencias visuales, criterios afectados y recomendaciones de remediación.

Más proyectos

¿Hablamos?

Si tienes cualquier propuesta, idea creativa u oferta de colaboración, estaré encantada de escucharte. No dudes en ponerte en contacto conmigo.