Herramientas gratuitas para convertir voz en texto

Hace unos días, el periódico El País publicó Cuatro herramientas gratuitas para convertir voz en texto:

Cada vez es menos habitual usar el teclado del móvil. Basta con echar un vistazo alrededor para comprobar el auge de las notas de voz frente a los mensajes de texto o las nuevas formas de preguntar a Google desde estos dispositivos. En concreto, comsCore vaticina que en 2020 la mitad de las búsquedas en Internet se harán con la voz, algo para lo que contaremos con la ayuda de asistentes personales como Siri, Sherpa, Google Now, Amazon Echo o Cortana. 

Bastará con dar una orden con la voz para obtener al instante lo que queremos, sin tener que escribir esa petición. Ahora bien, de momento estos asistentes pueden quedarse cortos si necesitamos dictarles textos para ser más rápidos a la hora de redactar largos emails, preparar discursos o ponencias o incluso transcribir automáticamente mensajes de voz (por ejemplo, la grabación de una charla que queremos tener por escrito). Para este tipo de casos, existen aplicaciones web gratuitas, basadas en tecnología de Google, que es posible utilizar sin tener que instalarlas y que además cumplen con su cometido: transformar voz en texto de forma automática. 

Eso sí, conviene repasar el texto final para pulirlo o corregir posibles errores, porque aunque estas herramientas cada vez están más afinadas y también se presentan como “asistentes personales”, al fin y al cabo siguen siendo máquinas. Además, al estar basadas en Google, sólo funcionan correctamente si utilizamos el navegador de esta compañía, es decir, Chrome.

Las herramientas son:

• Google Docs
• Dictation
• Speechnotes
• Speechlogger Personal

Algunas herramientas de evaluación automática de la accesibilidad web

En Web Accessibility Evaluation Tools List hay un listado actualizado de las herramientas automáticas de evaluación de la accesibilidad web. Algunas herramientas que acabo de descubrir son:

• AccessMonitor
• European Internet Inclusion Initiative del proyecto Tingtun.
• Vamolà

Orbit Reader 20, anotador braille de bajo costo

En Orbit Reader 20, ya está disponible el esperado y asequible anotador con teclado estilo Perkins y línea Braille patrocinado por la TBG se explica:

Os presentamos un revolucionario, asequible y portátil anotador Braille con teclado estilo Perkins y una línea Braille de 20 celdas dinámicas que se ha desarrollado gracias a la unión de la TBG (Transforming Braille Group) y Orbit Research. Un dispositivo que levantó muchas expectativas cuando se presentó hace algo más de dos años, pero que hasta este verano del 2018 no se ha empezado a comercializar a un precio realmente interesante, 449$. En efecto. Habéis leído bien. Orbit Reader 20 se ha desarrollado con el objetivo de conseguir un producto económico, compacto y sencillo, pero con una funcionalidad y conectividad más que satisfactorias que permitan acceder a la educación y a la información a todas aquellas personas que no se pueden permitir el alto coste de las líneas Braille tradicionales.

La página oficial del anotador es Orbit Reader 20.

El tamaño de los controles y los enlaces

En Web Content Accessibility Guidelines (WCAG) 2.1 podemos leer:

Success Criterion 2.5.5 Target Size
(Level AAA)
The size of the target for pointer inputs is at least 44 by 44 CSS pixels except when:

• Equivalent: The target is available through an equivalent link or control on the same page that is at least 44 by 44 CSS pixels;
• Inline: The target is in a sentence or block of text;
• User Agent Control: The size of the target is determined by the user agent and is not modified by the author;
• Essential: A particular presentation of the target is essential to the information being conveyed.

Este criterio ayuda a los usuarios con discapacidad motora que carezcan de un buen control, que necesitan un área de interacción con suficiente tamaño en los enlaces y los controles de los formularios.

Un área de interacción de tamaño adecuado también puede ser útil para quienes utilizan pantallas pequeñas o de alta resolución. WCAG 2.1 sugiere que el área sea de un mínimo de 44 x 44 píxeles para los elementos interactivos.

Principios de diseño inclusivo

Inclusive Design Principles presenta unos principios a tener en cuenta cuando se quiera hacer un diseño inclusivo:

• Provide comparable experience
• Consider situation
• Be consistent
• Give control
• Offer choice
• Prioritise content
• Add value

Todos estos principios se pueden resumir en "poner a las personas lo primero":

These Inclusive Design Principles are about putting people first. It's about designing for the needs of people with permanent, temporary, situational, or changing disabilities — all of us really.

Adiós a las abreviaturas y acrónimos en los sitios web oficiales del Reino Unido

Hace unos días se publicó la noticia Goodbye, etc: why the UK government will stop using Latin abbreviations online:

RIP eg, ie and etc. Henceforth the three abbreviated Latin phrases – which stand for exempli gratia (for the sake of example), id est (that is) and et cetera (and the rest) – will stop being used on Britain’s .gov.uk websites. Eventually they will be replaced in toto by English alternatives such as such as, that is, and so on and so on.

En WCAG 2.1, el criterio de éxito 3.1.4 Abbreviations está dedicado a este problema:

(Level AAA)
A mechanism for identifying the expanded form or meaning of abbreviations is available.

inSuit, competencia de Inclusite

A través de la noticia El Ayuntamiento de Alcalá de Henares instala en su web una herramienta de accesibilidad me he enterado de la existencia de inSuit, un producto similar a Inclusite:

La mejora de la navegación con la herramienta Insuit está destinada a personas con disminución o falta de visión, dificultad o falta de movilidad en manos y brazos, incluso cuando están combinadas con dificultades para el habla o discapacidad cognitiva/intelectual. También se ha hecho más sencilla la navegación para personas mayores con dificultades para la lectura o con pocas capacidades digitales. 

Para la concejala de Transparencia, Brianda Yáñez, "es una prioridad la accesibilidad universal a los servicios municipales, un condicionante para garantizar los derechos de todas las personas sea cual sea su situación. Las herramientas digitales se están implantando a gran velocidad pero deben ser accesibles para no generar más barreras sino todo lo contrario, debemos lograr que sean facilitadoras". 

La puesta en funcionamiento de esta nueva herramienta facilitará además la navegación de todas las personas usuarias de la web, que podrán establecer algunas preferencias a la hora de consultar los contenidos. 

El usuario de la página sólo tiene que utilizar el enlace o pestaña habilitada en la página web para la activación de inSuit y tiene acceso instantáneo al conjunto de herramientas para la navegación, con un intuitivo sistema de configuración, una sencilla barra que permite adaptar las ayudas a sus necesidades y preferencias.

Deja de usar PDF en las páginas web

Por fin alguien dice algo que llevaba tiempo queriendo leer: deja de usar PDF en las páginas web.

En los últimos años, el uso y abuso de PDF para publicar contenido en los sitios web es impresionante. Y es un error, porque una cosas es un PDF y otra una página web. Me recuerda a la "epidemia" que se vivió en la primera década del siglo XXI cuando lo "cool" era usar Flash para crear sitios web, o mejor dicho, falsos sitios web.

En Why GOV.UK content should be published in HTML and not PDF se proporcionan varias razones para dejar de usar PDF en los sitios web:

• They do not change size to fit the browser
• They’re not designed for reading on screens
• It’s harder to track their use
• They cause difficulties for navigation and orientation
• They can be hard for some users to access
• They’re less likely to be kept up to date
• They’re hard to reuse

Y si PDF es tan malo ¿por qué se usa tanto? Algunas razones son:

• They’re quick and easy to create
• Control over the design
• They’re easy for people to download and print
• They have the feel of a stand-alone product

Curso "Start Building Accessible Web Applications Today"

Start Building Accessible Web Applications Today es un excelente curso sobre accesibilidad web:

• Accessible Icon Buttons
• Accessible Button Events
• Building Forms with Accessibility in Mind
• Headings and semantic structure for accessible web pages
• Focus management using CSS, HTML, and JavaScript
• What is the Accessibility Tree?
• Intro to ARIA
• How Visible vs. Hidden Elements Affect Keyboard/Screen Reader Users
• Using the Voiceover screen reader to test for accessibility
• Testing for Accessibility with the NVDA Screen Reader on Windows
• Creating visual skip links in HTML and CSS
• Accessible modal dialogs
• Using the tabindex attribute for keyboard accessibility
• Basic accessibility testing
• Accessibility testing with axe-cli

Formulario de acceso con captcha, ¿para qué?

El usuario @begoodness de Twitter me ha avisado del siguiente error.

La página web Te damos la bienvenida al Área Personal del Demandante (el título de la página ya es malo) presenta un formulario de acceso con usuario y contraseña que además añade un captcha:

Esto supone un grave problema de accesibilidad.

¿Para qué el captcha si tienes usuario y contraseña?

Seguramente lo han puesto para evitar ataques masivos. Pero en ese caso hay formas más inteligentes y menos perniciosas para el usuario: controlar la dirección IP, controlar el número de accesos en un período de tiempo, etc.