⚠️ Oye, estás usando un navegador web desactualizado.
TaxScouts podría no funcionar con su navegador. Actualice aquí

Accesibilidad en TaxScouts

Introducción

En TaxScouts, nos comprometemos a que nuestros servicios sean accesibles para todas las personas, incluidas aquellas con necesidades de acceso diversas. Creemos en el diseño inclusivo y trabajamos para que nuestras experiencias digitales sean fáciles de usar y accesibles para todos.

Esta declaración de accesibilidad describe cómo nuestra plataforma de declaración de impuestos en España cumple con los requisitos establecidos por la Ley Europea de Accesibilidad (EAA). El alcance de esta declaración cubre nuestro producto SaaS para trabajadores autónomos en España.

Entre enero y junio de 2025, nuestro trabajo de pruebas e implementación en materia de accesibilidad se ha llevado a cabo tomando como referencia los estándares definidos por la norma EN 301 549 y las pautas WCAG 2.1 Nivel AA.

Trabajo realizado

Revisión del impacto normativo

Realizamos una evaluación de la Ley Europea de Accesibilidad (EAA) para entender su aplicabilidad a nuestro producto en España. Como parte de esta revisión, confirmamos que WCAG 2.1 Nivel AA constituye el estándar mínimo de cumplimiento, mientras que WCAG 2.2 fue identificado como nuestro punto de referencia preferido tras su publicación en diciembre de 2024.

Documentación como Estrategia de Cumplimiento

Iniciamos un proceso formal para documentar los problemas de accesibilidad con el fin de asegurar que todas las posibles mejoras se registren de forma estructurada y trazable. Este enfoque nos permite evaluar cada incidencia en función de su relevancia e impacto, y determinar si se debe abordar y cómo hacerlo. También proporciona un registro claro de las decisiones tomadas y de los avances logrados en apoyo al cumplimiento normativo, en línea con los estándares WCAG 2.1/2.2 y EN 301 549.

Intercambio de Conocimientos y Desarrollo de Estrategia

Para garantizar la alineación entre equipos, llevamos a cabo reuniones estratégicas con el equipo de diseño de Taxfix, empresa matriz de TaxScouts, con el objetivo de coordinar nuestro enfoque. También revisamos las herramientas de prueba de accesibilidad y las metodologías de corrección utilizadas dentro del Grupo Taxfix, que han servido de referencia para nuestras propias pruebas y planes de mejora.

Evaluación de Accesibilidad y Trabajo de Corrección

Mediante una combinación de herramientas automatizadas de evaluación de accesibilidad y una auditoría manual interna realizada por nuestro diseñador de producto y desarrollador front-end, evaluamos las áreas clave del producto para detectar problemas de accesibilidad. Los hallazgos nos permitieron identificar componentes específicos y patrones de interacción que no cumplían con los estándares de accesibilidad. Cada uno de los problemas enumerados a continuación fue abordado mediante cambios específicos de diseño y desarrollo, con el objetivo de alinear el producto con los requisitos de WCAG 2.1/2.2 Nivel AA y EN 301 549, al mismo tiempo que se mejora la experiencia general para todos los usuarios.

1. Selección de Grupo en el Registro

Problema

Las opciones de selección de grupo no contaban con un contraste visual suficiente para distinguirse claramente del fondo. En concreto, el color de resaltado de la selección usaba el valor hexadecimal #CAE5FF sobre un fondo blanco (#FFFFFF), lo que resultaba en una proporción de contraste de 1.29:1, incumpliendo los requisitos de WCAG 2.1 Nivel AA para el contraste de elementos no textuales (mínimo 3:1 para componentes de la interfaz de usuario y objetos gráficos). Esto dificultaba que los usuarios con discapacidades visuales o deficiencias en la percepción del color identificaran el estado seleccionado.

Impacto en la accesibilidad

Los usuarios pueden no reconocer que el grupo de opciones es seleccionable si las señales visuales son demasiado sutiles. Esto representa una barrera de accesibilidad significativa, especialmente en este caso donde la selección implica la aceptación obligatoria de nuestros Términos de servicio y Política de privacidad.

Solución implementada

El color de resaltado de la selección se actualizó a #0191E4, lo que proporciona una proporción de contraste de 3.4:1 sobre el fondo blanco. Esto cumple con el requisito mínimo de contraste para elementos no textuales definido por WCAG 2.1 Nivel AA, asegurando que el estado seleccionado sea claramente visible para todos los usuarios, incluidos aquellos con baja visión o deficiencias en la percepción del color.

2. Visibilidad de la Selección en los Botones de Opción

Problema

El color de resaltado utilizado para los botones de opción no cumplía con los requisitos de contraste establecidos por WCAG 2.1 Nivel AA. El color de resaltado original (#CAE5FF) se mostraba sobre un fondo gris neutro (#F4F1F1), lo que daba como resultado una proporción de contraste de 1.15:1. Esto está muy por debajo del mínimo requerido de 3:1 para elementos no textuales de la interfaz de usuario (criterio 1.4.11 de WCAG 2.1), lo que dificultaba la percepción del estado seleccionado por parte de los usuarios con discapacidades visuales o sensibilidad al contraste de color.

Impacto en la accesibilidad

Los usuarios pueden no reconocer que esta opción es seleccionable o está seleccionada debido a la escasa distinción visual. La falta de un estilo visual claro puede provocar confusión o interacciones fallidas, especialmente entre usuarios con discapacidades visuales o dificultades cognitivas. Este patrón de selección específico se utiliza con frecuencia en el flujo de registro y en las secciones del perfil del usuario, por lo que la claridad es esencial para garantizar una interacción coherente y accesible.

Solución implementada

El color de resaltado de la selección se actualizó a #0191E4, logrando una proporción de contraste de 3.02:1 sobre el fondo blanco. Esto cumple con el umbral de WCAG 2.1 Nivel AA para el contraste de elementos no textuales (criterio 1.4.11). Ahora, el estado seleccionado es considerablemente más visible para los usuarios, especialmente aquellos con baja visión o dificultades para percibir colores.

3. Cierre del Modal de Información

Problema

Actualmente, los usuarios que navegan mediante selecciones con la tecla Tab, ya sea utilizando un lector de pantalla o un teclado, no tienen una forma clara de salir del área de enfoque seleccionada.

Impacto en la accesibilidad

Esto puede dificultar la navegación y generar una experiencia frustrante para el usuario, ya que se vuelve complicado avanzar desde la selección actual.

Solución implementada

El modal se ha actualizado para permitir su cierre mediante la tecla Escape, ofreciendo a los usuarios una forma clara y accesible de salir utilizando únicamente el teclado.

4. Perfil del Usuario

Problema

Se identificaron varios problemas de accesibilidad relacionados con la estructura y la semántica. El área principal de contenido carece de una estructura semántica HTML5 adecuada y debería estar marcada con la etiqueta <main> para ayudar a los lectores de pantalla a identificar la sección principal de la página. Los grupos de botones de opción relacionados no incluyen elementos <fieldset>, que son fundamentales para transmitir la agrupación de opciones a las tecnologías de asistencia. Además, en la sección de suscripción, el elemento desplegable “ver/ocultar” requiere mejoras para asegurar que sea completamente operable y comprensible para los usuarios de lectores de pantalla.

Impacto en la accesibilidad

La ausencia de elementos semánticos como <main> y <fieldset> puede dificultar a los usuarios que dependen de lectores de pantalla la comprensión de la estructura de la página y la relación entre los elementos del formulario. Sin estos puntos de referencia, los usuarios pueden tener dificultades para navegar de manera eficiente o interpretar correctamente las opciones agrupadas.

Solución implementada

La etiqueta HTML principal se actualizó a <nav> con un aria-label apropiado para proporcionar un contexto estructural más claro a los lectores de pantalla. Se mejoraron los contornos de enfoque para aumentar la visibilidad para los usuarios que navegan con teclado, y se refinó la navegación con tabulador para asegurar que el enfoque se desplace correctamente al seleccionar elementos de la barra lateral, permitiendo una navegación más eficiente a través de la interfaz.

5. Funcionalidad de Contabilidad

Problema

Las pruebas de accesibilidad realizadas con Accessibility Insights for Web identificaron varios problemas que afectan la usabilidad de la funcionalidad de contabilidad para los usuarios que dependen de tecnologías de asistencia. Algunos campos de entrada etiquetados no mostraban contornos de enfoque visibles, lo que dificultaba saber cuándo estaban seleccionados. El nuevo componente InvoiceToolbar (V2) no era accesible mediante navegación por tabulador, y las secciones desplegables no eran seleccionables debido a la ausencia del atributo tabIndex. Además, ciertos campos de entrada de línea no contaban con atributos aria-label adecuados, lo que limitaba el soporte para lectores de pantalla.

Impacto en la accesibilidad

Los usuarios que navegan con teclado o lectores de pantalla pueden tener dificultades para interactuar con elementos clave de la interfaz de contabilidad. Sin contornos de enfoque visibles, los usuarios que utilizan teclado podrían no saber en qué parte de la página se encuentran. Componentes que no se pueden tabular, como la barra de herramientas o las secciones desplegables, interrumpen el flujo de navegación y dificultan el acceso a acciones esenciales. La falta de atributos aria-label en los campos de entrada puede causar confusión o pérdida de información para los usuarios de lectores de pantalla, reduciendo la usabilidad e inclusión general de esta funcionalidad.

Solución implementada

Se mejoró la navegación por tabulador dentro de la lista de elementos, asegurando que cada ítem sea ahora accesible mediante teclado. Para los elementos interactivos, como los menús tipo “kebab”, se añadieron etiquetas de texto discernibles (aria-label) para que sean correctamente anunciados por los lectores de pantalla, mejorando la claridad para los usuarios no visuales.

6. Notificaciones Emergentes

Problema

Las notificaciones emergentes (toasts) no eran anunciadas por los lectores de pantalla al ser activadas, lo que provocaba que los usuarios que dependen de tecnologías de asistencia no recibieran retroalimentación importante, especialmente en los mensajes de error y éxito

Impacto en la accesibilidad

Sin roles ARIA adecuados, los lectores de pantalla no son notificados cuando aparece una notificación emergente. Esto impide que los usuarios con discapacidades visuales reciban confirmación de acciones exitosas o advertencias sobre errores, lo que puede generar confusión o hacer que se omitan pasos importantes en un flujo de trabajo.

Solución implementada

Para garantizar que las notificaciones emergentes sean accesibles, se aplicaron roles de región activa (live region) de ARIA:

  • Se añadió role=»alert» a las notificaciones de error para que se anuncien de inmediato y se interrumpa la lectura del lector de pantalla.
  • Se aplicó role=»status» a las notificaciones de éxito, permitiendo que los mensajes se lean de manera educada y no intrusiva.

Estos cambios aseguran que todos los usuarios reciban retroalimentación del sistema en tiempo real, independientemente de cómo interactúen con la interfaz.

7. Página de Bienvenida

Problema

Las pruebas automatizadas con Accessibility Insights for Web identificaron varias infracciones de accesibilidad en la página de bienvenida. Estas incluyeron:

  • Contraste insuficiente entre los colores de primer plano y de fondo (no se cumplían los umbrales de proporción de contraste definidos por WCAG 2.1 Nivel AA).
  • Etiquetas ausentes o poco descriptivas en campos de formulario y listas desplegables.
  • Enlaces sin texto discernible, lo que los hace inaccesibles para los lectores de pantalla.

Además, en la inspección visual se observó que el contorno del mensaje “¿Buscas otro servicio?” era difícil de distinguir, y que algunos botones principales de llamada a la acción (por ejemplo, “Empezar con el alta de autónomo”) usaban colores de contorno y fondo similares, lo que reducía la visibilidad del enfoque.

Impacto en la accesibilidad

El bajo contraste de color y la escasa visibilidad de los contornos dificultan que los usuarios con discapacidades visuales o daltonismo identifiquen las acciones clave y comprendan la estructura de la interfaz. La ausencia de etiquetas en los campos de formulario y enlaces impide que los lectores de pantalla los anuncien correctamente, lo que puede bloquear a los usuarios que dependen de tecnologías de asistencia para completar tareas o navegar eficazmente.

Solución implementada

Se resolvieron los problemas de contraste ajustando los colores de fondo y los contornos de los botones para cumplir con los estándares de WCAG 2.1 Nivel AA. En concreto, se cambió el color de fondo de los botones de llamada a la acción a #000000 (negro), y se mantuvo el contorno en #003CD7 para asegurar una visibilidad clara del enfoque. También se mejoró el contorno del mensaje “¿Buscas otro servicio?” para hacerlo más distinguible. Además, se actualizaron todos los campos de formulario, elementos de selección y enlaces para incluir nombres y etiquetas accesibles, garantizando así la compatibilidad total con los lectores de pantalla.

8. Enlaces de Página

Problema

Los enlaces de página utilizaban un color de contorno #CAE5FF sobre un fondo #F4F1F1, lo que resultaba en una proporción de contraste de 1.15:1. Esto no cumplía con el requisito de contraste para elementos no textuales definido por WCAG 2.1 Nivel AA, bajo el criterio de Objetos Gráficos y Componentes de la Interfaz de Usuario (1.4.11). Como resultado, el estado visible de enfoque no era lo suficientemente distinguible para los usuarios que dependen de la navegación con teclado o de señales visuales claras.

Impacto en la accesibilidad

Sin un contorno de enfoque claramente visible, los usuarios que navegan mediante teclado o tecnologías de asistencia pueden no percibir qué enlace está actualmente enfocado. Esto crea barreras para una navegación eficaz, especialmente para personas con baja visión o sensibilidad al contraste. El problema refleja una incidencia similar identificada previamente en el flujo de registro, lo que indica la necesidad de aplicar un estilo de enfoque coherente en todos los elementos interactivos.

Solución implementada

Para mejorar la visibilidad y cumplir con los requisitos de contraste, se realizaron varios ajustes visuales:

  • Se aumentó el relleno (padding) a 8px en todos los lados para proporcionar un espacio más claro alrededor del texto del enlace.
  • Se añadió un radio de esquina de 2px para suavizar el contorno y mejorar la visibilidad del enfoque.
  • Se actualizó el color del contorno a #0191E4, logrando una proporción de contraste de 3.02:1, que ahora cumple con el umbral de WCAG 2.1 Nivel AA para contraste en elementos no textuales.

Estos cambios aseguran que los estados de enfoque sean claramente perceptibles y coherentes con las mejoras de accesibilidad visual aplicadas en todo el producto.

9. Botones de Acción

Problema

El indicador de enfoque para los botones de acción estaba limitado a un contorno de 2px contenido dentro del propio botón, lo que reducía significativamente su visibilidad. Esto dificultaba la identificación visual de qué botón estaba actualmente seleccionado, especialmente en casos donde los botones estaban rodeados por otros elementos visuales.

Impacto en la accesibilidad

Para los usuarios que navegan con lectores de pantalla o teclado, el estilo de enfoque sutil dificultaba saber qué componente estaba enfocado en ese momento. Esto representaba una barrera para completar acciones clave de confirmación, ya que los usuarios podían no tener la seguridad de estar seleccionando el botón correcto. La falta de retroalimentación visual o programática clara podía generar confusión o errores en la interacción.

Solución implementada

Se actualizó el estilo de enfoque de los botones de acción para mejorar su visibilidad, asegurando un contorno de enfoque más destacado y accesible. Además, se añadió aria-disabled=»true» a los botones en estado deshabilitado, proporcionando una indicación precisa a las tecnologías de asistencia y evitando que los usuarios intenten interactuar con controles no disponibles. En la práctica, el contorno de enfoque ahora aparece fuera del componente del botón con espacio de relleno, lo que hace mucho más claro para el usuario qué elemento está actualmente seleccionado.

10. Cambio de Color del Contorno para el Botón Chip

Problema

El botón tipo chip utilizaba un color de resaltado de selección #003CD7, que también se empleaba como color de fondo en ciertos estados del componente. Esto provocaba que el contorno de enfoque se mezclara con el fondo, haciéndolo visualmente imperceptible cuando el botón estaba enfocado.

Impacto en la accesibilidad

Cuando el estado de enfoque de un botón no es visualmente distinguible, los usuarios que navegan con teclado o lectores de pantalla pueden no saber qué elemento está actualmente seleccionado. Esto puede generar dudas o errores durante la interacción, especialmente cuando los botones se utilizan para confirmar o alternar acciones importantes.

Solución implementada

El indicador de enfoque de los botones chip se actualizó para mejorar su visibilidad. Específicamente, el contorno ahora se muestra fuera del límite del componente, utilizando la combinación outline: 2px solid #003CD7; y outline-offset: 2px. Esto crea una separación visual clara entre el botón y la interfaz circundante, haciendo evidente cuándo el componente está seleccionado. El espaciado adicional asegura que el contorno siga siendo visible incluso cuando el color de fondo del botón coincide con el del contorno.

11. Menú de Perfil

Problema

La barra lateral del perfil fue implementada originalmente mediante una construcción personalizada fuera de nuestro sistema estándar de componentes, incorporando patrones de React Native que no están completamente alineados con las prácticas de accesibilidad del HTML para la web. Como resultado, carecía de elementos semánticos clave y comportamientos interactivos esperados en componentes de navegación accesibles.

Impacto en la accesibilidad

Esta implementación limitaba la capacidad de los usuarios que dependen de lectores de pantalla o navegación por teclado para acceder y gestionar la configuración de su perfil. Sin roles de navegación adecuados, indicadores de enfoque o mapeo de tabulación, los usuarios podían no saber qué elemento del menú estaba seleccionado o incluso no poder acceder al menú de perfil en absoluto.

Solución implementada

Para mejorar la accesibilidad, se realizaron varias actualizaciones en la navegación lateral:

  • Se cambió el elemento contenedor principal a una etiqueta semántica <nav> con un aria-label descriptivo, para proporcionar un contexto estructural claro a las tecnologías de asistencia.
  • Se añadió mapeo de selección por tabulación a todos los elementos del menú, permitiendo la navegación con teclado a través de la barra lateral.
  • Se introdujo un contorno de enfoque visible para asegurar que los usuarios puedan percibir fácilmente qué ítem está actualmente seleccionado.
  • Se refinó el comportamiento del enfoque para que, al seleccionar un ítem del menú, el foco se desplace correctamente a la sección asociada. Estas mejoras alinean el menú de perfil con las mejores prácticas de accesibilidad y aseguran una experiencia más coherente para todos los métodos de entrada.

12. Selección de menús desplegables

Problema

Al interactuar con menús desplegables, incluidos los componentes Select, SelectWithLabel y DatePickerWithLabel, el resaltado de selección con el color #003CD7 no se mostraba visualmente cuando el menú estaba activo. Esto significaba que, al navegar o seleccionar el desplegable mediante un lector de pantalla o teclado, no se proporcionaba ninguna retroalimentación visual.

Impacto en la accesibilidad

Sin un indicador visible de enfoque o selección, los usuarios que navegan con teclado o tecnologías de asistencia pueden no darse cuenta de que se ha activado un desplegable. Esta falta de confirmación visual puede interrumpir el flujo de la tarea y causar confusión, especialmente cuando los menús desplegables se utilizan para realizar selecciones clave o introducir datos importantes.

Solución implementada

Para mejorar la claridad y la accesibilidad, ahora se muestra un contorno de 2px en color #003CD7 cuando el componente desplegable está activo. Este cambio se aplicó a todos los componentes afectados: Select, SelectWithLabel y DatePickerWithLabel. El nuevo estilo de enfoque garantiza que los estados de selección sean visualmente evidentes durante la navegación por teclado y compatibles con la interacción mediante lectores de pantalla, apoyando una experiencia de usuario más accesible e intuitiva.

13. Componentes Desplegables en la Herramienta de Facturación

Problema

Dentro del flujo de creación de facturas, las secciones desplegables utilizadas para recopilar la dirección del cliente y la del remitente no eran accesibles mediante la tecla Tab. Como resultado, estas secciones no podían alcanzarse usando un teclado o lector de pantalla, lo que impedía a los usuarios interactuar con ellas o introducir la información requerida.

Impacto en la accesibilidad

Estos campos de dirección son esenciales para completar y enviar una factura. Si los usuarios que navegan mediante teclado o lector de pantalla no pueden acceder o activar estos componentes desplegables, podrían no ser capaces de proporcionar los datos necesarios, lo que bloquea la finalización de la tarea. Esto representa una barrera significativa para la usabilidad y la inclusión.

Solución implementada

Las secciones desplegables se actualizaron para admitir interacción completa mediante teclado. Cada contenedor fue configurado para ser seleccionable y permitir la navegación con teclado dentro del componente una vez activado. Además, se refinó la funcionalidad de expandir/desplegar, de modo que los usuarios puedan abrir la sección mediante entrada de teclado y comenzar a introducir la información de inmediato. Estas mejoras aseguran que todos los usuarios, independientemente de su método de entrada, puedan completar las facturas de forma independiente y exitosa.

14. Menú de Configuración de Facturas

Problema

El menú de configuración introducido recientemente dentro de la herramienta de facturación no admitía la navegación mediante la tecla Tab, lo que significaba que los usuarios no podían acceder ni interactuar con las opciones disponibles utilizando solo el teclado. Como resultado, ninguno de los seis elementos del menú era accesible a través de la navegación por tabulación.

Impacto en la accesibilidad

La falta de acceso mediante teclado al menú de configuración impedía que los usuarios que dependen de la navegación por teclado o lectores de pantalla pudieran realizar cambios en las configuraciones clave de la factura. Esto limitaba el control del usuario sobre cómo se configuran y presentan las facturas a los clientes, reduciendo la usabilidad y flexibilidad de la herramienta para quienes tienen necesidades de accesibilidad.

Solución implementada

Los botones de los seis elementos del menú fueron actualizados para admitir navegación mediante tabulación, garantizando que sean completamente accesibles mediante el teclado. Para mejorar la visibilidad del elemento enfocado, se aplicó un estado activo con un contorno de 2px en color #003CD7. Estas mejoras permiten que todos los usuarios accedan y modifiquen con confianza la configuración de las facturas, respaldando una experiencia de interacción más inclusiva y completa.

15. Registro de tus datos como parte del alta de autónomo

Problema

Las pruebas automatizadas con Accessibility Insights for Web identificaron múltiples problemas de accesibilidad en la sección «Registra tus datos» del flujo de alta como autónomo. Estos incluían:

  • Atributos de rol incorrectos o ausentes en los elementos.
  • Valores de autocompletado inválidos o ausentes en los campos del formulario.
  • Etiquetas de formulario faltantes (label), nombres en los campos de selección (select-name) y textos no descriptivos en los enlaces (link-name).

Estos problemas afectan tanto la estructura como la usabilidad del formulario, especialmente para usuarios que dependen de tecnologías de asistencia.

Impacto en la accesibilidad

Estos problemas pueden interrumpir significativamente la experiencia de incorporación del usuario, dificultando la navegación entre secciones, la comprensión del propósito de los campos del formulario o la identificación de acciones disponibles. Para los usuarios que utilizan lectores de pantalla o navegan con el teclado, las etiquetas poco claras y las omisiones estructurales pueden hacer que la cumplimentación del formulario sea confusa.

Solución implementada

Se realizaron varias mejoras para optimizar la accesibilidad del formulario:

  • Se corrigió el comportamiento de tabulación para permitir una navegación fluida entre secciones sin omitir campos.
  • Se revisaron y actualizaron los campos del formulario para incluir atributos de autocompletado precisos, etiquetas descriptivas y valores de rol correctos.
  • Se asignaron nombres accesibles a los enlaces y elementos de selección para garantizar la compatibilidad con lectores de pantalla.

Estos cambios proporcionan una experiencia de formulario más clara, navegable e inclusiva para todos los usuarios, especialmente durante esta parte crítica del proceso de alta.

16. El logotipo no tiene texto accesible

Problema

Las pruebas automatizadas con Accessibility Insights for Web identificaron que el enlace del logotipo en la página de inicio (<a href=»/»>) carecía de texto discernible. Esto infringe las pautas WCAG 2.4.4 (Propósito del enlace – en contexto) y WCAG 4.1.2 (Nombre, Rol, Valor), ya que los lectores de pantalla no pueden determinar el propósito del enlace. El elemento <a> no tenía texto visible ni una etiqueta asociada programáticamente (como aria-label, aria-labelledby o title), lo que lo hacía inaccesible para usuarios que dependen de tecnologías de asistencia.

Impacto en la accesibilidad

Cuando los enlaces no tienen nombres discernibles, los usuarios de lectores de pantalla no pueden entender a dónde lleva el enlace ni qué representa. En este caso, el logotipo generalmente funciona como un enlace a la página de inicio. Sin texto accesible, el usuario puede pasar por alto esta opción de navegación o dudar en interactuar con ella, lo que limita su control sobre la interfaz.

Solución implementada

El enlace del logotipo fue actualizado para incluir una etiqueta programática mediante aria-label=»Inicio» (o equivalente, según el contexto del idioma). Esto garantiza que los lectores de pantalla puedan anunciar correctamente el propósito del enlace a los usuarios. Este cambio resuelve la infracción de las pautas WCAG 2.4.4 y 4.1.2, y alinea el comportamiento del logotipo con las expectativas estándar de navegación accesible.

17. Accesibilidad de iconos

Problema

Se detectó que los componentes de iconos personalizados, que generan elementos SVG, no eran accesibles para usuarios que dependen de lectores de pantalla o navegación mediante teclado. Estos iconos no eran seleccionables, no se podían usar con entrada únicamente por teclado, y carecían de etiquetas accesibles como aria-label o title. Como resultado, no estaban disponibles para las tecnologías de asistencia.

Impacto en la accesibilidad

Los iconos que transmiten información o ejecutan acciones deben estar debidamente descritos y ser accesibles mediante teclado. Sin etiquetas accesibles ni capacidad de enfoque, los usuarios de lectores de pantalla no reciben información sobre la presencia o el propósito de estos iconos. Esto genera barreras para la comprensión e interacción, especialmente cuando los iconos se usan para acciones como editar, eliminar o ver más detalles.

Solución implementada

Los componentes de iconos se actualizaron para seguir las buenas prácticas de accesibilidad según su función:

  • Los iconos interactivos ahora incluyen un aria-label para proporcionar una descripción clara a los usuarios de lectores de pantalla.
  • También se hicieron seleccionables, lo que permite la interacción completa mediante teclado para quienes no utilizan ratón.
  • En el caso de los iconos no interactivos utilizados únicamente con fines decorativos, se aplicó aria-hidden=»true» para ocultarlos de las tecnologías de asistencia y reducir el ruido innecesario.

Estas mejoras aseguran que solo los iconos relevantes sean anunciados por los lectores de pantalla y que todos los iconos interactivos sean accesibles tanto por teclado como mediante tecnologías de asistencia.