Categoría: Accesibilidad

Artículos sobre accesibilidad y diseño para todos

Cómo crear una voz sintética con tu propia voz en macOS

Publicado el

La voz es una parte esencial de la identidad. No solo transmite información, también comunica personalidad, intención, estado de ánimo y cercanía. Por ese motivo, la posibilidad de conservar la voz y usarla como voz sintética en un ordenador no es un simple capricho tecnológico: es una herramienta con impacto real en autonomía, accesibilidad y dignidad, especialmente para personas que pueden perder la capacidad de hablar o que necesitan apoyos de comunicación.

También las personas con trastorno del espectro autista u otros perfiles de discapacidad cognitiva se pueden beneficiar de esta característica al incluir la voz de un familiar o un terapeuta de confianza para la persona. De esta forma la atención y la seguridad se unen a los beneficios de esta característica.

En el ecosistema de Apple podemos encontrar Personal Voice, más conocido como Voz personal, una función de accesibilidad que permite crear una voz sintética a partir de las grabaciones de una voz humana real.

Esta voz puede ser utilizada en el sistema para las notificaciones, el servicio de Live Speech (Voz en tiempo real) o para VoiceOver, el lector de pantallas de Apple.

Requisitos y consideraciones antes de empezar

En macOS Personal Voice está disponible solo en ordenadores con procesadores Apple silicon, y no está disponible en todos los idiomas o regiones. Además, Apple indica que para crear una Voz personal en el Mac necesitas tener contraseña de inicio de sesión configurada, ya que se solicita durante el proceso de creación.

Aunque el proceso oficialmente dura pocos minutos, este tiempo dependerá de la versión del hardware y del sistema operativo que estemos utilizando.

Crear tu voz paso a paso

En el menú de ajustes del Mac, debemos ir al apartado de accesibilidad y allí buscar la opción de Voz personal.

Dentro encontraremos el botón Crear una voz personal. Este botón comienza el proceso de creación.

Además en esta pantalla encontramos información sobre esta característica de accesibilidad, cuántas voces tenemos creadas, si queremos compartir nuestra voz con todos nuestros dispositivos de Apple y si queremos que nuestra voz pueda ser utilizada por otras aplicaciones como, por ejemplo, aplicaciones de lectura de libros.

El proceso de creación

Al pulsar el botón de Crear una voz personal daremos comienzo al proceso de creación.

Al comenzar el proceso de creación el sistema te guiará por una grabación de frases. El objetivo de estas lecturas es capturar suficientes muestras para que el modelo genere una voz que se parezca a la voz original.

Se puede grabar con el micrófono integrado del Macbook, pero se recomienda un micrófono externo o unos auriculares con micrófono integrado ya que con mejor calidad en la grabación obtendremos mayor calidad en la voz resultante.

Aparecerá la petición de autenticación en tu cuenta de iCloud. Tras identificarnos aparecerá un diálogo con información sobre el proceso:

Grábate,

Tendrás que leer en voz alta un conjunto de 10 frases.

Genera tu voz personal,

El Mac creará tu voz personal y la almacenará de forma segura.

Usa tu voz personal,

Usa la voz en tiempo real para decir lo que escribas.

Si has creado una voz personal, también la podrás usar con las funciones de lectura y voz, VoiceOver y las apps de comunicación aumentativa.

Y unos botones para cancelar y continuar.

Apple también contempla la posibilidad de pausar y retomar el proceso, guardando el progreso para continuar en otro momento.

Al pulsar el botón de Continuar deberemos seleccionar el idioma para realizar la grabación.

En el momento de escribir este artículo los idiomas disponibles son: inglés de Estados unidos, español de México y chino mandarín de China continental.

En nuestro caso elegiremos español y volveremos a pulsar en Continuar.

En el siguiente paso el sistema nos pregunta por el nombre que le daremos a la voz.

Luego se necesita realizar una descarga de un contenido previo para la grabación de 1Gb. Debemos esperar a que termine la descarga.

Si se necesita configurar algún aspecto de la red se puede volver al proceso al abrir de nuevo los ajustes del Macbook, accesibilidad y de nuevo entrar en el panel de Voz personal.

En la lista de voces veremos nuestra voz en un estado similar a quedan 10 frases por grabar.

Al terminar de grabar las frases el procesamiento se realizará de forma segura en el propio dispositivo y el sistema te avisará cuando la voz esté lista para usarse.

Durante el proceso de grabación tendremos que verbalizar frases del tipo: Estoy creando una voz personal con mi Mac, ¿Te gusta coleccionar pósters de películas?, .

En el caso de utilizar lector de pantallas es recomendable que utilicemos auriculares para evitar que la voz de VoiceOver se mezcle con la grabación.

Cada vez que grabemos una de las frases, pulsando el botón de grabar, podemos escuchar el resultado o pasar a la siguiente frase.

Una vez terminado el proceso de grabación se mostrará un mensaje del tipo:

Recibirás una notificación,

Cuando se haya terminado de generar tu voz personal, recibirás una notificación. El proceso no debería tardar más de un minuto..

Recomendaciones prácticas para una mejor calidad

Aunque el sistema guía el proceso, la calidad final suele mejorar cuando se graba en un entorno silencioso y estable, se mantiene una distancia constante al micrófono y se evita cambios bruscos de postura.

También ayuda leer con una dicción natural, sin forzar un tono de locutor, porque el objetivo no es interpretar, sino capturar la voz cotidiana. Si se tiene fatiga vocal, es preferible pausar y continuar más tarde; Apple permite retomar la grabación sin perder el progreso.

Uso de nuestra voz personal

Una vez creada la voz podemos activarla para compartirla entre todos nuestros dispositivos y con otras aplicaciones.Podemos realizar una prueba con la función de Voz en tiempo real que aparece en los ajustes de accesibilidad de nuestro Mac. Para ello en el campo de idioma dejamos el valor de Idioma de voz del sistema y como voz seleccionamos el nombre de nuestra voz personal.En el campo de frases para hablar introducimos el texto que queremos verbalizar y pulsamos el botón Hablar o pulsamos la tecla enter.

Creación de la voz en otros dispositivos

Este proceso también se puede completar en un iPhone, un iPad o unas Apple Vision Pro. Se recomienda realizar, en cambio, el proceso en el Mac porque el procesador es más potente y se pueden utilizar micrófonos externos con mayor facilidad.

Se puede consultar la ayuda oficial de Apple para la creación de voces en su portal de soporte.

Tutoriales para Vox libri en el canal de Alibluebox de Whatsapp

Publicado el

Los amigos de AliBlueBox han publicado recientemente unos tutoriales para aprender a utilizar mejor la aplicación de Vox libri.

En estos videos se detallan los siguientes elementos de la aplicación:

  • Cómo consultar toda la información de los libros que importas.
  • Explicación detallada de la barra de progreso y todo lo que ofrece.
  • Un recorrido completo por las distintas formas de navegación dentro del libro.

Este contenido está dentro del canal de Whatsapp de AliBlueBox por lo que necesitarás suscribirte a su canal para disfrutar de estos contenidos.

La importancia de integrar la accesibilidad de forma temprana

Publicado el

La accesibilidad digital ya no puede considerarse como una tarea aislada ni como una etapa tardía de un proyecto. El enfoque conocido como shifting left en accesibilidad implica integrar criterios de inclusión desde las primeras fases del desarrollo desde la estrategia y la definición de requerimientos en lugar de retrasarlos al test final o a una fase de corrección previa al lanzamiento de un producto o servicio.

La práctica del shifting left no sólo mejora la experiencia de los usuarios, incluidas las personas con discapacidad, también repercute positivamente en la eficiencia del equipo, la calidad del producto, el cumplimiento normativo y la contención de costes en el proyecto.

Cuando la accesibilidad se aborda de forma temprana, se favorece una experiencia verdaderamente universal. Los usuarios con discapacidad por ejemplo personas con baja visión, sordera, dificultades de movilidad o discapacidad cognitiva se benefician de una interfaz diseñada con ellos en mente desde el inicio, y a la vez se mejora la usabilidad para todos los demás. Lo que se diseña con criterios de accesibilidad tiende a resultar más claro, más usable, más compatible y más duradero. Además, al evitar que los problemas de accesibilidad se acumulen o solo se detecten al final, se reduce las tareas de reconstrucción y aplicación de parches, se minimiza la deuda técnica y se evita el elevado coste de corrección que suele surgir cuando un defecto o barrera llega hasta producción.

El reparto de responsabilidades

Desde el punto de vista estratégico mover la accesibilidad hacia la izquierda del cronograma significa que cada rol del equipo asume responsabilidades concretas en distintos momentos del ciclo de vida del proyecto. Los estrategas, por ejemplo, deben asegurarse de que la arquitectura de la información, los flujos de usuario y las decisiones de contenido contemplen personas con discapacidad en sus perfiles y contextos de uso. Se deben plantear requisitos funcionales que incluyan criterios de accesibilidad como por ejemplo navegación mediante teclado, compatibilidad con lector de pantallas, descripciones alternativas de imágenes y explicar por qué estos importan tanto para una experiencia inclusiva.
Los diseñadores tienen la misión de aplicar desde muy temprano en los wireframes y prototipos principios como alto contraste de color, tipografías legibles, orden lógico de encabezados, espaciamiento adecuado, indicadores de foco, tamaño mínimo de zonas táctiles y opciones para reducir el movimiento.
Al hacerlo de esta manera, se crean componentes de diseño que facilitan una implementación accesible y evitan que el desarrollador tenga que arreglar errores complejos más adelante.

En la fase de desarrollo, tanto front-end como back-end juegan un papel esencial: los desarrolladores front-end deben aplicar marcado semántico correcto, roles ARIA sólo cuando se requieren, gestión efectiva del foco, navegación por teclado, estados visibles de los controles, compatibilidad con tecnologías de asistencia.

Los desarrolladores back-end deben asegurarse de que la estructura generada respete los criterios de accesibilidad, documentar las decisiones, automatizar pruebas accesibles en el flujo de integración continua y reducir la deuda de accesibilidad futura.

El equipo de QA debe incluir auditorías de accesibilidad automatizadas y manuales en el ciclo de verificación: no esperar al último sprint, más bien que la accesibilidad sea parte del definition of done.

En paralelo, los creadores de contenido como editores de texto, gestores de CMS o responsables de medios también tienen responsabilidades específicas: redactar en lenguaje claro, usar estructuras de encabezado correctas, proporcionar alternativas textuales para imágenes, vídeos subtitulados, evitar texto incrustado en imágenes y asegurar la coherencia entre contenido y navegación.

Si todos estos roles trabajan de forma coordinada desde el inicio, se genera una cultura de accesibilidad que atraviesa todo el proceso y evita que la accesibilidad sea un añadido apresurado, costoso e insuficiente.

Después de la publicación

Pero el trabajo no termina con el lanzamiento del sitio web o la entrega de la aplicación. La accesibilidad requiere mantenimiento continuo. Las nuevas funcionalidades, el nuevo contenido, las integraciones de terceros, las actualizaciones de plataforma pueden introducir regresiones de accesibilidad.

Por esta razón es necesario establecer mecanismos de monitorización como dashboards de accesibilidad, auditorías periódicas automatizadas, revisiones manuales cuando sean necesarias y formación continua del equipo para mantener actualizado el conocimiento sobre pautas como World Wide Web Consortium (W3C) y estándares legales locales.

También debe existir un compromiso organizativo que vincule la accesibilidad a métricas, a cultura interna, a responsabilidad compartida en los distintos equipos y al ciclo de vida completo del producto digital.

En definitiva, integrar la accesibilidad desde el arranque del proyecto digital mediante la estrategia de shifting left permite no solo cumplir con criterios éticos y legales, sino construir productos más robustos, usables y sostenibles. Equipos que adoptan este enfoque logran una experiencia más inclusiva, reducen costes de corrección, aceleran la entrega y evitan que la accesibilidad se convierta en un parche final. En un mundo en el que una proporción significativa de la población vive con alguna discapacidad o circunstancia temporal de uso, este enfoque deja de ser opcional y se convierte en una ventaja estratégica.

Qué es Axe DevTools

Publicado el

La herramienta axe DevTools es un kit profesional destinado a la evaluación de accesibilidad digital, diseñado para desarrolladores, testers y equipos de producto que requieren una cobertura automatizada de los requisitos de accesibilidad definidos por el estándar WCAG (Web Content Accessibility Guidelines). Está desarrollada por la empresa Deque Systems y se apoya en el motor de reglas de código abierto axe‑core, lo que garantiza que los análisis estén fundamentados en un conjunto robusto de comprobaciones de accesibilidad.

La extensión axe DevTools funciona como un complemento para navegadores web que permite identificar de forma automática numerosos errores de accesibilidad, comparables a lo que ofrecen otras herramientas como WAVE Evaluation Tool, aunque con un enfoque más detallado, profesional y orientado al ciclo de desarrollo. A diferencia de WAVE, que se orienta más a una evaluación de entrada para diseñadores y equipos de contenido, axe DevTools ofrece informes técnicos profundos, integración con flujos de testing y configuración orientada a desarrolladores. De hecho, en sus documentos se describe explícitamente que el propósito es empoderar a los equipos de desarrollo web y móvil a encontrar, prevenir y corregir problemas de accesibilidad mientras codifican.

Informes técnicos

El valor diferencial de axe DevTools se encuentra en los informes técnicos que genera para desarrolladores. Una vez lanzado el escaneo de una página o aplicación, la herramienta presenta una lista de problemas detectados, cada uno con su nivel de severidad (crítico, serio, moderado, menor), el estándar o criterio WCAG que infringe, un fragmento de código fuente o apuntador al DOM, y la capacidad de resaltar la ubicación del problema en la página. Para cada problema, la herramienta incluye orientación de corrección (remediation guidance), lo que facilita que los desarrolladores comprendan y apliquen la solución. Además, dado que está impulsada por el motor axe-core, minimiza los falsos positivos, lo que contribuye a que los equipos de desarrollo no pierdan tiempo.

Además, la herramienta ofrece capacidades de exportación y compartición de resultados, lo que permite que los desarrolladores integren esos informes en sistemas de seguimiento de incidencias o los compartan con otros miembros del equipo (por ejemplo testers de accesibilidad, QA o equipo de producto). También existe la posibilidad de análisis de componentes individuales, lo que permite una granularidad mayor cuando se trabaja por módulos o micro frontends.

Integración con flujos de testing

Otras de las características interesantes de esta herramienta es la integración con los flujos de testing.

Las APIs de axe DevTools permiten su uso dentro de entornos automatizados, sistemas de integración continua (CI), pruebas end-to-end y frameworks como Cypress, Playwright, Puppeteer, WebDriver, así como lenguajes de scripting como JavaScript/Node.js, C#, Java, Python o Ruby.
De esta forma, un equipo puede configurar, gracias a la documentación de la herramienta, que cada build automatizada ejecute un análisis de accesibilidad y genere un reporte; si aparecen violaciones de accesibilidad, puede bloquearse la entrega o abrirse automáticamente una incidencia. Esto permite que la accesibilidad sea parte del proceso de calidad desde el inicio y no sólo al final.
Complementariamente, en la extensión de navegador se habilita una modalidad Intelligent Guided Tests (IGT) que guía al tester o desarrollador sobre pruebas que no son detectables automáticamente, reduciendo el volumen de pruebas manuales que aún son necesarias.
De esta manera, axe DevTools puede funcionar tanto de forma interactiva (desde el navegador) como en modo automatizado dentro del pipeline de desarrollo, incrementando la cobertura de accesibilidad sin necesidad de que cada desarrollador sea un experto en accesibilidad.

Qué es el Inspector de accesibilidad de Firefox Developer Tools

Publicado el

El Firefox Accessibility Inspector es un panel especializado dentro de las herramientas de desarrollo del navegador que expone el llamado árbol de accesibilidad una estructura que representa cómo se presenta el contenido web a los agentes de asistencia, mostrando para cada nodo información como el rol, el nombre accesible, los estados, las relaciones y otros atributos ligados a la accesibilidad.

El  Accessibility Inspector está integrado en el navegador Mozilla Firefox y permite a los desarrolladores web examinar la forma en que las tecnologías de asistencia, como los lectores de pantalla, interpretan la estructura de una página web. Esta funcionalidad está disponible desde la versión 61 de Firefox.

Mediante este inspector, el desarrollador puede activar el motor de accesibilidad del navegador y desplazar un foco de inspección que muestra cómo un lector de pantalla “vería” o interpretaría un elemento concreto del sitio, o incluso la página en su conjunto.

Una de las funciones fundamentales del inspector es ofrecer una vista jerárquica del árbol de accesibilidad (accessibility tree), que difiere del árbol DOM en cuanto incluye únicamente los elementos expuestos a las tecnologías de asistencia. En esa vista, cada nodo presenta al menos dos propiedades clave: un rol (por ejemplo button, link, heading) y un nombre (que para los controles suele venir del texto de su etiqueta).

Además, cuando se selecciona un nodo, se muestra un panel con detalles más extensos: nombre, rol, acciones disponibles (por ejemplo “Press” para un botón), valor (en caso de un campo de entrada), DOM Node asociado, descripción, atajo de teclado, índices en el padre, conteo de hijos, estados (como focusable, enabled, selected), relaciones con otros nodos (por ejemplo “labelled by”), y atributos de accesibilidad relevantes o relacionados con ARIA (por ejemplo aria-label, aria-hidden, role, etc.).

La herramienta incluye utilidades de diagnóstico automatizado: permite activar un análisis de “Check for issues” (verificar problemas) que scaneará toda la página en busca de diferentes tipos de fallos contraste de color insuficiente, problemas de navegación mediante teclado, etiquetas de texto faltantes y resaltará únicamente los nodos que presentan esos problemas. Además, el inspector permite simular deficiencias de visión de color (simulación de daltonismo) o mostrar la orden de tabulación de los elementos. Todo ello ayuda al desarrollador a comprender y corregir cómo una página estaría siendo percibida por personas que utilizan lectores de pantalla u otros dispositivos de asistencia, lo cual es esencial para asegurar que el HTML semántico, el uso de ARIA y la estructura del contenido soporten una experiencia inclusiva.

Google Lighthouse como herramienta de evaluación de la accesibilidad

Publicado el

Google Lighthouse es una herramienta automatizada de auditoría integrada en el navegador Google Chrome, diseñada para evaluar diversos aspectos de calidad en cualquier página web, desde el rendimiento y la optimización para motores de búsqueda hasta ciertos criterios fundamentales de accesibilidad.
Lighthouse forma parte del ecosistema de herramientas de Google orientadas al análisis y diagnóstico web.
Esta herramienta se ejecuta desde las DevTools de Chrome, desde la línea de comandos o mediante su versión en línea, y proporciona informes detallados que permiten comprender el estado técnico de un sitio web.
El funcionamiento de Lighthouse se basa en la recopilación estructurada de métricas relacionadas con la carga, la estabilidad visual, el procesamiento del contenido y los metadatos de la página. En el ámbito del rendimiento, la herramienta mide el tiempo de interacción, de renderizado y la eficiencia en el uso de recursos; en el ámbito del SEO, analiza la correcta estructuración de elementos fundamentales para la indexación, como etiquetas meta, atributos descriptivos o la accesibilidad del contenido para los robots de búsqueda.
Además, la sección de accesibilidad realiza una serie de comprobaciones técnicas que identifican ciertos problemas habituales como la falta de texto alternativo, la insuficiente estructura semántica o la ausencia de etiquetas asociadas a controles interactivos.

Es importante señalar que, aunque Lighthouse incorpora una auditoría de accesibilidad basada en reglas automatizadas, su fiabilidad es limitada cuando se interpreta como un verificador exhaustivo de barreras de accesibilidad. La herramienta detecta únicamente una parte de las barreras existentes, aquellas que pueden evaluarse de forma automática sin intervención humana. Aspectos esenciales como la claridad de las descripciones alternativas, la adecuación de la estructura lógica del contenido, la comprensibilidad de los textos, la calidad de la interacción mediante teclado o la experiencia global de usuarios con diversas discapacidades requieren un análisis manual basado en las pautas WCAG. Por esta razón, Lighthouse no puede considerarse una herramienta específica para la mejora integral de la accesibilidad web, sino un complemento orientado a la detección preliminar de problemas comunes y al apoyo en procesos de auditoría más amplios.

A pesar de estas limitaciones, los resultados proporcionados por Lighthouse ofrecen valor en procesos de diseño y desarrollo, ya que permiten identificar rápidamente fallos críticos que afectan a la experiencia de usuario, al posicionamiento en buscadores y al rendimiento general del sitio. La interpretación de sus métricas debe realizarse de manera contextualizada, entendiendo que sus diagnósticos no sustituyen a una revisión profesional de accesibilidad ni a pruebas con usuarios reales, pero sí constituyen una base inicial para orientar esfuerzos de optimización y asegurar un nivel mínimo de calidad técnica.