Respuesta a 25 dudas habituales sobre accesibilidad web
En los artículos Técnicas WCAG 2.0 para 10 dudas habituales sobre accesibilidad y Técnicas WCAG 2.0 para otras 5 dudas sobre accesibilidad incluía las respuestas a 15 dudas de accesibilidad basándome en el documento "Techniques for WCAG 2.0" de las WCAG 2.0
A continuación listo el enlace a las 15 dudas ya resueltas en esos artículos anteriores y el ancla a las 10 nuevas dudas que se resuelven en este artículo.
- ¿Mi sitio Web es inaccesible si utiliza ventanas emergentes?
- ¿Mi sitio Web es inaccesible si utiliza frames?
- ¿Mi sitio Web es inaccesible si utiliza tablas para maquetar?
- ¿Mi sitio Web es inaccesible si utiliza Flash?
- ¿Mi sitio Web es inaccesible si utiliza javascript?
- ¿Cómo debo asociar los labels y los campos del formulario: de forma explícita o implícita?
- ¿Cómo debo presentar el texto: justificado o alineado a la izquierda?
- ¿Cómo he de marcar correctamente las abreviaciones y acrónimos?
- ¿Es correcto utilizar botones en la página que permitan aumentar el tamaño del texto?
- ¿Cómo se especifica correctamente el color de fondo y de primer plano?
- ¿Cómo marcar adecuadamente un emoticon?
- ¿Es correcto que aparezca en el código HTML un H2 antes que un H1?
- ¿Es recomendable incluir una opción de "Leer está página"?
- ¿Cuánto se ha de poder ampliar el tamaño de un texto?
- ¿Cómo marcar la pronunciación de una palabra?
- ¿Cómo se implementan de forma accesible los enlaces con el mismo texto que enlazan con diferentes páginas?
- ¿Debo indicar el cambio de idioma en cualquier tipo de palabra?
- ¿Cualquier sonido automático de la página tiene que tener la opción de pausar o detener el audio?
- ¿Está permitido que las imágenes que son enlaces no queden punteadas alrededor al coger el foco?
- ¿Hay alguna limitación en cuanto al ancho de un bloque de texto? ¿Alguna pauta de accesibilidad indica el número de caracteres que debe tener?
- ¿Una versión de alto contraste suple los requerimientos obligatorios de contraste entre el color de primer plano y el del fondo?
- ¿Cuándo puedo ponerle a una imagen alt=""?
- ¿Es correcto que el contenido de un
inputse borre al coger el foco? - ¿Qué se considera texto grande y texto pequeño?
- ¿Es obligatorio antes de enviar un formulario que el usuario confirme el envío?
16. ¿Cómo se implementan de forma accesible los enlaces con el mismo texto que enlazan con diferentes páginas?
Es el típico ejemplo de "Leer más" o "Más información" en un listado de noticias.
En las WCAG 1.0 se especifica en relación al punto de verificación 13.1 Identifique claramente el objetivo de cada vínculo que si en la página hay dos o más vínculos con el mismo texto deben remitir al mismo recurso y de lo contrario se han de diferenciar por el atributo "title":
Si hay más de un vínculo en una página con el mismo texto, todos estos vínculos deben remitir al mismo recurso. Esta coherencia ayudará al diseño de la página tanto como a la accesibilidad.
Si dos o más vínculos van referidos a objetivos diferentes pero comparten el mismo texto, distinga los vínculos especificando un valor diferente para el atributo "title" de cada elemento A.
En "Técnicas HTML para las Pautas de Accesibilidad de los Contenidos Web 1.0" del W3C.
Las WCAG 2.0 también tienen dos criterios de conformidad (2.4.4 de nivel A y 2.4.9 de nivel AAA) que obligan a que se clarifique el propósito de un vínculo. Una de las técnicas suficientes para cumplir con el criterio de conformidad 2.4.4 es la "H33: Supplementing link text with the title attribute". Esta técnica consiste también en incluir el atributo "title" para clarificar el destino del vínculo cuando la información complementaria proporcionada por el atributo "title" es algo que el usuario debe saber antes de seguir el enlace.
Sin embargo, la propia técnica H33 de las WCAG 2.0 desaconseja el uso del atributo "title" para clarificar el destino de un vínculo por la falta de soporte del atributo "title" en muchos user-agent. De hecho, esta técnica no es válida para cumplir con el criterio de conformidad 2.4.9, que también se refiere a clarificar el destino de un vínculo pero es más estricto por ser de nivel AAA.
En esta técnica se recomiendan otras dos técnicas suficientes alternativas al uso de "title":
- o bien que el enlace tenga el texto completo (sería la técnica H30) por ejemplo: "Leer más sobre el artículo 'WCAG 2.0'" en vez de "Leer más"
- o bien ocultar mediante CSS el texto del enlace que sigue a "Leer más" (sería la técnica C7), lo cual resulta muy útil cuando el texto del enlace puede llegar a ser demasiado extenso. También se permite incluir un enlace o botón para ver u ocultar las versiones largas de los enlaces (serían las técnicas G189 y SCR30)
Estas alternativas permitirían cumplir con los criterios de conformidad 2.4.4 (nivel A) y 2.4.9 (nivel AAA).
En cuanto a la opción de ocultar por CSS parte del texto del enlace, es necesario que la ocultación del texto se haga de forma accesible para los lectores de pantalla, es decir, no se debe utilizar display:none sino localizarlo fuera de pantalla.
El ejemplo correcto sería el siguiente:
En la CSS:
a span { height: 1px; width: 1px; position: absolute; overflow: hidden; top: -10px; }
En la página:
<dl>
<dt>Winnie the Pooh </dt>
<dd><a href="winnie_the_pooh.html">
<span>Winnie the Pooh </span>HTML </a> </dd>
<dd><a href="winnie_the_pooh.pdf">
<span>Winnie the Pooh </span>PDF </a> </dd>
<dt>War and Peace</dt>
<dd><a href="war_and_peace.html">
<span>War and Peace </span>HTML</a></dd>
<dd><a href="war_and_peace.pdf">
<span>War and Peace </span>PDF </a> </dd>
</dl>
Hay otra manera de cumplir con la pauta 2.4.4 (nivel A), pero que sin embargo no será válida para cumplir con la pauta 2.4.9 (nivel AAA), y por tanto es menos aconsejable, pues las WCAG 2.0 alientan a cumplir más criterios de los estrictamente necesarios para alcanzar un determinado nivel de adecuación.
Esta última alternativa es que será válido el enlace "Leer más" cuando esté correctamente contextualizado. Por ejemplo, en el caso de un párrafo (sería la técnica H78) el W3C propone el siguiente ejemplo:
Sería incorrecto:
<p>Coming soon to a town near you...the final 15 in the
National Folk Festival lineup.</p>
<p><a href="final15.html">[Read more...]</a></p>
<p>Coming soon to a town near you...the final 15 in the
National Folk Festival lineup.
<a href="final15.html">[Read more...]</a>
</p>
De igual manera, hay otras técnicas para indicar cómo se puede asociar correctamente un enlace con su contexto (en listas, tablas, etc.)
17. ¿Debo indicar el cambio de idioma en cualquier tipo de palabra?
La pauta 4.1 (prioridad 1) de las WCAG 1.0 indica Identifique claramente los cambios en el idioma del texto del documento y en cualquier texto equivalente
. De la misma manera, el criterio de conformidad 3.1.2 de las WCAG 2.0 también obliga a identificar los cambios de idioma pero establece una serie de excepciones. No es necesario identificar el cambio de idioma de:
- los nombres propios
- los términos técnicos, por ejemplo: Homo sapien, Alpha Centauri, hertz, habeas corpus (ejemplos textuales de la explicación del criterio)
- las palabras en un idioma indeterminado
- las palabras o frases que se hayan convertido en parte natural del texto que las rodea.
Para resolver las dudas que esto puede ocasionar recomiendan: If there is doubt whether a change in language is intended, consider whether the word would be pronounced the same (except for accent or intonation) in the language of the immediately surrounding text.
18. ¿Cualquier sonido automático de la página tiene que tener la opción de pausar o detener el audio?
La pauta 1.4.2 (nivel A) de las WCAG 2.0 indica que sólo es necesario si el sonido dura más de 3 segundos: If any audio on a Web page plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level. (Level A)
19. ¿Está permitido que las imágenes que son enlaces no queden punteadas alrededor al coger el foco?
Es una práctica habitual utilizar :focus{outline:0;} o peor aun onfocus="blur()" para evitar que las imágenes queden punteadas alrededor cuando cogen el foco.
Las WCAG 1.0 indican mediante el punto de verificación 9.4 (de prioridad 3 y de prioridad 2 en la Norma UNE 139803) que es necesario poder acceder mediante el tabulador a vínculos, controles de formulario y objetos. Sin embargo no se especifica si es necesario que el foco sea visible.
Esto se corrige en las WCAG 2.0 Su criterio de conformidad 2.4.7 (nivel AA) especifica claramente que el foco debe ser visible, de hecho incluye como fallos habituales las dos prácticas comentadas:
- F55: Failure of Success Criteria 2.1.1, 2.4.7, and 3.2.1 due to using script to remove focus when focus is received
- F78: Failure of Success Criterion 2.4.7 due to styling element outlines and borders in a way that removes or renders non-visible the visual focus indicator.
Por tanto, no sólo se debe poder acceder mediante el tabulador a toda imagen que sea enlace, sino que además cuando coja el foco este debe ser visible como se aprecia en este ejemplo:
20. ¿Hay alguna limitación en cuanto al ancho de un bloque de texto? ¿Alguna pauta de accesibilidad indica el número de caracteres que debe tener?
Una duda habitual es la anchura que debe tener (en número de carácteres) un bloque de texto para su óptima legibilidad. Hay muchos estudios al respecto, unos recomiendan entre 80-100 caracteres y otros entre 60-80 por ser el ancho preferido de los usuarios. Se pueden consultar esos estudios en el artículo "Columnas, anchos de línea y legibilidad" de Juan Carlos García.
¿Dicen algo al respecto las WCAG? El criterio de conformidad 1.4.8 (nivel AAA) indica que el ancho de un bloque de texto no debe ser mayor de 80 caracteres.
For people with some reading or vision disabilities, long lines of text can become a significant barrier. They have trouble keeping their place and following the flow of text. Having a narrow block of text makes it easier for them to continue on to the next line in a block. Lines should not exceed 80 characters or glyphs (40 if CJK), where glyphs are the element of writing in the writing system for the text.
En relación con este requisito, las técnicas que aseguran que sea así aunque se redimensione el navegador son :
- C20: Using relative measurements to set column widths so that lines can average 80 characters or less when the browser is resized, o
- H87: Not interfering with the user agent's reflow of text as the viewing window is narrowed
En este criterio de conformidad también se especifica que el espacio entre líneas (interlineado) debe ser, al menos, un espacio y medio dentro de los párrafos y el espacio entre párrafos, al menos, de 1.5 veces mayor que el espacio entre líneas.
People with some cognitive disabilities find it difficult to track text where the lines are close together. Providing extra space between lines and paragraphs allows them to better track the next line and to recognize when they have reached the end of a paragraph. It is best if there are several different options, for instance, space-and-a-half and double spacing for line spacing. By space and a half within paragraphs we mean that top of one line is 150% further from the top of the line below it than would be true when the text is 'single spaced' (the default spacing for the font). By Paragraph spacing that is 1.5 times larger than the line spacing we mean that the spacing from the top of the last line of 1 paragraph is 250% farther from the Top of the first line of the next paragraph (i.e., that there is a blank line between the two paragraphs that is 150% of the single space blank line). 21. ¿Una versión de alto contraste suple los requerimientos obligatorios de contraste entre el color de primer plano y el del fondo?
La técnica G174 de las WCAG 2.0 ofrece como alternativa para cumplir con los criterios de conformidad 1.4.3 y 1.4.6 referentes al contraste de color, el utilizar la cláusula de "Version alternativa" de los requisitos de conformidad e incluir un botón o enlace para visualizar la página en alto contraste. Un ejemplo de una web que ofrece una versión en alto contraste es: Media, del Ministerio de Educación.
Pero para que se utilice con éxito esta técnica es necesario:
- El botón o enlace a la versión alto contraste debe cumplir con los requerimientos de contraste.
- La versión alto contraste debe tener el mismo contenido y funcionalidad.
- La versión alto contraste debe cumplir con todos los demás requisitos de accesibilidad.
Los dos últimos requisitos no deben suponer un problema si simplemente se carga una CSS diferente.
22. ¿Cuándo puedo ponerle a una imagen alt=""?
¿Qué entendemos por imagen decorativa? Cualquier imagen que no forma parte del contenido significativo de la página y que por tanto debería ser ignorada por los lectores de pantalla. Según la definición incluida en el criterio de conformidad 1.1.1: serving only an aesthetic purpose, providing no information, and having no functionality
Las imágenes decorativas deberían estar definidas en las CSS, pero si se incluyen en las páginas deben tener alt=""
El error cómun F39. Failure of Success Criterion 1.1.1 due to providing a text alternative that is not null (e.g., alt="spacer" or alt="image") for images that should be ignored by assistive technology indica además que aunque es válido alt=" " (ojo, se admite un espacio en blanco pero no que contenga ) es más recomendable usar alt="".
Además las imágenes decorativas no podrán tener el atributo "title" o este deberá estar vacío (ver técnica H67)
NO se puede considerar que una imagen es decorativa (y por tanto no puede estar definida en la CSS ni tener alt=""):
- si es un enlace, a no ser que sea un icono que acompaña a un texto y el enlace los englobe a los dos, en cuyo caso el alt del icono sí deberá ser vacío (ver técnica H2)
- si incluye texto, a no ser que dicho texto sea también decorativo, entendiendo como tal (ver criterio de éxito 1.4.9):
Text is only purely decorative if the words can be rearranged or substituted without changing their purpose. Example: The cover page of a dictionary has random words in very light text in the background.
23. ¿Es correcto que el contenido de un input se borre al coger el foco?
En el criterio de éxito 3.2.2 se especifica que un cambio de contenido no siempre es un cambio de contexto. En este caso es válido que se borre el texto de un input al coger el foco pues supone un cambio de contenido pero no un cambio de contexto.
Por el contrario, no sería válido el comportamiento que se implementa a veces en los campos de fecha o de número de cuenta, en los que al terminar de incluir el contenido del campo el foco salta automáticamente al siguiente campo, pues en este caso sí que es un cambio de contexto. Según se especifica, si se implementa este comportamiento se debe incluir una explicación antes de los campos: consultar la ténica G13: Describing what will happen before a change to a form control that causes a change of context to occur is made
24. ¿Qué se considera texto grande y texto pequeño?
En el criterio de conformidad 1.4.3 se indica:
large scale (text)
with at least 18 point or 14 point bold or font size that would yield equivalent size for Chinese, Japanese and Korean (CJK) fonts
Note 1: Fonts with extraordinarily thin strokes or unusual features and characteristics that reduce the familiarity of their letter forms are harder to read, especially at lower contrast levels.
Note 2: Font size is the size when the content is delivered. It does not include resizing that may be done by a user.
Note 3: The actual size of the character that a user sees is dependent both on the author-defined size and the user's display or user-agent settings. For many mainstream body text fonts, 14 and 18 point is roughly equivalent to 1.2 and 1.5 em or to 120% or 150% of the default size for body text (assuming that the body font is 100%), but authors would need to check this for the particular fonts in use. When fonts are defined in relative units, the actual point size is calculated by the user agent for display. The point size should be obtained from the user agent, or calculated based on font metrics as the user agent does, when evaluating this success criterion. Users who have low vision would be responsible for choosing appropriate settings.
Note 4: When using text without specifying the font size, the smallest font size used on major browsers for unspecified text would be a reasonable size to assume for the font. If a level 1 heading is rendered in 14pt bold or higher on major browsers, then it would be reasonable to assume it is large text. Relative scaling can be calculated from the default sizes in a similar fashion.
Note 5: The 18 and 14 point sizes for roman texts are taken from the minimum size for large print (14pt) and the larger standard font size (18pt). For other fonts such as CJK languages, the "equivalent" sizes would be the minimum large print size used for those languages and the next larger standard large print size.
En cuanto al texto incluido en las imágenes se especifica:
Note: Because different image editing applications default to different pixel densities (ex. 72 PPI or 96 PPI), specifying point sizes for fonts from within an image editing application can be unreliable when it comes to presenting text at a specific size. When creating images of large-scale text, authors should ensure that the text in the resulting image is roughly equivalent to 1.2 and 1.5 em or to 120% or 150% of the default size for body text. For example, for a 72 PPI image, an author would need to use approximately 19 pt and 24 pt font sizes in order to successfully present large-scale images of text to a user.
25. ¿Es obligatorio antes de enviar un formulario que el usuario confirme el envío?
El criterio de conformidad 3.3.4 (nivel AA) indica que es necesario que:
- los envíos sean reversibles,
- o bien que se puedan comprobar los datos y dar la oportunidad al usuario de corregirlos,
- o bien que se ofrezca un mecanismo para revisar, confirmar y corregir la información antes de enviarla.
El criterio 3.3.4 sólo obliga a las páginas que:
- causen compromisos legales
- supongan una transación económica
- modifiquen o borren datos controlables por el usuario
- envíen respuestas del usuario a algún tipo de prueba
Sin embargo, el criterio de conformidad 3.3.6, que es de nivel AAA y por tanto es más estricto, obliga a cualquier tipo de envío de información.
Se pueden consultar las distintas formulas para implementar estas opciones en las técnicas asociadas a este criterio 3.3.4
Artículos relacionados:
Etiquetas: accesibilidad general, Técnicas WCAG 2.0, WCAG 2.0
1 comentarios en el artículo "Respuesta a 25 dudas habituales sobre accesibilidad web"
Sígueme en: