Los programas de televisión un poco más accesibles gracias a Navilens

La empresa Navilens lleva varios años trabajando con sus códigos QR para hacer más accesibles las ciudades, las tareas de la vida diaria de personas ciegas y ahora, gracias a una colaboración con la cadena de televisión Antena3, algunos programas de televisión serán más accesibles al poder aportar más información durante la emisión del programa. 

Esta cadena utiliza desde este pasado miércoles códigos QR NaviLens para que “la información ampliada” que se ofrece en su programación resulte más accesible a las personas con discapacidad visual, mayores o con dificultades de movilidad en las manos.

Aunque en principio el uso de estos códigos QR se limiten a poder acceder a artículos sobre las noticias que se están emitiendo en ese momento es posible, quizás en un futuro breve, que este sistema para ampliar información pueda utilizarse para acceder a una versión de la noticia en lectura fácil o acceder a las imágenes de la noticia y que dichas imágenes posean una descripción alternativa accesible o poder utilizar un motor de inteligencia artificial que describa dichas imágenes.

Codigos QR para múltiples propósitos 

El uso de estos códigos QR accesibles de fácil enfoque por parte de personas ciegas permiten que sean puntos de orientación y adquisición de información en el entorno. Uno de los ejemplos de accesibilidad en el entorno, también por parte de Navilens, es la ayuda a la orientación que proporciona el hotel IBIS Style Sevilla, situado cerca de la estación de Santa Justa, que mediante códigos QRA de Navilens permiten a una persona ciega moverse por el hotel de forma autónoma. En el canal de Youtube de Navilens se puede ver el video Cómo hacer un hotel más accesible. NaviLens en el Hotel IBIS Style Sevilla.

Lo que está claro es que gracias al uso de múltiples tecnologías tanto códigos QRs, ciudades cada vez más inteligentes, herramientas de asistencia para detección de obstáculos y orientación cada día encontramos que las ciudades van siendo un poco más accesibles para las personas con discapacidad sensorial.

Cómo utilizar o desactivar las reacciones de video en MacOS Sonoma

Dentro de las novedades incluidas en MacOS 14, más conocido como Sonoma, aparece una experiencia enriquecida para las videoconferencias en el que el sistema operativo añade efectos visuales como corazones, globos o lluvia cuando realizamos un gesto delante de nuestra cámara.

Lo interesante de esta característica es que la realiza el propio sistema operativo por lo que es compatible con todas las aplicaciones utilizadas para grabar video o realizar videoconferencias.

Cómo utilizar los nuevos gestos

Para que aparezcan estos efectos simplemente debemos hacer gestos con las manos y el propio sistema se encarga de pintarlos en la pantalla.

Los gestos que podemos realizar hasta ahora son:

  • Corazones: utilizando las dos manos unimos los dedos formando un corazón
  • Pulgar hacia arriba: con una mano cerramos los dedos dejando el pulgar apuntando hacia arriba
  • Fuegos artificiales: con las dos manos hacemos el gesto de pulgar hacia arriba
  • Pulgar hacia abajo: como el gesto anterior pero el dedo pulgar apunta hacia abajo
  • Lluvia: con las dos manos debemos hacer el signo de pulgar hacia abajo
  • Globos: con una mano dejamos extendidos el dedo índice y corazón haciendo el símbolo de la victoria
  • Confeti: con las dos manos hacemos el signo de la victoria
  • Laser: con la mano sólo dejamos extendidos los dedos índice y meñique haciendo el signo de cuernos

Cómo desactivar la detección de gestos

Puede que a algunas personas no quieran este servicio en sus videoconferencias y videos. Su desactivación no es tan evidente.

Para desactivar este servicio debemos hacer click en el icono de cámara que aparece en la barra de estado del Mac en la parte superior y nos aparecerá un menú para gestionar los servicios multimedia por un lado la cámara y por otro el micrófono.

Dentro de los servicios para cámara encontramos:

  • Retrato: este efecto hace que el fondo de nuestra imagen aparezca borroso
  • Luz de estudio: este efecto hace que aparezcamos iluminados de forma más uniforme
  • Reacciones: este es el efecto que reconoce nuestros gestos con las manos y hace que aparezcan los elementos visuales

Desmarcando la casilla de verificación de reacciones ya podremos hacer los gestos que queramos sin que aparezca nada pintado por pantalla.

Si eres usuario de VoiceOver el elemento de la cámara en la barra de estado se identifica como un elemento de menú de estado llamado Controles de audio y vídeo y para acceder al menú de estado hay que pulsar VO+M dos veces.

Encuesta sobre las experiencias, necesidades y sugerencias en el uso de líneas braille

El Grupo de Trabajo sobre braille de la Unión Europea de Ciegos ha elaborado una encuesta sobre las experiencias, necesidades y sugerencias en el uso de líneas braille preguntando sobre su uso en situaciones relacionadas con la educación, el trabajo y actividades de ocio.

Se busca tener un conocimiento más exacto del uso actual del braille por parte de usuarios de distintas edades y nacionalidades para ayudar a los fabricantes de este tipo de dispositivos a satisfacer las necesidades de prestaciones y rendimiento de este hardware de asistencia.

La encuesta se compone de 18 preguntas que pueden ser completadas en menos de 10 minutos.

La encuesta estará disponible hasta el 29 de febrero de 2024 y los resultados se publicarán en el sitio web de livingbraille.

Para colaborar con este estudio puedes participar en la encuesta en español.

Disponible la 10ª encuesta sobre lectores de pantalla del WebAIM

Ell WebAIM ya ha puesto a disposición de todas las personas que utilizan lector de pantallas su décima encuesta sobre el uso de estos productos de apoyo.

La encuesta estará disponible hasta el 31 de enero y sus resultados permiten conocer a los profesionales de la accesibilidad datos como cuales son las barreras de accesibilidad más importantes o más comunes para los usuarios de lector de pantallas así como otros datos de uso de este tipo de productos de apoyo.

La encuesta está en inglés pero es fácil de rellenar. Puedes participar en la encuesta de lectores de pantallas en el portal del WebAIM.

Disponible el número 2 del podcast Accesibilidad con tecnologías libres

Ya está disponible el número 2 del podcast Accesibilidad con tecnologías libres en el que se habla de accesibilidad web, herramientas de asistencia para personas con discapacidad física, visores de realidad virtual y realidad aumentada y sistemas de reconocimiento de voz parra transcripción de audios.

Puedes suscribirte al podcast en las plataformas habituales o utilizando su página de sindicación.

Cómo notificar de forma apropiada un error en una aplicación o servicio

A la hora de mejorar y mantener un producto software los desarrolladores utilizan el feedback proporcionado por los usuarios a través de lo que se conoce como bug report o feedback report. Un bug report es un mensaje de un usuario al desarrollador indicando que hay un problema en una aplicación.

Este mensaje se puede enviar a través de correo electrónico, mediante una plataforma web de gestión de errores, a través de chat o a través del canal que el desarrollador haya proporcionado para la comunicación con los usuarios.

Un bug report efectivo

En muchas ocasiones los reportes de error enviados por los usuarios son totalmente inútiles y poco efectivos ya que se limitan a mensajes del tipo la app no funciona. Es evidente que si se envía un reporte de error es porque el usuario ha encontrado que algo no funciona pero los desarrolladores, por ahora, no podemos leer el pensamiento de los usuarios por lo que es necesario dar más detalles sobre qué no funciona para encontrar respuesta a la pregunta de por qué no funciona y cómo hace el usuario para que no funcione ya que los desarrolladores antes de publicar sus aplicaciones realizan multitud de pruebas de uso y puede que conocer cómo utilizan su aplicación otras personas les permita mejorar el uso de la misma.

Además, decir que la app no funciona es algo muy general. Una app pequeña tiene entre 4 y 15 pantallas por lo que es de agradecer un poco más de información.

Qué incluir en un reporte de error

A la hora de enviar un reporte de error es muy recomendable incluir los siguientes apartados:

Descripción breve del problema

En un par de párrafos describir qué error sucede. Se recomienda incluir el nombre de la aplicación, en qué pantalla sucede y cómo llegó a esa pantalla.

Paso a paso

Incluir una lista de pasos desde que se abre la aplicación hasta que se obtiene el error o el comportamiento no esperado.

También se debe incluir un paso indicando que se activa el lector de pantallas, el magnificador o cualquier otro producto de apoyo que se esté utilizando ya que a veces los errores sólo suceden con un producto de apoyo.

Además, si el producto de apoyo o la aplicación tiene alguna personalización o ajuste especial que provoque el problema también es necesario indicarlo.

Resultados esperados y resultados obtenidos

Este apartado sirve para indicar qué esperaba el usuario que sucediese y qué es lo que sucede realmente. A veces el problema no es de software sino de lenguaje empleado. El usuario entendió que debería pasar una cosa pero el desarrollador no se explicó bien en el manual o las instrucciones en la aplicación. Este tipo de informes de error permiten solucionar este tipo de problemas de malentendidos o para comprender qué experiencia de uso tienen los usuarios ante ciertas situaciones provocadas por sus aplicaciones.

Los resultados esperados y resultados obtenidos suelen ser un par de párrafos describiendo ambos elementos.

Observaciones

Este apartado suele ser un texto beve donde el usuario puede aportar más información sobre, por ejemplo, si está utilizando el dispositivo con una configuración determinada (por ejemplo un iPhone configurado en Español de USA con modo oscuro y con auriculares), el modelo de su dispositivo o si tenía algún dispositivo más conectado.

Adjuntos al reporte

Adjunto al reporte de errores es recomendable incluir un adjunto con un informe de comportamiento o fichero de log que permita al desarrollador ver el comportamiento interno de la aplicación cuando sucedía el problema.

Si el apartado de paso a paso es muy detallado no es necesario incluir ningún adjunto a menos que el problema lo tenga un usuario en concreto y pueda ser por una configuración muy concreta o un fallo colateral en ese dispositivo concreto. Estos ficheros de log permiten encontrar esa información tan concreta que no es evidente ni para el usuario ni para el desarrollador. 

En la mayoría de ocasiones se piden estos ficheros en una segunda comunicación sólo si el desarrollador no ha podido reproducir el problema reportado por el usuario y tras seguir el paso a paso indicado.

Siempre con educación

Es algo que puede parecer evidente cuando nos comunicamos con otra persona pero es algo que muchas veces se olvida. Si un usuario espera que otra persona atienda a su mensaje con buena disposición es necesario un trato cordial y sin caer en insultos o palabras despectivas hacia la persona que desarrolla el software, su inteligencia o su progenie.

En varias ocasiones he desechado o ignorado reportes de error por estar mal estructurados, no aportar información suficiente o utilizar un lenguaje inapropiado. Y como yo conozco a muchos desarrolladores que hacen lo mismo ya que se considera que ese tipo de feddback no es beneficioso para el software.

Buscando el entendimiento

A veces también hay un problema de comunicación entre el usuario y el desarrollador por el lenguaje empleado. Puede que el usuario no sepa hablar francés y el desarrollador no sepa hablar japonés. En estos casos siempre es recomendable utilizar un idioma neutral, siendo el más común en el desarrollo de software utilizar inglés, y utilizando una herramienta de traducción incluir dentro del texto un aviso indicando que la persona habla en un idioma concreto y que este texto ha sido traducido al inglés gracias a una herramienta de traducción. Esto permite a ambas partes estar atentos a posibles malentendidos a causa de un error en la traducción.