Todo tipo de información sobre accesibilidad en la Web: errores de accesibilidad, ejemplos de páginas inaccesibles, noticias, software, hardware, productos de apoyo, consejos, pautas y guías de accesibilidad, WAI, WCAG, Norma EN 301 549, legislación, etc.
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.
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.
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.
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.
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.
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:
* 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:
In this post, we'll explore some of the design trends we increasingly run into on the Web today, and how decisions made during the design phases can have a hugely detrimental effect on anyone who uses the web in a slightly differently way.
Las tres tendencias que se analizan son:
Three such examples of current design trends that have a tremendously negative impact on people with disabilities are: placeholder text labels, parallax scrolling and conversational interfaces (chatbots). As we'll see in the next few paragraphs, each of these trends are likely to create significant barriers for some of us, if basic accessibility concepts are not taken into consideration.
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:
Disappearing placeholder text is easy to forget
Not all browsers support placeholders
Pre-populated values are hard to understand
Reviewing a long form is difficult
Erroneous fields are harder to fix
Some browsers will remove placeholder text on focus
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.
