Magazine veraniego de noticias sobre accesibilidad

        
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.