Magazine veraniego de noticias sobre accesibilidad
![](https://accesibilidadtl.gitlab.io/images/logo-ATL-opt.png)
Programa 08:
- Rompiendo barreras, con Eva Marco. Nos describe los "Principios de diseño inclusivo".
- 00:08:55 Odisea en el ciberespacio, con David Marzal.
- Mozilla está experimentando con la generación local del ALT text, por ahora (FF130) en imagenes de PDF, pero con intención de generalizarlo en el navegador.
- Y siguiendo con Mozilla, ya implementado, tenemos la funcionalidad de captura de pantalla ahora se puede usar en más sitios y en materia de accesibilidad tiene atajos de teclado y un soporte para temas o modo de Alto Contraste.
- Se esta desarrollando una nueva arquitectura de accesibilidad llamada Newton para mejorar la actual AT-SPI, ya que será nativamente compatible con Wayland
- Fedora tiene un grupo de accesibilidad, aquí os dejo un vídeo presentación y su sala de Matrix
- Podcasts en ingles dirigidos a invidentes: reviews de hardware y juegos y otro sobre tecnología, viajes y auto-cuidados
- Articulo con 4 vídeos sobre como testear la accesibilidad en tus proyectos
- Aplicación para revisar la accesibilidad
- 00:17:29 Accesibilidad web, con Pablo Arias. Nos habla sobre de los formularios web.
- 00:33:42 Diseño para todos, con Jonathan Chacón. Nos comenta sobre las smartcities y las ayudas a la orientación en la ciudades.
Subtítulos disponibles en steno.fm si vuestra aplicación no los implementa.
Enlace a comentarios por si vuestra aplicación no los implementa.
Transcripción completa pinchando aquí
Y en la sección de Rompiendo Barreras, con Eva Marco, vamos
a continuar con la parte de diseño, ¿verdad Eva?
Sí, buenos días. Jorge, ¿qué tal?
Bien, de momento el calor no nos afecta demasiado.
Pues, como has dicho, el otro día estuve hablando de diseño
accesible, que es el que se encarga de
diseñar productos y aplicaciones que rompan con las dificultades
que tiene una persona con discapacidad para poder acceder.
Pero hoy os quería hablar del diseño inclusivo, que parece
lo mismo, pero no lo es. El inclusivo es una metodología
mucho más amplia, que abarca todo lo que hace el diseño
accesible, pero se enfoca a más cosas, a
un público mucho más global. Intentamos diseñar para que
personas de diferentes culturas, diferentes accesos,
diferentes entornos, diferentes espectros, también puedan acceder,
no solo a las personas que tienen discapacidad.
Así que intentamos tener en cuenta el género, la etnia, la
edad de la persona, contextos...
...económicos de esas personas, etcétera, ¿vale?
El diseño inclusivo se basa en siete principios principales,
que son los que tenemos que tener en mente si queremos
hacer que nuestro diseño, nuestra aplicación, también
sea inclusiva. Os voy a ir contando un poquito
a poco y os voy a dar un ejemplo de cada uno,
para que lo entendamos, y si cualquier cosa me paras, ¿vale?
Si ves que hablo demasiado de algún tema.
Vale, el primer principio es proporcionar experiencias
comparables. Este principio nos habla de que
tenemos que intentar conseguir que,
todos los usuarios, tengan la misma experiencia, usando
nuestra aplicación. Voy a hablar de aplicación,
pero se extiende a páginas web, a productos, etcétera, ¿vale?
Haciendo que los usuarios tengan la misma experiencia,
obtendrán la misma información
y los mismos resultados. ¿Cómo podemos conseguir esto?
Pues, como habló Pablo el otro día, usando textos alternativos.
Una persona vidente puede ver la imagen, una persona no vidente
puede leer texto y obtener la misma información,
o añadir una descripción a un vídeo,
o poner descripciones en formato de audio de algún contenido
que... que pongamos.
Un ejemplo en concreto podría ser una web de comercio que,
así como una foto del producto que quieres vender, haya una
descripción de audio de ese producto.
Así, todas las personas podrían comprar en igualdad de
condiciones. Segundo principio, tenemos que
tener en cuenta la situación del usuario.
¿Qué quiere decir esto? El usuario puede usar nuestra
aplicación o producto en situaciones muy diferentes,
y si las tenemos en cuenta, todos podrán obtener una
experiencia similar. Un ejemplo de esto, por ejemplo,
en una aplicación de navegación, puedes ir andando,
con ella, y la tienes en la mano, sería una situación
puntual. Si la llevas en el salpicadero
del coche, podría ser otra situación.
Pero si entras en un túnel, tu situación cambia.
Entonces, si tenemos en cuenta, pues eso, un modo oscuro, un
modo andar, un modo alto contra brillo,
porque estás a pleno sol y estás andando con ella,
si consigues diseñar tu aplicación con esas diferentes situaciones,
pues todos los usuarios tendrán un acceso agradable a la misma.
El tercer punto podría ser: ser coherente.
Esto quiere decir que tenemos que intentar mantener la misma
estructura, los mismos métodos, los mismos sistemas para hacer
las cosas a lo largo de toda nuestra aplicación.
Con un ejemplo se entiende mucho más fácil.
Si nosotros tenemos una plataforma de vídeos de aprendizaje,
y sabemos que los recursos están en el panel de la
izquierda, que en el panel de la derecha tenemos acceso a
puntos en concreto del vídeo, y abajo
tenemos una caja donde puedes comentar, y todos los vídeos
tienen la misma estructura. Al cuarto vídeo ya sabes
dónde ir a buscar los recursos, dónde ir a buscar los puntos
del vídeo, etcétera. Entonces, si somos coherentes,
facilitamos mucho más el uso de nuestra aplicación o
página. No andar mareando al usuario,
va. Exactamente, si en cada
contexto le cambiamos las cosas, en cada contexto tiene que
aprender, o buscar, o investigar a ver
dónde están las cosas, y eso es una complejidad enorme que
no merece la pena. Entonces, la técnica esta de
los supermercados, de andar cambiando las cosas de sitio,
no la creemos aquí. No.
No, no, no, además para ellos tampoco es muy buena idea, así
que no sé por qué la hacen. El cuarto principio del diseño
inclusivo sería otorgar el control al usuario.
¿Qué quiere decir esto? Pues, es el usuario el que debe
elegir cómo interactuar con nuestra página y no al revés.
No tenemos que forzarle a, por ejemplo, no le podemos bloquear
el scroll. Si el usuario quiere hacer el
scroll con ratón, permíteselo. No hay ninguna razón para que
tú le digas al usuario qué es lo que puede usar o lo que no.
Otro ejemplo, si tu página tiene un montón de animaciones,
a lo mejor a ti te encanta y es estupendo,
pero a lo mejor hay otra persona que esas animaciones le
provocan un ataque o le marean. Entonces, si le permites poner
las animaciones o quitarlas al gusto,
le estás dando el control al usuario y él puede decidir
qué es lo que quiere hacer y estar cómodo en tu página.
Por ejemplo, en una aplicación de lectura que puedas cambiar
el color del fondo de la página,
que puedas cambiar el tamaño de la letra.
Dale al usuario opciones para que él pueda sentirse cómodo
y en control, como dice el principio.
La quinta, tienes que ofrecer alternativas al usuario.
Es decir, si yo tengo que completar una acción y solo ofrezco
una manera de completar esa acción, si una persona no puede usar
esa manera que yo le estoy permitiendo, le bloqueo
totalmente. Entonces, cuando sea posible,
hay que intentar ofrecer más de una.
Por ejemplo, yo quiero completar una acción.
Por ejemplo, hacer un submit, ¿vale?
Submit es pulsar un botón y enviar un formulario.
Si solo doy la opción del clic con el ratón, un usuario que
no use ratón no puede hacer ese submit.
¿Qué otra opción puedo dar? Pues usar teclado, por ejemplo,
que también admita un intro. O, por ejemplo, tengo una
gráfica de barras y eje X e Y. Si hay alguien que no entiende
esa gráfica porque tiene alguna dificultad,
si le ofrecemos esos datos de esa gráfica visuales en una
tabla, a lo mejor su lector de
pantalla se los puede consumir y ofrecérselos de esa manera.
Tenemos que intentar dar la mayor número de alternativas
posible. Obviamente, hay casos que solo
tendrás una y no será posible más que esa y ya está.
Pero cuantas más, mejor. Aquí entran, por ejemplo,
también los subtítulos. Hemos hablado antes de subtítulos.
Aquí también se podría ofrecer ahí una de las alternativas.
Podría ser no solo de Zoom Video, sino también de la
transcripción en texto. Punto seis, priorizar el
contenido. Lo hablábamos un poco también.
En el capítulo anterior, que el contenido tiene que ser
sencillo de entender, que tiene que estar bien colocado,
tiene que ser de fácil de lectura. Hablábamos un poquito el otro
día. Pues aquí un poco vuelve a
redundar sobre el mismo tema. Lo que tenemos que intentar es
que el contenido principal sea lo que ya te llame la atención,
lo que esté en el punto de vista principal, que sea fácil
de acceder y entender y evitar todas las distracciones
alrededor que nos oculten este contenido.
Por ejemplo, una web de noticias. Si tienes millones de anuncios,
que te salen pop-ups del anuncio de turno,
seguro que te has encontrado mil páginas con un montón de
anuncios que te están flaseando la vista
cada vez que estás haciendo scroll.
Pues eso hace que nuestra atención se vaya a esos anuncios
y que realmente el contenido se esté perdiendo.
Entonces, la funcionalidad de la página de noticias,
que es enseñarte el titular y la noticia, se pierde con tanto
anuncio y tanta distracción. Y por último, el último
principio del diseño, inclusive,
sería añadir valor. ¿De qué trata esto?
Es un poco intentar ir más allá de las expectativas básicas
que pudiese tener tu funcionalidad y añadir cosas que mejoren la
experiencia de usuario. Por ejemplo, en una aplicación
de salud, si queremos hacer un seguimiento
de una aplicación que solo permita hacer el seguimiento de
tu actividad física o de tu dieta, pues está guay.
Pero si además le ofreces consejos de dieta, recordatorios
mensuales de tomarse sus medidas,
o una comunidad, acceso a una comunidad que le dé mensajes
de apoyo y tal, pues estás añadiendo cosas
que no son exclusivamente de tu producto,
pero que le añaden mucho valor y generan comunidad.
Todos estos principios lo que tienen en común no es solo
eliminar una barrera a una persona con discapacidad,
sino tienen en cuenta también tu situación en el momento.
Puedes también enfocarte en si esa persona proviene de una
cultura o tiene un conocimiento de una
cosa, etcétera, ¿no? Eso es un poquito el diseño
inclusivo. Y eso es lo que te quería
contar hoy. Ha sido un poco rápido, pero
intenso. El próximo día, si quieres,
podemos profundizar un poquito en las mejoras de accesibilidad
cognitiva, como hablamos. Lo de texto fácil y tal, a ver
si sacamos un tema interesante ahí.
De acuerdo. Pues hasta aquí la sección de
"Rompiendo barreras" con Eva Marco.
Y en la sección de 2024, una odisea,
en el ciberespacio contamos, como siempre, con David Marzal.
Hola, David. Buenas, Jorge y audiencia.
Estamos de verano. ¿Qué nos traes? ¿Boletín
veraniego? Sí, para cambiar un poco el
ritmo, como aquí hace mucho, mucho calor,
he dicho, voy a hacer una especie de magazine de varias
noticias sueltas, cortitas, que no sé si refrescan, pero
por lo menos es algo menos denso que una sección entera
hablando de inteligencia artificial.
Pues vamos allá, ¿con qué empezamos?
Pues mira, la primera, para no tener que cambiar
el título a la sección, va sobre inteligencia artificial
en modo local dentro de Mozilla, que es que Firefox está
desarrollando, estará en beta a partir de la
130, la generación local del alt text,
de las descripciones visuales, lo harán ellos con un modelo
propio que han entrenado para que sea
más pequeño y más certero y que no consuma un huevo
dentro de un navegador. Así me gusta, quitándome
trabajo. Maravilla. ¿Qué más? En principio,
lo que van a hacer es, van a empezar poco a poco, haciendo
iteraciones. Lo primero es que te va a sugerir
que tú le pongas dentro de los PDFs
que ellos tienen, cómo generar el texto y luego lo van a ir
ampliando a generar las imágenes de todo
y luego hacerlo estable, meterlo en Thunderbird.
Está bien, están ahí haciendo cosas en local y que
sean útiles. Sí, no sé si tienes por ahí
también que también estaban ampliando
el tema de las traducciones de texto.
Sí, también, también lo he visto, la han mejorado, han
hecho que se puedan traducir más trozos de la página que
antes no se podían y luego también dentro del paraguas
de Mozilla tengo otra noticia, que es que la funcionalidad de
captura de pantalla, eso que es como un cuadradito y
unas tijeras que tiene ahí arriba a la derecha,
yo la cual, por cierto, utilizo un montón, la han mejorado
también, han hecho que se puedan hacer
capturas de pantalla a más áreas porque a veces
si la página era especial, como las de configuraciones o
de PDF, no se podía. Ahora se pueden hacer más
fotos, se pueden exportar a otros
formatos y luego lo importante para lo que es este
podcast de accesibilidad es que le han puesto unos cuantos atajos
de teclado para que esto sea manejable sin
tener que usar el ratón. Muy bien, pues el navegador poniéndose
las pilas. Y ya salimos de Mozilla y entramos
a accesibilidad en general. Tengo que hay un nuevo protocolo,
una arquitectura nueva que se llama Newton,
que se supone que es la heredera de AT-SPI, que es lo que usan
prácticamente todos los Linux que tienen
accesibilidad, usan ese esquema, esa arquitectura
y luego las aplicaciones se conectan y consiguen leer las
cosas. Pues en Gnome están desarrollando
uno nuevo y la gracia que es ya directamente
nativo con Wayland, porque ahora mismo el problema que hay
es que Wayland es un infierno para quien quiera usar,
por ejemplo, Orca, el lector de pantalla.
Entonces han decidido hacer uno de nuevo,
ya directamente enfocado en que esta accesibilidad esté con
arquitectura moderna. David Marzal no parece él
hablando bien de Gnome y no mencionando a KDE.
Has visto, que sepas que las dos últimas noticias son de KDE,
las he dejado a las últimas, pero...
Al César lo que es del César. En Gnome en estas cosas son
muy punteras, seguramente porque tienen detrás el dinero
de Red Hat, que es el dinero de IBM y
entonces realmente no lo está haciendo como Gnome,
lo está haciendo un desarrollador de Gnome, pero es compatible y
enfocado a todas las distribuciones de Linux.
Aquí los desarrolladores no son de mi nicho y esto lo hago
para mí y mejorar la mía y que la tuya sea peor, sino
que lo están haciendo para intentar mejorar
el sistema en sí para todo el mundo.
Entonces está muy bien, está en desarrollo, está muy verde,
pero ya está en marcha. Bueno, pues todo lo que sea
mejor a la abuela, que falta le hace, bienvenido será.
Luego también en la familia de Gnome y Red Hat está Fedora
y he visto un post, un tute en Mastodon, que voy a dejar en
las notas del programa, en el que he visto que tienen
un vídeo de presentación y una sala de Matrix.
Se ve que Fedora tiene como una comunidad, un grupo especial,
especializado en accesibilidad. Entonces ahí han dejado un enlace
a una presentación en vídeo de qué hacen y de qué va
y su sala de Matrix, lo cual está muy bien porque si esto
no fuera accesibilidad con tecnologías libres,
sino que sería un podcast de Linux, te diría que se está
liando buena porque Gnome va a quitar X11
en sus próximas versiones y entonces va a hacerle un cristo
a toda la gente que usa Orca. Por lo cual yo creo que ese foro
va a estar calentito, o sea que si entendéis inglés
me metería para decir, oye, dejadnos la posibilidad de
arrancar. Es lo que tienen los cambios,
pero bueno, no será por anunciarlo con más de 10 años
que tenían de preaviso, o sea, me parece tiempo suficiente
para estar informados. Sí, sí, pero vamos, yo espero
que monten a tiempo algo que sea usable
antes de que corten el grifo de lo que está usando ahora mismo
la gente para poder saltarse el que Wayland
no va bien. Luego también dentro de Mastodon
he visto un par de... cuentas interesantes que son
dos podcasts, los dos están en inglés
y los dos van sobre accesibilidad. Uno se enfoca en reviews de
hardware y juegos y el otro se encarga de hablar
de tecnología, viajes y autocuidado. Entonces voy a dejar enlazados
las dos cuentas de Mastodon por si queréis buscar esos
podcasts. Me ha parecido interesante, yo
todavía no me lo he agregado porque la verdad es que tengo
como 48 horas pendientes en la cola de escuchar
pero tienen pinta de estar interesantes.
¿Y los títulos, los puedes decir?
Sí, mira, uno es, no se lo he currado mucho en el nombre, es
TFFP. Yo no he conseguido saber de
qué son las iniciales. Y el otro es más sencillo, es
Living Blindfully, viviendo de manera ciega o algo
así sería la traducción en español.
¿Qué más? Venga, ahora entramos en la
parte KDE. Que es, que en KDE han hecho un
artículo en el que te van detallando en
una serie de cuatro vídeos, hay Selenium, es una aplicación
de testeo, pero está enfocada a páginas
web, ¿no? Entonces han desarrollado algo
parecido y te explican cómo usarlo para
que tú cada vez que hagas un desarrollo
de una aplicación normal y corriente
la puedas testear en tiempo real
y sin tener que luego decirle a alguien
oye, mira a ver si funciona, o sea, ya la diseñas y la
programas haciendo testeo y la gracia de
esto es que este testeo está hecho en
accesibilidad. Todavía con el protocolo viejo
AT-SPI mismo es lo que hay, pero
hombre, me ha parecido interesante
por si conocéis a algún desarrollador que le paséis
este enlace porque es como deberían
desarrollarse todas las aplicaciones que es desde el inicio, desde
el minuto cero diseñado y probado con accesibilidad
y no luego, claro, ya luego cuando ya lo ha hecho
arreglarlo, cuesta. Eso lo comentamos un poquito en
el programa anterior con Eva que el diseño debería empezar
desde el principio. Y hablando de probar las cosas
una vez que están hechas pues he encontrado una aplicación
en la tienda o página de KDE
que se llama, no tiene, o sea, el nombre no se lo han
currado mucho, se llama Inspector de Accesibilidad
¿Y qué hace? Pues como su nombre sugiere
es un inspector del árbol de accesibilidad de las aplicaciones
te va haciendo así como que se van abriendo árboles
y vas viendo todos los elementos de tu aplicación
y te va dando todas sus propiedades en accesibilidad, si es visible,
el orden que tiene con el tabulador cómo lo puedes ejecutar con
una tecla de acceso rápido está bien. Y luego también te
permite comprobar todos los elementos expuestos
al AT-SPI que es lo que hemos dicho, que
es lo que usan otras aplicaciones de accesibilidad para poder
leer o poder saber decirle al usuario que hay en
pantalla o transformarlo a Braille. Entonces me han parecido
curiosas y por supuesto todo lo que he
dicho está en las notas del programa
que es donde está la gracia de poder pinchar directamente y
ver los artículos completos. ¿Alguna más? Pues
esta era todas porque no quería así
hacerlo muy gordo estoy preparando a hablar en el
siguiente sobre una aplicación que te
permite para humanos jugar con inteligencias
artificiales con modelos de lenguaje natural
grande sin tener que ser ollama, que es
lo que hablamos en otro episodio que era por línea de comando,
pues esto es una manera gráfica y sencilla. Ese será el
siguiente en modo veraniego veraniego. Muy bien, pues hasta
aquí la sección de 2024, no voy a decir nada,
del ciberespacio Un saludo, hasta luego. Y en la
sección de accesibilidad web como siempre contamos con Pablo
Arias. Hola Pablo Muy buenas Jorge, ¿qué tal,
cómo estás? Bien, creo que quieres hablarnos
de formularios web Efectivamente, quiero hablaros
de formularios web y es una parte
súper importante para lo que es la toma de datos
la parte con la que el usuario puede
ponerse en contacto con nosotros
e interactuar, enviarnos información
es algo que tenemos que tener en cuenta
y que debemos cuidar muy mucho, en cuanto a accesibilidad se
refiere también Una de las cosas que quiero
comentar es que además se está poniendo muy
de moda desde hace unos años para aquí
es el tema de no utilizar etiquetas en los campos. Es decir, que el
campo tenga dentro su texto
donde tienes que poner tu nombre, por ejemplo, o apellidos
y tiene el campo, ese texto escrito
dentro del propio campo y cuando pinchas sobre él
desaparece. Eso no es una etiqueta, eso es lo que en inglés se denomina
placeholder. Claro, si al pinchar sobre él desaparece
cuando estás rellenando un formulario y vas a medias
ya no sabes si pusiste correctamente el nombre
en el campo que correspondía o no
además de que el placeholder no se lee normalmente a los
lectores de pantalla y la etiqueta sí. Entonces es
importante que haya una etiqueta y que
se visualice en todo momento, que no desaparezca cuando el
campo recibe el foco. Entonces esa es
una parte importante. Seguro que lo tenéis
visto en más de una ocasión, ¿verdad
Jorge? Sí, normalmente los formularios suelen dar dolores
de cabeza, como tú bien sabrás. Sí, sí, efectivamente.
Entonces bueno, sí que es cierto que ahora hay evoluciones
que, por ejemplo, pinchas en el campo, la etiqueta se desplaza
hacia un lado. Estaba como dentro del formulario, dentro
del campo y se desplaza hacia un lado o
hacia arriba y sigue ahí presente. Eso
está bien. En principio es una etiqueta, no es un placeholder.
No es un placeholder a secas. Entonces es una buena práctica.
Pero lo habitual, que esté ahí siempre presente
con la etiqueta label de HTML. Otra cosa que también tenemos
que tener en cuenta en los formularios, lo que hablábamos
en el anterior episodio, el tema del teclado. Debe ser
navegable con teclado. Es decir, que cuando alguien
llegue al formulario y le dé al tabulador,
pues vaya pasando de campo en campo y que pueda
ir rellenando y dándole al tabulador
y vuelve a empezar. Rellenar, darle al tabulador.
Incluso campos un poco más complejos, que no sea sólo de
introducir texto, que sea de seleccionar opciones o que
sea de tipo radio o de casilla
de verificación, del típico checkbox,
que también se pueda rellenar con teclado. Que por defecto
los formularios son accesibles en HTML.
Lo único que a veces, añadiendo nuevas funcionalidades, nos cargamos
esa accesibilidad. Entonces, informar
correctamente también de qué campos son
obligatorios y cuáles no, al usuario.
Muchas veces ponemos un asterisco. Bueno, pues si
ese asterisco normalmente tiene que
llevar una leyenda diciendo pues los campos marcados con asterisco
son obligatorios. Esa es una opción. También
está la opción de si en un formulario hay muchos
campos que son obligatorios, decir los que no lo son.
Es decir, poner el nombre del campo en la etiqueta
y entre paréntesis decir pues este
no es obligatorio o simplemente no requerido
o similares. Otra cosa que los desarrolladores
web no nos acordamos en ocasiones es
el que los formularios se puedan dividir
en partes. Es decir, con la etiqueta Fielset
nosotros podemos dividir el formulario
por ejemplo, si vamos a hacer un
formulario en el que le pidamos datos de registro
al usuario, por ejemplo, datos de envío
para, estamos haciendo una compra, pues podemos dividir
ese formulario en dos partes. Entonces
la etiqueta Fielset nos permite ponerle,
digamos, agrupar esos campos y ponerle un título
a lo que es esa agrupación. Por ejemplo, como decía antes,
datos de registro para la parte donde le pides
el correo electrónico, la contraseña y demás y datos
de envío o dirección de envío o lo que sea para la parte
donde le pides la dirección, teléfono, etcétera. Entonces
así queda como más organizado. La etiqueta
Fielset sí que es cierto que necesita ese título para que
sea 100% accesible. Muy recomendado.
Pablo, no sé si lo vas a tocar más adelante, pero
muchas veces causa confusión cuando no queda
muy claro qué tipo de datos te están pidiendo o en qué formato
y, no sé, el típico número de carnet pero a lo mejor
que no te piden la letra y tú le metes la letra
y te da un fallo y a veces te dice
error 323 y dices tú, pues vale, ¿qué será?
Pues simplemente te aparece en rojo la parte esa del formulario
pero no sabes por qué motivo no funciona.
Sí, es muy cierto. De hecho, con respecto a la validación
iba a hablar ahora, pero sí que es cierto
que con las nuevas versiones de HTML es posible
definir tipos de campos, pues por
ejemplo, que sean numéricos o que sean un correo
electrónico o que sean bueno, pues eso ya nos ayuda
desde ciertos dispositivos. Por ejemplo, si
ponemos que un campo es de tipo texto, pero a mayores
le indicamos que es para introducir un correo
electrónico, ahí el teclado del móvil,
por ejemplo, se nos transforma poniendo la arroba
a mano. Aparte de eso, como bien dices, Jorge,
el tema de que indiquemos al usuario exactamente
lo que necesitamos, es decir, no sólo una etiqueta
label, donde le decimos qué tipo de
dato queremos, por ejemplo, nombre o DNI,
como decías, sino a mayores también una etiqueta
o sea, una descripción para saber
qué tenemos que poner en ese campo. Por ejemplo,
si te estoy pidiendo el NIF, pues aclarar debajo
del campo que diga, pues introduce
el número y la letra, por ejemplo.
Al final deben ser nueve caracteres, imagínate.
Entonces, eso ayuda mucho para que cuando
estás cubriendo el formulario puedas ir más
rápido o que no surjan esas dudas y que
incluso ahora entramos en la parte de validación, pues
no sea simplemente un borde rojo que te indique
que en ese campo hay algo incorrecto.
Porque el borde rojo, pues hay gente que no lo ve.
Entonces, es bueno que haya algo más.
Por ejemplo, un mensaje. Además del borde rojo,
puedes poner un mensaje, un breve texto, que también
puede estar en otro color para ayudar,
pero no puedes confiar en que el color sea
lo único que distinga. Entonces, poner un texto que
diga, pues el campo que has rellenado
no es correcto, pues porque le falta una cifra,
porque le falta la letra o porque
no parece una dirección de correo electrónico, lo que sea.
Entonces, indicarle bien cuál es el error.
Otro error que me he encontrado a veces,
que no sé, debe estar muy caro el kilo de bit, que a veces
en algún campo tienes un número máximo
de caracteres que puedes meter y te queda a medias un nombre
de estos compuestos muy largos o una dirección de una calle
que tenga un nombre muy complejo y como te han puesto
X caracteres, pues no te dejan meter más caracteres.
Sí, sí, sí, como bien dices, va caro el kilo de bit.
Entonces, pues es cierto que deberían indicar también
cuál es el límite de ese campo, si es un límite
pequeño. A mí incluso también me tiene
pasado algo muy parecido a lo que dices, que es que
estás rellenando un formulario, por ejemplo, de registro, vas a
poner una contraseña, sí que es cierto que dicen, no,
mínimo ocho caracteres o los que sean que te sugieren
y que tiene que haber un símbolo y no sé qué, no sé cuánto,
perfecto. Pero luego, si pones una
contraseña demasiado larga, ni te avisan y te la cortan.
Y punto. Entonces, tú tienes, piensas que has escrito
una contraseña, pues vamos a suponer, de veinte caracteres
y en realidad solo te cogió dieciséis, por poner un
ejemplo. En otras ocasiones, pues son
otros números, ¿no? Pero eso es
un problemón, porque tú luego vas a poner la contraseña
que la tenías, pues sabías que eran esos
veinte caracteres y resulta que solo cogió dieciséis,
entonces nunca aciertas la contraseña.
A que no sabes dónde me ha pasado eso.
Dime. No que me recortara la contraseña,
espero, sino que me ponía un número máximo de
caracteres que me pareciera una ridiculez hoy
en día. En algunos formularios de banco,
en algunas webs de algún banco, de ponerme un
máximo, pues no me acuerdo si era
seis o ocho, o sea, una ridiculez hoy en día por una contraseña.
Sí, sí, tal cual. Te están obligando a utilizar contraseñas
débiles, porque esos caracteres son insuficientes.
Insuficientes. Entonces, y ya que te lo
recorten sin decir nada, ya me ha pasado varias veces.
Simplemente, pues así, la contraseña que tú pensabas
que tenía no es porque le faltan cuatro
caracteres, entonces jamás vas a acertar a
introducirla bien. Entonces, bueno, tienes que volver a
empezar y como no te lo indican, pues
igual vuelves a caer en el mismo fallo.
Ahora que ya lo sé, pues dices, bueno,
incluso a veces puedes inspeccionar la web
con una herramienta, le das al F12, te salen las
herramientas para desarrolladores y ahí puedes ver el límite
de cuáles son los caracteres que te están poniendo como límite.
Entonces, bueno, es un despropósito que debemos
evitar. Otro problema que me he encontrado es
nuevamente cubres el formulario, sea más extenso o menos extenso,
y suele haber un botón para enviar los datos.
Pero, ¿qué pasa cuando no pasa nada en la pantalla? No
nos mandan un mensaje de los datos
han sido enviados, te quedas mirando como tonto la pantalla
diciendo, estará cargando, estará enviando
los datos, ya ha terminado, tengo que esperar, ¿qué pasó
aquí? Cierto, cierto. Tal cual, eso
es algo que debemos tener muy en cuenta, es
decir, un mensaje que le diga al usuario qué ha
sucedido, porque si no a lo mejor se queda ahí
esperando sin saber qué sucede. Entonces, pues es
muy importante el típico mensaje de agradecimiento
e incluso un correo electrónico si
procede diciéndole, oye, pues hemos recibido
tu compra o hemos recibido tu formulario de contacto, lo que
sea que, bueno, no siempre procede
este correo electrónico, pero sí que el usuario tenga claro
lo que pasa y a poder ser en pantalla, que ya salga
un mensaje aclaratorio, muchas veces incluso que
desaparezca el propio formulario y que aparezca ese mensaje.
Ahí ya no cabe duda de que el formulario se ha procesado y se
ha enviado y si ha dado un error, pues te aparecerá de
nuevo el formulario, pero con la validación diciéndote,
pues mira, este campo es obligatorio o este campo no está bien cubierto,
lo que sea, lo que sea que haya que corregir, lo que
hablábamos antes de las validaciones. Sí, y hablando también con
temas de accesibilidad, también debe ir
caro los caracteres grandes, porque no
sé por qué, pero en muchas maquinitas, en la web
a lo mejor no tanto, aunque en algunas sí, pero en muchas
maquinitas, que realmente es un formulario
lo que tienes que cubrir para meter información, a veces
tienen la costumbre en ciertas zonas o apartados o
en esas etiquetas a veces que hablabas tú antes,
o descripciones, de poner un tamaño de texto
más pequeño que el resto de la pantalla,
con lo cual para gente con problemas
de visión también le va a costar leer esa información.
Sí, efectivamente, el tamaño de la fuente en los formularios
tiene que ser acorde con el resto de la web,
no más pequeño ni más complicado.
Incluso tener cuidado también con el tipo de fuente,
porque a veces hay fuentes que los números, por ejemplo, se
confunden mucho. El 6 y el 8 son muy parecidos, todo
ese tipo de cosas, pues también hay que tener
cuidado. Incluso hay estas fuentes que
tienen los números que se muestran unos más
arriba que otros, eso también puede ser un poco confuso
a la hora de escribir. Y bueno, pues tenemos
que facilitar al máximo la entrada de datos en nuestro
formulario. De hecho, una de las cosas que iba a comentar
ahora es ayudar también con el atributo
"autocomplete", es decir, procurar que si
esa persona ya ha escrito, por ejemplo, su correo electrónico
en otra web, que el navegador le
sugiera ese dato para cubrir tu formulario, también es
útil, porque así no tiene que escribirlo de nuevo y
podemos evitar que cometa errores, porque ya
lo escribió en otra web y lo ha escrito bien. Entonces,
pues es una buena cosa que le permitamos
que se autocompleten los campos. Sí que es cierto que en
algunos casos, por temas de seguridad,
pues hay webs que lo limitan esto. Bueno, vale,
ahí ya no me meto, habrá excepciones, pero por defecto
permitamos que sí, que se autocubran
y bueno, sí que es cierto que yo no me fío
mucho de algunos navegadores, porque
esto sucede, por lo menos creo recordar,
que en Chrome o similares, que tú escribes,
empiezas a rellenar un formulario, escribes tu nombre
y te sugiere ya rellenar el resto de los campos
con todos los datos, pues yo qué sé, tu correo electrónico,
tu dirección, tal. Entonces, pasa en ocasiones
que el formulario, pues vamos a suponer que no te
esté pidiendo el teléfono, sin embargo, el desarrollador
web, con cierta picardía, podría ponerte un campo oculto,
que sea el teléfono, que sean otros datos que tú no
rellenarías en esa web, pero que Chrome te los cubra
sin que tú te des cuenta. Entonces, mucho cuidado con esa
forma de rellenar. Recuerda esa funcionalidad: cubre
solo los datos y de uno en uno. Solo los datos
que quieras y de uno en uno. Procura no rellenar el formulario
completo a golpe de clic, porque te la
pueden jugar de esta forma. Hay otro asunto
con respecto a los formularios que debemos también tener
cuidado, que es el tema de la confirmación
para tareas importantes o irreversibles.
Es decir, si tú estás decidiendo eliminar
algo, pues que te ponga un botón "eliminar"
y que automáticamente inmediatamente se elimine, pues
puede ser peligroso si no se puede deshacer esa acción.
Entonces, tener un mensaje que confirme:
¿estás seguro de que quieres eliminar este
elemento? Sí. Entonces, pues para las tareas
irreversibles o importantes, una confirmación.
Sí, incluso en algunos, esa confirmación no es solo
pulsar un botón, sino que es a lo mejor meter tu correo electrónico
o el nombre de lo que quieres eliminar para tener una mayor
seguridad de lo que vas a hacer. Exacto, eso lo estamos viendo
últimamente en muchos casos. Entonces, pues interesante que
haya esa confirmación para no perder
datos relevantes o para no realizar
una acción que no querías. Por ejemplo,
me pasa en alguna ocasión, pues
sin dar nombres, pero en la aplicación del banco vas a enviar
un Bizum, pones el nombre, la
cantidad y antes de... O sea, tú le das a enviar y ¡pum!,
ya pagaste. Estaría bien que hubiese una pantalla
simplemente que te enseñe: "Oye, vas a enviar este
dinero a esta persona". ¿Es correcto? Sí, aceptar. Vale,
pues ya está. Una simple confirmación, ¿no?
Porque, pues eso no es reversible y es algo importante.
Entonces, bueno, pues considero interesante que
haya una validación para ese tipo de acciones.
Y luego, por último, que tengo aquí en mi chuleta,
pues implementar un sistema para deshacer,
si es que es posible. Por ejemplo, esto del Bizum, pues
no es posible. Vale, pues está hecho, hecho
está. Pero si hay una posibilidad de que cuando
elimines algo, pues se vaya una papelera y en caso de,
bueno, de que quieras recuperar ese contenido
puedas hacerlo, pues está genial. Entonces, ya nos
podremos a lo mejor podremos obviar esa
confirmación que decíamos antes. ¿Por qué?
Porque se puede deshacer la acción. Por lo tanto,
no es tan crítico y a lo mejor no necesitamos
tanta confirmación. Entonces, esto es un poco
los, bueno, los consejos que quería dar para
los que hacemos webs y tenemos que implementar
formularios y que sean accesibles. No sé si quieres comentarte
algo más, Jorge. No, yo creo que
has tocado todo lo relativo a formularios.
Entonces, voy a cerrar ya la sección, si no tienes nada
más. Y hasta aquí la sección de
accesibilidad web con Pablo Arias. Y en la sección
de diseño para todos con Jonathan Chacon, hoy vamos
a hablar de Smart Cities y ayudas a la orientación en
las ciudades. Hola, Jonathan. Buenas, Jorge. Buenas a todos.
Pues hoy vamos a hablar de un tema
bastante metafísico. Que es los beneficios de ir creando
poquito a poco Smart Cities, pero irlas creando
de forma socialmente responsable, con tecnologías abiertas y los
beneficios que nos traen a todos. Pero Jonathan, las que
llamaban Smart Cities hasta ahora, ¿algunas
realmente es Smart? En realidad, ahora se están volviendo Smart
porque el primer paso era esta etapa de ir recolectando
información sobre qué pasa en la ciudad.
Y ese era el gran problema. Querer crear una
Smart City sin saber qué sucedía en la Smart
City. Entonces no podía ser Smart. Mira que han
soltado pasta desde Europa y otros sitios para proyectos
de este tipo y al final... Ahí hay un tema
de empresas privadas que levantaban la manita de
"dame pasta que yo hago un proyecto de innovación".
Que lo llaman así, innovación. Empleando tecnologías que ya
llevan 20, 30 años. Pero bueno, era innovar. El
problema era qué empresa privada va a poder
abarcar la posibilidad de incorporar
sensores en todas las farolas y semáforos de una
ciudad. Ahí debía haber una implicación de la
administración de cada ciudad y de cada estado o autonomía
para coordinarse. Tú no puedes ir modificando
de forma privada los semáforos y el
mobiliario urbano de una ciudad. Entonces
ha habido mucha inversión que se ha perdido.
Por suerte para nosotros ha habido también mucha
inversión que ha servido para crear la base tecnológica
de la sensórica y la gestión de información
que hay ahora en ciudades como puede ser Barcelona,
Sevilla, Valencia, Londres, Nueva York, París.
Y eso ha permitido que ahora empiecen a aparecer
poquito a poco los nuevos servicios de orientación
y asistencia a personas con y sin discapacidad.
Te comento cuál es la filosofía a la hora de ayudar
a las personas en una Smart City. Hay tres enfoques muy
claros. La primera es la gestión de
los sensores a la ciudad, bien sea para gestionar el tráfico
o para obtener información de cuántos peatones hay e
incluso de qué peatón hay en una calle
y en qué posición. Eso implica un problema de gestión porque
esa sensórica puede ser saturada, ocultada
u obstruida, bien por motivos físicos,
por motivos digitales o por motivos legales.
Y Jonathan, ¿ahí metemos las cámaras
que están poniendo los semáforos o no?
Sí, sí, sí, se han considerado dentro del plan de inversión
de Smart City Europeo, o sea, se contemplan como Smart Cities.
Ahora te digo que no sólo eso es suficiente
para decir que una ciudad es Smart City,
por llenarla de sensores no es suficiente.
La Smart City necesita de los dos otros enfoques también,
que el segundo enfoque es llenar de sensores y de receptores
de información al peatón o vehículo que se mueve por la
ciudad. Normalmente llevamos un ordenador
de abordo con muchos sensores, que es un teléfono móvil o
smartphone, pero también para algunas necesidades
especiales, pues hay hardware específico
que permite a personas con discapacidad visual
o con sordera o incluso personas con movilidad reducida
obtener información de esa Smart City,
de ese conjunto de sensores que están repartidos por toda
la ciudad y obtener información para un fin.
Y ahora ahí tenemos que ver el tercer enfoque,
el enfoque en la nube y el enfoque de comunicación bidireccional.
La ciudad ofrece información en un clúster o un gran servidor,
pero toda esa información sin un orden y sin un objetivo
totalmente inútil. ¿A mí para qué me interesa
saber el estado de abierto o cerrado
de los semáforos de toda la ciudad?
A mí sólo me interesa saber si el semáforo,
yo como persona ciega, el que tengo más cercano está en
verde o está en rojo, el que está para mí, para peatón,
si estoy en ese momento con peatón. Entonces hacía falta el tercer
enfoque, que es el contexto del ciudadano.
Ciudadano va caminando con un objetivo, entonces hace falta,
y aquí se está utilizando mucho inteligencia artificial,
un tema de definición de contexto y definición de soluciones
para los objetivos del ciudadano. Esto es muy bonito, Jorge. Yo
aquí te estoy vendiendo la publicidad,
y se están haciendo cosas chulísimas con mucho dinero Europeo
y mucho dinero ayuda a países en vía de desarrollo o de
desarrollo temprano, como en Latinoamérica. Por
ejemplo, se están haciendo inversiones
para digitalizar el mapa de una ciudad completa, como puede ser
Valencia, puede ser Londres, puede ser
Sevilla, o de monumentos y edificios importantes
de ciudades como Roma, París, y dices tú, bueno, ¿y eso
para qué vale? Para que luego el ayuntamiento
pueda venderlo a estudios de desarrollo de videojuegos,
para hacer un Call of Duty en plan realista en la ciudad de
Londres, pues también para ofrecer
experiencias de turismo digital en remoto,
pero también gracias a todo el tema de posicionamiento GPS
y posicionamiento indoor, si tú tienes un mapa muy preciso
de cómo es la ciudad, puedes crear un Matcher, un algoritmo
que rectifique la posición de tu usuario, no sólo utilizando
el posicionamiento de acelerómetro y GPS,
que, quieras o no, con el tiempo de uso, en cinco o seis
minutos, va acumulando una deriva. Pues con esa información
visual y ese mapa digital puedes rectificarle,
o no, no, está cinco metros más atrás, que tan rápido no
se mueve el peatón. ¿Qué pasa con todo esto? Que
tenemos mucha tecnología y ahora, poquito a poco,
nos estamos empezando a coordinar, tanto la empresa privada como
la Administración, como las universidades.
Y ahora empiezan, muy poquito a poco, Jorge, ya que hemos gastado
casi un tercio o casi tercio y medio del
presupuesto que se había destinado para Smart Cities en
Europa, ahora se empiezan a conseguir a
tener una base de Smart Cities. Hay esperanzas, pero sí es
cierto que se han dado muchos palos de ciego
antes de entender que la Smart City requiere mucho enfoque en
donde los ciudadanos estén implicados, la Administración
esté implicada, las empresas privadas estén implicadas
y que toda esa información fluya. ¿Esto qué permite? Que, por
ejemplo, aplicaciones como Lazarillo o Sendero GPS,
que son aplicaciones específicas para personas ciegas, ahora,
cuando hacen una consulta de una ciudad,
adquieren mucha más información del contexto del
usuario en una localización concreta de la ciudad.
Entonces, la asistencia a una persona ciega es mucho más
efectiva. También que se consigue que la
posibilidad futura de un coche autónomo
o de nivel 4 de autonomía sea cada vez más real.
En Europa el gran freno del coche autónomo es que no garantizan
que sea seguro su conducción de forma autónoma
porque sí es cierto que el trazado de las vías en Europa
no es tan rectilíneo y tan predecible
como en países más modernos como Estados Unidos o muchas
ciudades de Latinoamérica. Esto es un gran atraso ahí y
poquito a poco se va a intentar aportar esa solución
dando más precisión de cómo están construidas las ciudades.
Hay un chiste muy divertido dentro de la conducción autónoma
que es si tú pones a un Tesla con su
autopilot a circular por España,
en cuanto entre en una rotonda, no va a saber salir.
Porque es un problema de decisión, de ser arriesgado para salir.
Porque no es nada segura. Es un problema de la inteligencia
artificial que siempre intenta reducir al mínimo los riesgos
y en ciertas ciudades de Europa conducir es un riesgo.
Entonces ahí tenemos una posible solución aportando
más información. Y digamos que los conductores
que rodean a ese coche tampoco se lo permiten.
Ahí no voy a entrar porque entramos fuera de la
tecnología que es la percepción de bondad
y maldad humana cuando nos ponemos delante del volante de un coche.
Porque hay gente que siendo una persona entrecomunicada
"equilibrada" socialmente, se transforman cuando se montan
dentro de un coche. Y es muy curioso ese cambio de
actitud. Entonces es un tema de implicar
a todos los actores que rodean a una ciudad.
Ciudadanos, administradores, empresarios, tecnólogos...
Para que esa información fluya de la forma más óptima recogiéndose
por parte de la sensórica de la ciudad, pero incluso de la
sensórica de los propios peatones.
Y es uno de los cambios que está pasando desde el 2021
para acá. Que las propias aplicaciones,
los propios teléfonos van aportando información
a ese nodo de información de una ciudad.
Los sensores de un teléfono o de un hardware específico para
asistencia a personas con discapacidad o
de un propio vehículo pueden ayudar a notificar
de un bache, de un problema, de una rotura en la ciudad.
Hay una aplicación muy divertida que
instalada en el smartphone de un conductor, por ejemplo un
taxista o conductor de VTC, puede
detectar con el acelerómetro del giroscopio
del propio teléfono, si está pasando por encima de un bache.
Teniendo una posición más o menos aceptada de entre 5 y 30
metros, esa información se puede notificar
a la página web de la ciudad de:
"Oye, aquí hay un bache". Y eso ya se está utilizando en
muchas ciudades. Lo que comentabas antes del azarillo
y las otras, ¿ya empiezan a implementar
también orientación interior de algunos edificios?
Senderos GPS dentro de la suya sí.
También hay una versión japonesa, que no te voy a decir el nombre
porque mi pronunciación de japonés es horrorosa, pero es el
equivalente. Y sí, se están comunicando
constantemente para ir actualizando los mapas
de edificios de interior y, por ejemplo, hay otros servicios
que aunque parezcan más rudimentarios, son muy
eficaces. No sé si conoces los códigos
QR. Un código QR más evolucionado
es lo que oferta NaviLens, que es una iniciativa privada
que cuenta con el apoyo de muchos ayuntamientos
y de gobierno, en la que abogan por utilizar el código NaviLens,
que es un QR sobrealimentado. Porque se puede leer en casi
cualquier posición con casi 170 grados de luz.
O sea, casi plano, a tu perspectiva.
Y se utiliza mucho, por ejemplo, si habéis pasado por Madrid o
por Barcelona, en la estación de Atocha de
Renfe de Madrid, en muchas paradas de autobuses de Barcelona,
en algunos hoteles... En Valencia también lo tienen,
en el metro y en algunos otros puntos.
Sí, sí, pues lo que se está intentando hacer es no solo
utilizar un mecanismo de orientación, bien un código NaviLens, bien
un código de orientación, bien un código de consulta de
posicionamiento indoor, bien GPS,
sino intentar que los servicios se comuniquen entre ellos para:
"Oye, según NaviLens estoy aquí. Según sendero estoy
aquí. Según la ciudad estoy aquí".
Pues con todo eso, que el teléfono y el poquito de inteligencia
artificial, que ahora estamos de moda, pues
diga: "Pues hago una media y más o menos estoy aquí".
¿Quién me da la mejor información?
Pues a lo mejor me da la aplicación de NaviLens para decirme que
tengo que ir a la escalera que está en el fondo
de la tercera planta para ir a la sección de ropa para señores.
Es una búsqueda porque se ha demostrado que un servicio
individual no está siendo suficiente
para reconocer el contexto y satisfacer las necesidades.
Sí, sería triangular con diferentes fuentes de
información. Y estamos en eso. Parece que
después de la saturación de la pandemia,
que todo lo tecnológico parece que se bloqueó, ya vamos acelerando.
Y la inteligencia artificial ya está pasando un poquito de moda
y está empezando a ocupar el sitio que se merece,
que es una herramienta más, muy eficaz, pero que
simplemente tiene que ayudar a que evolucionen
los proyectos que ya están ejecutándose o que se van a ejecutar.
Lo importante tienen que ser las personas y si una Smart
City quiere ser una Smart City, tienen que tener personas satisfechas
que se puedan mover con tranquilidad y seguridad.
Bueno, pues hasta aquí la sección de diseño para todos con
Jonathan Chacón. Un placer, saludos.
- Créditos de la música:
- "Evening" de Kevin MacLeod (incompetech.com) - Licensed under CC: By Attribution 4.0
Este podcast tiene licencia Reconocimiento-CompartirIgual 4.0 Internacional (CC BY-SA 4.0).