Accesibilidad Web: Formularios (2)

 

Accesibilidad Web: Formularios (1)

 

Consejos para formularios accesibles

En Accessible Forms: Tips and Techniques se proporcionan  buenas prácticas (consejos) interesantes para crear formularios accesibles:

Los formularios son fundamentales en la experiencia web (por ejemplo, para registros o compras), pero muchas veces presentan barreras para personas con discapacidad. Asegurar su accesibilidad es clave no solo para cumplir con normativas, sino también para garantizar una experiencia inclusiva.

1. Usa elementos semánticos de HTML

Utiliza etiquetas como <form>, <label>, <input>, <textarea> y <select> en lugar de <div> o <span>.

Relaciona cada <label> con su campo usando el atributo for.

2. Etiquetado e instrucciones claras

Todos los campos deben tener una etiqueta visible.

No sustituyas etiquetas con texto de marcador (placeholder), ya que este desaparece al escribir.

Proporciona instrucciones claras y mensajes de error descriptivos cerca del campo correspondiente.

3. Accesibilidad con teclado

Asegúrate de que el formulario pueda recorrerse con la tecla Tab en orden lógico.

Evita bloquear el enfoque (focus) en componentes personalizados.

Los botones deben ser operables con Enter o barra espaciadora.

4. Validación y retroalimentación clara

Usa atributos ARIA como aria-live y aria-describedby para comunicar errores o validaciones a los lectores de pantalla.

Realiza validaciones en tiempo real y mueve el foco al primer error detectado.

5. Agrupa campos relacionados

Usa <fieldset> y <legend> para agrupar controles relacionados (como botones de opción), lo cual mejora la comprensión para usuarios con lector de pantalla.

6. Mensajes de error accesibles

No uses solo el color para indicar errores; combina colores con mensajes textuales.

Asegura que los errores se lean en voz alta mediante ARIA y expliquen qué ocurrió y cómo solucionarlo.

7. Diseño para pantallas táctiles

Los botones deben ser lo suficientemente grandes (mínimo 44×44 px).

Asegura buena legibilidad de etiquetas en pantallas pequeñas.

Evita interacciones basadas en "hover", que no funcionan en dispositivos táctiles.

8. Prueba tus formularios

Evalúa con lectores de pantalla (NVDA, JAWS, VoiceOver).

Navega solo con el teclado.

Usa herramientas automáticas como Axe o WAVE, aunque no detectan todos los problemas.

Texto accesible para etiquetar los controles de los formularios

 En Accessible Text Labels For All se explica un problema importante que puede aparecer con el texto que se emplea en la etiqueta label para etiquetar los controles de un formulario.

El problema aparece cuando se emplea un texto oculto para añadir información significativa, para que la etiqueta de cada control sea única. Ese texto oculto puede ser un problema para los usuarios que controlen el ordenador con la voz:

Inserting visually hidden text in the middle of a visible string of text on a button like that prevents users browsing and navigating using voice commands from interacting with the button.

A popular example of Voice recognition software used to browse the Web is Dragon Naturally Speaking. It is software that allows you to use your computer and browse the web using voice commands. It comes with a full usage manual that details how to use it to perform different tasks on your computer and on the Web. Such software is useful for a lot of people, including but not limited to people with disabilities who can’t use their hands, for example, or power users who want to get things done faster (because voice dictation is faster than typing).

[...]

When the dragon user (in the video) wants to select a form control, he speaks out the visual text label of that control. This is one of many reasons why visual labels are important in user interfaces.

Accesibilidad Web: Formularios (1)

El atributo placeholder no es una etiqueta, no sustituye a label

En Placeholder Attribute Is Not A Label!:

Just so we’re all clear on this, the HTML5 placeholder attribute in a text input is not a replacement for the label element. Period. The placeholder should only be used as a brief example of the text to be entered. 

Besides inconsistent support for screen readers, using a placeholder as an input label can create usability problems and issues for those with cognitive impairments. For example, how does one review the information entered if the placeholder is now gone? 

The placeholder should be used like a title attribute (tooltip); it provides only supplementary information. If the information is required for the user (such as a strict text format) then this should be conveyed in the main content of the page, not in an attribute.

Los placeholders causan problemas

El uso de los placeholders causa muchos problemas, no solo de accesibilidad, también de usabilidad. En Placeholders are problematic, se explican muchos de los problemas:

Since the placeholder attribute came along, lots of us started using it as way to show form field hints. Their appeal lies in their minimal aesthetic and that they save space. 

Some go a step further replacing labels with placeholders. Either way, placeholders are an inclusive design anti-pattern.

Propósito de año nuevo: NO USES PLACEHOLDER

En este año nuevo, por favor, no uses el atributo placeholder. O si lo usas, úsalo correctamente.

Ya he escrito sobre placeholder varias veces, por ejemplo, Cómo joder a la gente con el placeholder. Sí, cuando usas placeholder, normalmente lo usas mal y le estás jodiendo la vida a un montón de personas.

¿No me crees? Lee Don’t Use The Placeholder Attribute:

The placeholder attribute contains a surprising amount of issues that prevent it from delivering on what it promises. Let’s clarify why you need to stop using it.

La importancia de usar etiquetas (labels) en los formularios

El artículo Labels Required explica por qué es importante identificar los controles de los formularios:

Using the label element checks all of the boxes for inclusivity when properly formatted: it's directly associated with a form element (either with the for attribute or by nesting the element inside the label), displayed as text by standard browsers, and spoken by screen readers. Clicking or tapping on a label will focus the associated element (or select the checkbox or radio option), and when you focus directly on the element, screen readers will read the label. Ensuring that both visual and auditory cues are present and intelligible are critical when you consider that in WebAIM's annual screen reader study screen reader users report relying on a mix of both, with the majority using audio exclusively.

Hay otras alternativas a label, pero en este artículo se explica que no siempre funcionan:

It's possible to use markup other than label, but when you do, users may see or hear blank form elements and have no idea what to enter. 

At first glance, placeholder does a very similar job to label: it's displayed as text (within text inputs, specifically) and read aloud by screen readers. The placeholder has a purpose, though, that diverges from that of a label. It's meant to be a suggestion, formatting guideline, or hint that is ultimately replaced by user input. So while a placeholder may seem like a worthy label alternate on the first pass through a form, once a data value is entered, that label is gone. And that's just one of several reasons why placeholder is an inadequate substitute label. It's much more valuable when used as a guide. 

The aria-label attribute provides label text to screen readers for identifying interactive elements, or elements with ARIA roles, and it produces the same audio feedback as the label element. There's no reason to use both on the same form field, and we actually recommend against trying.

La conclusión es clara:

Out of the box, the label element is all we need to indentify fields in an accessible way. Used in combination with accessible hiding and other helper elements, like placeholder or icons, we can ensure that a form element's purpose is clearly communicated to all users.

Formularios de búsqueda no accesibles

En Unlabelled search fields se explica cómo etiquetar correctamente un formulario de búsqueda para que sea accesible.

La típica implementación como la siguiente está mal:

<input type="search" placeholder="…">
<button type="submit">
Search
</button>

Algunas alternativas son:

<input aria-labelledby="searchtext" type="search" placeholder="…">
<button type="submit" id="searchtext">
Search
</button>

O también:

<input type="text" name="search" aria-label="Search">
<button type="submit">Search</button>

En el artículo también se repasan las implementaciones de BBC, Medium, Google, Twitter y otros sitios web populares.

Cómo joder a la gente con el placeholder

En Don’t Use The Placeholder Attribute el resumen es claro y rotundo:

The placeholder attribute contains a surprising amount of issues that prevent it from delivering on what it promises. Let’s clarify why you need to stop using it.

Pues eso, DEJA DE USAR EL PLACEHOLDER, DEJA DE JODER A LA GENTE, o mejor dicho, DEJA DE USARLO MAL.

Esto ya lo he comentado varias veces en este blog:

• Ejemplo de que usar el placeholder es una mala idea
• Diez razones por las que los placeholders son problemáticos

Y aquí, unos ejemplos que aparecen en el artículo Don’t Use The Placeholder Attribute:

* El formulario de registro de Facebook con un abuso de del uso de placeholder:

* Tienes que introducir tu fecha de nacimiento, pero ¿el formato era MM/DD/YY, MM/DD/YYYY, DD/MM/YY o DD/MM/YYYY? ¿No te acuerdas? Pues te jodes, así de sencillo:

* Tiene que introducir una contraseña que debe cumplir una serie de requisitos. ¿Empiezas a escribir la contraseña y no te acuerdas de los requisitos? Pues ya sabes, te jodes una vez más:

 * ¿No sabes dónde puedes encontrar el código YAMA? Pues te rejodes:

Accesibilidad Web: Formularios (1)

Uso de los elementos fieldset y legend

Los formularios suelen plantear muchos problemas de accesibilidad web. Por ello es muy importante conocer todos los elementos de HTML que se pueden emplear en los formularios para mejorar su accesibilidad.

El artículo Using the fieldset and legend elements explica el uso correcto. La explicación se resumen en estos consejos:

When to use a fieldset and legend
You should use the <fieldset> and <legend> elements when:

• You have a single multiple choice question (using radio buttons or checkboxes).
• You have several questions relating to the same topic (like text boxes, or any other type of field).

When not to use a fieldset and legend
You should not use the <fieldset> and <legend> when:

• You have a single form field that asks for a single piece of information.

Diez razones por las que los placeholders son problemáticos

El artículo 10 reasons why placeholders are problematic explica situaciones problemáticas al usar el atributo placeholder en un control de un formulario. Estas situaciones pueden afectar de forma negativa a la usabilidad y accesibilidad de una página web:

1. Disappearing placeholder text is easy to forget
2. Not all browsers support placeholders
3. Pre-populated values are hard to understand
4. Reviewing a long form is difficult
5. Erroneous fields are harder to fix
6. Some browsers will remove placeholder text on focus
7. Placeholder text may be mistaken for a value
8. They have insufficient contrast
9. Screen readers may not announce them
10. A missing label reduces the size of the hit area

Ejemplo de que usar el placeholder es una mala idea

El siguiente formulario se encuentra en Mejor con lentillas:

El aviso "* Campos obligatorios" al final del formulario en vez de al principio no es muy adecuado, pero ese no es el problema más grave de este formulario.

Para indicar el contenido de cada campo del formulario se emplea el atributo placeholder en vez de una etiqueta con :

Lo podemos comprobar viendo el código fuente:

¿Por qué es una mala idea usar el placeholder? Imaginemos que me equivoco y en el campo para el teléfono escribo el DNI y en el campo para el DNI escribo el teléfono. El resultado será el siguiente:

¿Qué está pasando? ¿Cuál es mi error? Si no me he fijado bien al rellenar el formulario, no recordaré qué debo introducir en cada campo. Para saberlo deberé ¡¡borrar lo he escrito!!

Además, desde un punto de vista de la accesibilidad web, algunos lectores de pantalla no reconocen el atributo placeholder, así que los usuarios que dependen de su uso para poder navegar por la Web no podrán rellenar este formulario de forma autónoma.

Formularios accesibles para las personas sordas

Los problemas de accesibilidad relacionados con las personas con problemas de audición son un poco desconocidos porque no son obvios.

Que una persona ciega tenga problemas con una página web es algo que todo el mundo entiende. Es más, está tan asumido que lo que realmente ocurre es que a mucha gente le sorprende que una persona ciega pueda usar una página web.

Con una persona sorda ocurre lo contrario. Normalmente en las páginas web el sonido no es importante, más bien es todo lo contrario, es molesto. Además de los problemas que pueda tener con un vídeo que no esté subtitulado, ¿qué otros problemas puede tener? Seguramente la mayoría de la gente dirá que ninguno. Sin embargo, hay un problema básico importante.

Las personas con problemas de audición, principalmente las personas sordas de nacimiento, tienen dificultades para comprender los textos escritos (Problemas del colectivo de personas sordas o con discapacidad auditiva). Para reducir este problema, se suele aconsejar simplificar los textos.

Pero las personas con problemas de audición tienen otro problema obvio que se suele olvidar: no pueden contestar al teléfono. Este problema lo explican muy bien en el artículo Accessible Forms for Deaf People?

En realidad, las personas sordas sí que utilizan el teléfono, pero con un producto de apoyo. Pero claro, si quien le llama no lo sabe, habrá un problema.

En el artículo se explica que en los formularios comerciales, cuando se solicitan los datos de un cliente, normalmente se solicita su teléfono o incluso suele ser un campo obligatorio.

Pero, ¿qué pasa si el cliente prefiere que no le llamen y prefiere otros métodos de comunicación?

Normalmente los formularios de contacto no suelen ofrecer esa posibilidad, no suelen permitir que el cliente indique que, por ejemplo, prefiere que le escriban un correo electrónico.

Es algo obvio y sencillo... pero no se suele hacer.

Formularios más fáciles

Un consejo rápido, que estamos en fiestas...

Los formularios son uno de los elementos de una página web que más problemas de usabilidad y accesibilidad originan. Una cosa es navegar, pulsar en un enlace para pasar de una página a otra, y algo muy distinto es rellenar un formulario en el que se pide información con cierto formato.

Una de las claves para que un formulario sea usable y accesible es reducir los errores. Para ello, una forma es limitar la forma de introducir los datos. Por ejemplo, en vez de introducir el nombre de un país, es mucho mejor elegirlo de una lista.

Sin embargo, a veces no se puede elegir el valor de una lista. Por ejemplo, si se solicita un teléfono, no hay más remedio que utilizar un cuadro de texto o cuadro de texto libre.

Pero, ¿en qué formato se solicita el teléfono? Por ejemplo, y si nos limitamos a la forma de escribir los números de teléfono en España, es muy normal ver lo siguiente:

999123123
999 123123
999 123 123
999.123.123

Y algunas formas más raras. ¿Es bueno aplicar un filtro para obligar a que todos los usuarios escriban los números de teléfono con el mismo formato?

Pues no. Lo mejor es filtrar la entrada del usuario, eliminar todo aquello que no sea un dígito, para quedarnos únicamente con aquello que sea realmente parte de un número de teléfono.

¿No es mejor que los ordenadores trabajen por nosotros?

Teléfono de contacto en un formulario web

Los formularios son el principal mecanismo de interacción y de obtención de información en las aplicaciones web. La creación de formularios accesibles es un tema bastante complejo (por ejemplo, leed e intentad aplicar todo lo que se explica en este artículo Formularios accesibles según las WCAG 2.0).

Sin embargo, dejando de lado todas las cuestiones técnicas que nos marca WCAG 2.0, a veces hay errores evidentes que se cometen por falta de "sentido común" o por desconocimiento.

Por ejemplo, Sergio López Lozano, un lector de este blog, me manda su artículo Webs, formularios y documentos accesibles, en el que explica el error que supone exigir en un formulario web el teléfono (móvil) como un dato obligatorio. ¿Qué pasa si tengo problemas auditivos y no empleo la función de voz del teléfono, sino que únicamente lo utilizo para enviar texto?

Por ejemplo, el formulario de la compañía aérea EasyJet exige introducir un teléfono móvil por si se quieren poner en contacto contigo:

Lo mismo ocurre con el formulario de otra compañía aérea, Ryanair:

En estos dos ejemplos, si no se introduce un teléfono, es imposible completar el proceso de compra de un billete de avión. Y lo mismo ocurre en la mayoría de los formularios web hoy en día.

Sergio López propone en su artículo añadir una casilla para indicar que se posee una discapacidad auditiva y que, por tanto, se desea que la comunicación sea vía correo electrónico o mensaje de texto al teléfono móvil. Pero solicitar este dato quizás complique el mantenimiento de los ficheros de datos e infrinja alguna de las normas de la Ley Orgánica de Protección de Datos de Carácter Personal.

JavaScript no molesto (5): validación de formularios

En la entrada JavaScript no molesto (4): separación del JavaScript se explicó cómo aprovechar el atributo class para separar el código JavaScript del código XHTML. En esta entrada se va a explicar cómo utilizar la misma técnica para validar formularios.

Los formularios se deben validar en el navegador por varias razones, las más importantes son:

• Disminuye el tiempo de respuesta de la aplicación: el usuario no tiene que esperar a que se envíen los datos al servidor, se validen en el servidor y se reciba una respuesta para saber si los datos están bien o están mal.
• Se reduce la carga de trabajo del servidor (no del todo, como ahora se explicará): en el servidor no se tienen que validar los formularios de todos los usuarios, en el navegador de cada usuario se validan los datos que ha introducido.

La segunda razón no es verdad en parte, porque SIEMPRE hay que validar los datos que se reciben en el servidor, ya que un usuario malicioso los puede enviar directamente, sin pasar antes por la validación de nuestro formulario. Por tanto, la solución que vamos a ver para separar el JavaScript del XHTML no supone un problema cuando no se dispone de JavaScript, ya que los datos serán validados en el servidor.

Sí que puede haber problemas cuando se emplea JavaScript para actualizar un control del formulario o una página web en función de las acciones del usuario. Por ejemplo, el típico caso de las listas desplegables en cascada (una lista que muestra sus valores en función de lo que se ha elegido en otra lista) realizado con JavaScript no funcionaría si está desactivado. Este problema es distinto al que se explica en esta entrada y merece una para él solo.

Consejo 1: no se debe usar botones de tipo button con el evento onclick para enviar un formulario

El código siguiente presenta un grave problema de accesibilidad: cuando JavaScript no está disponible, el formulario no se puede enviar.

function validar() {
// Algunas instrucciones para validar
// Al final, si todo va bien, se envía el formulario
document.forms[0].submit();
}

<input type="button" value="Enviar" onclick="validar()">Para solucionar este problema, se deben emplear los botones de tipo submit y utilizar el evento onsubmit para llamar al código de validación:

function validar() {
// Algunas instrucciones para validar
// Al final, si todo va bien, se envía el formulario
document.forms[0].submit();
}

<form action="unapagina.php" onsubmit="return validar()"></form>Consejo 2: utiliza múltiples clases para indicar el tipo de validación que requiere cada control de un formulario

En el artículo A Guide to Unobtrusive JavaScript Validation se presentan técnicas para separar el código JavaScript que realiza la validación de un formulario:

• Utilizar campos ocultos (hidden) para indicar las validaciones que se tienen que realizar (valor requerido, correo electrónico, código postal).
• Utilizar el atributo class para indicar el tipo de validación.
• Crear un DTD propio para añadir atributos que indican el tipo de validación.

La primera opción es poco práctica, ya que no es adecuada para formularios complejos con muchos campos. La tercera opción tampoco es práctica, ya que una página web basada en un DTD propio no es una página válida respecto a XHTML. Por tanto, la opción más recomendable es la segunda.

En el class se pueden añadir valores para indicar el tipo de validación que requiere el control:

• required
• notrequired
• email
• integer
• date

Por ejemplo:

<input type="text" name="correo" class="required email">
Para más información sobre cómo lograr un manejo de formularios correcto con JavaScript:

• A Guide to Unobtrusive JavaScript Validation
• Unobtrusive Javascript
• Javascript no obstructivo, Manual de buenas maneras (traducción al español del anterior)