domingo, 30 de enero de 2011

Respuesta a 25 dudas habituales sobre accesibilidad web

Artículos relacionados: Consejos avanzados de accesibilidad web

Última actualización: 16/04/2012

A continuación se dan respuesta a 25 dudas habituales de accesibilidad respondidas de acuerdo a las WCAG 2.0 y su documento asociado Techniques for WCAG 2.0


  1. ¿Puedo utilizar ventanas emergentes?
  2. ¿Puedo utilizar frames?
  3. ¿Puedo utilizar tablas para maquetar?
  4. ¿Mi sitio Web es inaccesible si utiliza Flash?
  5. ¿Mi sitio Web es inaccesible si utiliza javascript?
  6. ¿Cómo debo asociar los labels y los campos del formulario: de forma explícita o implícita?
  7. ¿Cómo debo presentar el texto: justificado o alineado a la izquierda?
  8. ¿Cómo he de marcar correctamente las abreviaciones y acrónimos?
  9. ¿Es correcto utilizar botones en la página que permitan aumentar el tamaño del texto?
  10. ¿Cómo se especifica correctamente el color de fondo y de primer plano?
  11. ¿Cómo marcar adecuadamente un emoticon?
  12. ¿Es correcto que aparezca en el código HTML un H2 antes que un H1?
  13. ¿Es recomendable incluir una opción de "Leer está página"?
  14. ¿Cuánto se ha de poder ampliar el tamaño de un texto?
  15. ¿Cómo marcar la pronunciación de una palabra?
  16. ¿Cómo se implementan de forma accesible los enlaces con el mismo texto que enlazan con diferentes páginas?
  17. ¿Debo indicar el cambio de idioma en cualquier tipo de palabra?
  18. ¿Cualquier sonido automático de la página tiene que tener la opción de pausar o detener el audio?
  19. ¿Está permitido que las imágenes que son enlaces no queden punteadas alrededor al coger el foco?
  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?
  21. ¿Una versión de alto contraste suple los requerimientos obligatorios de contraste entre el color de primer plano y el del fondo?
  22. ¿Cuándo puedo ponerle a una imagen alt=""?
  23. ¿Es correcto que el contenido de un input se borre al coger el foco?
  24. ¿Qué se considera texto grande y texto pequeño?
  25. ¿Es obligatorio antes de enviar un formulario que el usuario confirme el envío?

1. ¿Puedo utilizar ventanas emergentes?

Cuando hablamos de ventanas emergentes (pop-ups) nos referimos tanto a nuevas ventanas del navegador abiertas mediante el atributo TARGET como a ventanas que se abren mediante javascript con WINDOW.OPEN

El criterio de conformidad "3.2.5 Change on Request: Changes of context are initiated only by user request or a mechanism is available to turn off such changes. (Level AAA)" de las WCAG 2.0 dice:

The intent of this Success Criterion is to encourage design of Web content that gives users full control of changes of context. This Success Criterion aims to eliminate potential confusion that may be caused by unexpected changes of context such as automatic launching of new windows, automatic submission of forms after selecting an item from a list, etcetera. Such unexpected changes of context may cause difficulties for people with motor impairments, people with low vision, people who are blind, and people with certain cognitive limitations.

Asociado a este criterio hay dos técnicas que contestarán a nuestra pregunta:

H83: Using the target attribute to open a new window on user request and indicating this in link text

La técnica H83 dice así:

The objective of this technique is to avoid confusion that may be caused by the appearance of new windows that were not requested by the user. Suddenly opening new windows can disorientate or be missed completely by some users. In HTML 4.01 Transitional and XHTML 1.0 Transitional, the target attribute can be used to open a new window, instead of automatic pop-ups. (The target attribute is deleted from HTML 4.01 Strict and XHTML 1.0 Strict.)

Note that not using the target allows the user to decide whether a new window should be opened or not. Use of the target attribute provides an unambiguously machine-readable indication that a new window will open. User agents can inform the user, and can also be configured not to open the new window. For those not using assistive technology, the indication would also be available from the link text.

Es decir, aunque no se recomienda el uso de ventanas emergentes y se hace hincapié en los problemas que provocan, las WCAG 2.0 no prohíben el uso de TARGET con HTML 4.01 Transitional y XHTML 1.0 Transitional, eso sí, debe indicarse siempre mediante texto y dentro del enlace que se abrirá en ventana nueva.

Por ejemplo:

Show Help (opens new window)

¿Se puede ocultar la aclaración "se abre en ventana nueva" mediante la CSS? ¿Se puede indicar en el title del enlace?

El criterio de conformidad 2.4.4 (A) permite como técnicas suficientes para que los enlaces transmitan su próposito elegir (aparte de que el propio enlace sea suficientemente descriptivo):

  • que la aclaración se incluya con el atributo title. Es la técnica H33, pero en la misma, aunque permitida, se desaconseja su uso por las limitaciones del soporte del atributo title y se aconseja que el propio enlace describa su propósito aunque parte del mismo se oculte mediante la CSS.
  • incluir la aclaración dentro del enlace pero ocultarla por CSS

Sin embargo, para cumplir con el nivel AAA, sería obligatorio que la advertencia de que se abre en ventana nueva se incluya dentro del enlace puesto que:

  • así lo recomienda el texto y el ejemplo de la técnica H83 del criterio 3.2.5, tal y como hemos visto. Se especificaba que las ventanas emergentes no sólo causan problemas a personas con una discapacidad visual, sino también a personas con problemas motores o cognitivos que no están usando un lector de pantalla y para las cuales por tanto sería opaco el contenido oculto por CSS.
  • el criterio 2.4.9 (AAA) obliga a que el propósito de los enlaces esté especificado en el texto del enlace, aunque admite como técnica la ocultación de parte del texto del enlace mediante CSS. Pero no admite la aclaración en el atributo title del enlace.

SCR24: Using progressive enhancement to open new windows on user request

Tras advertir de nuevo de los problemas de las ventanas emergentes, se explica cómo hacer un WINDOW.OPEN de forma accesible mediante javascript no intrusivo.

Consultar la técnica para ver un ejemplo.

Conclusión

Hay muchas razones para no usar ventanas emergentes, sin embargo no están prohibidas por las WCAG 2.0, siempre y cuando se cumplan estas dos normas:

  • Si te utiliza TARGET se debe indicar dentro del enlace y mediante texto que se abre una ventana nueva.
  • Si se utiliza javascript el enlace debe tener un HREF con la ruta de la página y mediante javascript no intrusivo implementar el WINDOW.OPEN

Complementariamente se citan tres errores comunes a la hora de crear nuevas ventanas que sí reportan problemas de accesibilidad:

Es decir, no se debe abrir una ventana nueva al cargar la página sin que el usuario lo haya requerido, ni se deben abrir ventanas emergentes sin previo aviso cuando se introducen datos o se seleccionan campos en un formulario (cuando se cambia el estado de un check o un radio o se selecciona el elemento de una lista).

2. ¿Puedo utilizar frames?

La técnica H70: Using frame elements to group blocks of repeated material dice así:

The objective of this technique is to demonstrate how framesets can be used to group blocks of repeated material. Since most user agents and assistive technology provide a way to navigate from frame to frame, using frames to organize elements can provide a mechanism for easily bypassing blocks of repeated content. If the site uses framesets, organize the blocks of content into separate frames. Make certain that the repeated blocks of content appear in the same frame within the frameset of each Web page. In addition, each frame element must have a title attribute to describe the content of the frame. When frames are properly titled, users can use frame navigation to easily navigate between blocks of content.

This technique is appropriate when framesets are already used to organize the content of the page; other techniques are preferred for pages that are not already using framesets, because many people using assistive technology have trouble with frames. An advisory technique about using noframes is available in Success Criterion 4.2.1.

Esta técnica, como se indica en la misma, NO está recomendando el uso de frames. Únicamente reconoce su utilidad para agrupar contenido repetido y da instrucciones sobre cómo identificarlos correctamente en caso de que ya se estén usando en el sitio web.

Si se utilizan frames habrá que ofrecer un NOFRAMES y cada frame deberá tener un TITLE como se explica en la técnica H64: Using the title attribute of the frame and iframe elements

Ambas técnicas están asociadas al criterio de conformidad 2.4.1 Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages. (Level A)

Aunque no me gusten los frames, con las WCAG 2.0 en la mano podremos aconsejar que no se usen, pero no podremos mantener que es obligatorio eliminarlos si ya se están utilizando.

Conviene recordar que el uso de frames puede provocar diferentes problemas de usabilidad y accesibilidad en las páginas (si bien es cierto que hay soluciones para todos raramente se encuentran implementadas):

  • Suelen impedir que funcione correctamente el botón "Atrás" del navegador.
  • Aunque cambie el contenido de los frames, el URI del conjunto de frames no varía y por tanto no se puede hacer referencia a su estado actual con una dirección web.
  • Algunos navegadores pueden tener problemas para añadir una página a los marcadores o favoritos.
  • Los usuarios pueden tener dificultades para imprimir el conjunto de frames.
  • Suele suponer problemas para indexar correctamente las páginas por los buscadores, que pueden indexar cada frame y no estos en su conjunto.
  • El usuario podría acceder a un marco fuera de su contexto (por ejemplo a una página sin su cabecera o sin su menú de navegación).

3. ¿Puedo utilizar tablas para maquetar?

La técnica H73: Using the summary attribute of the table element to give an overview of data tables dice:

Although WCAG 2 does not prohibit the use of layout tables, CSS-based layouts are recommended in order to retain the defined semantic meaning of the HTML table elements and to conform to the coding practice of separating presentation from content. However, if a layout table is used, then the summary attribute is not used or is null. The purpose of a layout table is simply to control the placement of content; the table itself is “transparent" to the user. A summary would “break" this transparency by calling attention to the table. A null summary (summary="") on layout tables is acceptable.

Es decir, aunque hay razones de sobra para no utilizar tablas para maquetar y por ello se desaconseja su uso (también por ejemplo en las técnicas G140: Separating information and structure from presentation to enable different presentations y G146: Using liquid layout), las WCAG 2.0 no las prohíbe.

Eso sí, se han de cumplir ciertas reglas:

Así que si a pesar de todo alguien insiste "¿pero si se usan tablas para maquetar la página es innaccesible? ¿cumple con las WCAG 2.0?", pues la realidad es que sólo podemos contestar que si se cumplen las normas citadas sí se pueden usar.

Que nadie interprete que yo las recomiendo, por favor, me limito a informar de lo que dicen las WCAG 2.0

4. ¿Mi sitio es inaccesible si utiliza Flash?

En la presentación "WCAG 2 Compliance With Flash" (PDF, 151 KB), de The Paciello Group Blog se explica como con la versión 6 y posteriores el contenido Flash puede ser accesible y cumplir con las WCAG 2.0 puesto que:

  • All content exposed to AT
  • Keyboard accessibility
  • Accessible interactive components

En octubre de 2010 el W3C (World Wide Web Consortium) actualizó los documentos "Understanding WCAG 2.0" y "Techniques for WCAG 2.0" incluyendo 36 técnicas específicas para el contenido Flash, donde se explica como implementar Flash accesible de forma nativa.

Es reseñable que el documento de técnicas Flash del W3C ("Flash Techniques for WCAG 2.0") antes de comenzar a explicar estas técnicas que permiten hacer un Flash accesible de forma nativa, incluye tres consideraciones especiales para el cumplimiento de las WCAG 2.0:

  • 2.4.2 Page Titled - In order to meet 2.4.2, Flash content must be embedded within an HTML page that has a page title in the HTML title element. See H25: Providing a title using the title element (HTML).
  • 3.1.1 Language of Page - The language of Flash content is established by the lang attribute of the containing object element in HTML, not within the Flash SWF file itself. Authors may include more than one Flash SWF in a single web page, each with a different language indicated in the object element's lang attribute. See FLASH13: Using HTML language attributes to specify language in Flash content (Flash).
  • 3.1.2 Language of Parts - Since the language of Flash content is not established within the Flash SWF file, it is not currently possible to indicate changes of language within a single SWF file.

En resumen, si se considera la tecnología Flash como compatible con la accesibilidad y se utiliza de forma accesible (compatible con los productos de apoyo) NO deberemos ofrecer una alternativa accesible en HTML y en la declaración de conformidad se indicará que depende de la tecnología Flash.

Si se utiliza Flash de forma no accesible se deberá proporcionar una alternativa accesible (por ejemplo en HTML) y entonces en la declaración de conformidad no incluiríamos Flash como tecnología de la que se depende.

Si Flash se usa de forma no accesible y no se proporciona una alternativa accesible en otra tecnología como por ejemplo HTML, deberemos excluir las páginas que utilizan Flash de la declaración de conformidad.

Por último deberá cumplir también con el requisito de conformidad 5 de no interferencia:

5. Sin interferencia: Si las tecnologías se usan de una forma que no es compatible con la accesibilidad, o está usada de una forma que no cumple los requisitos de conformidad, no debe impedir a los usuarios acceder al contenido del resto de la página. Además, es necesario que la página web como un todo siga cumpliendo con los requisitos de conformidad en las siguientes circunstancias:

  1. cuando cualquier tecnología de la que no se depende está activada en una aplicación de usuario,
  2. cuando cualquier tecnología de la que no se depende está desactivada en una aplicación de usuario, y
  3. cuando cualquier tecnología de la que no se depende no es soportada por una aplicación de usuario

Por ejemplo, no puede atrapar el foco con el teclado sin dejarlo salir, no puede tener destellos que puedan provocar ataques epilépticos, etc.

Lo mismo se aplicaría a los documentos PDF.

Otras referencias de interés sobre accesibilidad y Flash son:

5. ¿Mi sitio es inaccesible si utiliza javascript?

Javascript no era bienvenido en las pautas WCAG 1.0, no olvidemos que datan de 1999, pero el W3C sí que contempla javascript y AJAX en las WCAG 2.0. Es más, se recomiendan soluciones implementadas con javascript en numerosas técnicas: para abrir ventanas emergentes de forma no intrusiva, para cambiar de CSS de forma dinámica, etc.

Estas son todas las técnicas relacionadas con javascript y ARIA:

El problema no es utilizar o no javascript, sino cómo se utiliza.

En el artículo "Creating Accessible JavaScript" de WebAIM, cuya lectura se recomienda en las técnicas, se resumen muy bien las normas para crear javascript accesible:

Such uses of JavaScript do not need additional accessibility features incorporated because important content is not displayed or functionality introduced by such scripting.

Making JavaScript accessible involves looking at the following issues.

  • When using event handlers, use only those that are device independent (e.g., do not require the use of the mouse only).
  • Content and functionality that is provided through scripting must be made accessible to assistive technologies.
  • Web pages that utilize scripting must be fully navigable using a keyboard.
  • JavaScript should not modify or override normal browser functionality in a way that may cause confusion.
  • When JavaScript cannot be made natively accessible, an accessible alternative must be provided.

¿Es necesario ofrecer una alternativa al JavaScript? ¿Se debe realizar una versión que funcione sin JavaScript?

La duda surge porque estamos acostumbrados a trabajar con las WCAG 1.0, en las cuales se especifica con claridad que es necesario una alternativa:

Punto de Verificación 6.3: Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page.

Las WCAG 2.0 lo que promueven es que el código JavaScript debe ser accesible nativamente. Es decir, si se implementa de forma no intrusiva, si es independiente del dispositivo (no requiere por ejemplo sólo el uso del ratón), si es accesible para los productos de apoyo, etc. no tiene porque suponer un problema de accesibilidad.

Pero si a pesar de todo no lo logramos, las WCAG 2.0 dicen en el Requisito de conformidad número 4:

4. Only Accessibility-Supported Ways of Using Technologies: Only accessibility-supported ways of using technologies are relied upon to satisfy the success criteria. Any information or functionality that is provided in a way that is not accessibility supported is also available in a way that is accessibility supported.

En el documento "Comparison of WCAG 1.0 Checkpoints to WCAG 2.0, in Numerical Order" del W3C, el punto 6.3 se corresponde además con los requisitos de conformidad 1 (nivel de conformidad) y 5 (no interferencia). Como nota adicional se dice: There is no longer a requirement that pages work without script or other programmatic objects, only that those objects meet the conformance requirements listed above.

En resumen, si se utiliza la tecnología javascript de forma accesible (compatible con los productos de apoyo, según las técnicas de las WCAG 2.0 y la implementación de WAI-ARIA) no deberemos ofrecer una alternativa accesible y en la declaración de conformidad se indicará que depende de la tecnología javascript.

Si se utiliza javascript de forma no accesible se deberá proporcionar una alternativa accesible y entonces en la declaración de conformidad no incluiríamos javascript como tecnología de la que se depende.

Si javascript se usa de forma no accesible y sin alternativa accesible entonces deberemos excluir las páginas que lo utilizan de la declaración de conformidad.

Por último deberá cumplir también con el requisito de conformidad 5 de no interferencia:

5. Sin interferencia: Si las tecnologías se usan de una forma que no es compatible con la accesibilidad, o está usada de una forma que no cumple los requisitos de conformidad, no debe impedir a los usuarios acceder al contenido del resto de la página. Además, es necesario que la página web como un todo siga cumpliendo con los requisitos de conformidad en las siguientes circunstancias:

  1. cuando cualquier tecnología de la que no se depende está activada en una aplicación de usuario,
  2. cuando cualquier tecnología de la que no se depende está desactivada en una aplicación de usuario, y
  3. cuando cualquier tecnología de la que no se depende no es soportada por una aplicación de usuario

He hablado de javascript accesible en algunos artículos anteriores:

6. ¿Cómo debo asociar los labels y los campos del formulario: de forma explícita o implícita?

La técnica H44: Using label elements to associate text labels with form controls asociada al criterio 1.3.1 (A) dice así:

The HTML and XHTML specifications allow both implicit and explicit labels. However, some assistive technologies do not correctly handle implicit labels (for example, <label>First name <input type="text" name="firstname"></label>).

  • JAWS 7.10 was tested on Windows XP with Internet Explorer 6.0 and Firefox 1.5. It reads the label for explicit and implicit labels for text fields in both virtual PC cursor and forms reading mode. In forms mode it does not read the label for implicit labels on checkboxes and radio fields.
  • Window-Eyes 5.5 was tested on Windows XP with Internet Explorer 6.0 and Firefox 1.5. It will always speak the label for an explicitly labelled form field. It does not speak the label for the implicitly labelled form control in browse on mode but will speak the implicit label when navigating from control to control in browse off mode.

Por dichas razones aconseja asociarlos de forma explícita como en estos ejemplo, es decir, mediante el atributo for del label y el id (que debe ser único en la página) del campo:


<label for="firstname">First name:</label>
<input type="text" name="firstname" id="firstname" />

<input type="checkbox" id="markuplang" name="computerskills" checked="checked">
<label for="markuplang">HTML</label>

Además se especifica que:

  • el label debe estar colocado antes del elemento del formulario al que etiqueta salvo que este sea un checkbox o un radiobutton (en cuyo caso se coloca detrás del mismo)
  • el label sólo se usa con los textarea, select e input (de tipo text, checkbox, radio, file y password) pero NO se usa con button (cuyo contenido es su etiqueta) ni con los input de tipo image (su atributo alt será su etiqueta), submit y reset (su atributo value es su etiqueta) o hidden (no tienen etiqueta)

Por otro lado, hay que destacar que la técnica H65, también asociada al criterio 1.3.1 (A), admite el uso del atributo title para etiquetar los campos de formulario cuando NO se usa para ello label, bien porque en el diseño de la página no hay un texto que pueda etiquetarse como label o tenerlo podría generar confusión.

En esta técnica se explica que si no hay un label los lectores de pantalla y los agentes de usuario en general pueden leer o mostrar el valor del title asociado a un campo de formulario (mejor soportado que en el caso de los enlaces)

Se ponen varios ejemplos muy habituales. Por ejemplo, si tenemos varios campos de fecha (dia, mes, año) o de cuenta bancaria, sin un label para cada uno, podemos etiquetarlos con su atributo title.

En el caso de tener un campo de búsqueda y un botón "Buscar", bastaría con que el campo tuviera un atributo title del estilo "Escribe el término de búsqueda aquí". Pero incluso ni esto sería necesario, puesto que sería suficiente con la técnica G167 que indica que un botón adyacente a un campo puede hacer de label del mismo (si su texto es claro y ejecuta una acción sobre el campo) Es decir, en este caso no sería necesario etiquetarlo ni con label ni con title y pone precisamente como ejemplo el caso del campo y el botón buscar.

7. ¿Cómo debo presentar el texto: justificado o alineado a la izquierda?

La técnica G169: Aligning text on only one side dice así:

Many people with cognitive disabilities have a great deal of trouble with blocks of text that are justified (aligned to both the left and the right margins). The spaces between words create "rivers of white" running down the page, which can make the text difficult for some people to read. This failure describes situations where this confusing text layout occurs. The best way to avoid this problem is to create text layout that is fully justified.

Es decir, el texto no debe justificarse, puesto que algunas personas con discapacidades cognitivas o visuales pueden tener problemas para leer el texto que está justificado a ambos lados. Esta dificultad proviene de que las variaciones entre el espaciado entre las palabras puede provocar que las palabras estén demasiado juntas o por el contrario "ríos blancos", es decir, zonas del texto donde la separación de las palabras dejan grandes zonas continuas de espacio en blanco.

Sin embargo se ofrece como alternativa que el sitio ofrezca un mecanismo para eliminar la justificación del texto como se especifica en la técnica G172: Providing a mechanism to remove full justification of text:

The objective of this technique is to provide a version of the page that does not have full justification (justified both left and right). There may be circumstances when for layout purposes an author may want to have the text fully justified. In these cases, it is sufficient to provide a feature that removes the justification of text. The control should be easy to find and access and near the beginning of the page.

El problema de la justificación del texto se presenta también como un error común de accesibilidad en F88: Failure of SC 1.4.8 due to using text that is justified (aligned to both the left and the right margins)

Todas ellas están asociadas al criterio de conformidad 1.4.8 Visual Presentation: For the visual presentation of blocks of text, a mechanism is available to achieve the following: (Level AAA)

8. ¿Cómo he de marcar correctamente las abreviaciones y acrónimos?

Hay varias técnicas relacionadas con el criterio de conformidad 3.1.4 Abbreviations: A mechanism for identifying the expanded form or meaning of abbreviations is available. (Level AAA).

El marcado dependerá de si la abreviación tiene un único significado en la página o si tiene diferentes significados dentro de la misma página.

Si la abreviación tiene un único significado en la página

En este caso habrá que explicar o ampliar la abreviatura la primera vez que aparece de una de las siguientes maneras:

Y habrá que explicar o ampliar la abreviatura en todas sus apariciones en la página de una de estas maneras:

Si la abreviación tiene diferentes significados dentro de la misma página

En este caso se deberá explicar o ampliar todas las veces que aparece siguiendo la técnica G55: Linking to definitions o la H28: Providing definitions for abbreviations by using the abbr and acronym elements.

Traté el tema de las abreviaturas y acrónimos en Más accesible a pesar de blogger (I). DÍA 8: Revisión de abreviaturas y acrónimos

9. ¿Es correcto utilizar botones en la página que permitan aumentar el tamaño del texto?

Asociado al criterio de conformidad 1.4.4 Resize text: Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality. (Level AA) está la técnica G178: Providing controls on the Web page that allow users to incrementally change the size of all text on the page up to 200 percent en la que se puede leer:

The purpose of this technique is to provide a mechanism on the Web page to incrementally increase the size of text. Many people with low vision do not use magnifying software, and they may not be familiar with browsers text size adjustments. This may be particularly true of older people who are learning about computers later in life and who may be experiencing age related vision loss. It may also be true of some people with cognitive disabilities who also require increased font size.

This technique provides a mechanism that some users will find easier to use. The mechanism may include links or buttons that will switch the visual presentation to a different style sheet or use scripts to change the text size dynamically.

To implement this technique, an author provides controls that allow the user to incrementally increase or decrease the text size of all of the text on the page to a size that is at least 200% of the default text size.

This can be achieved by providing links, buttons or linked images and the controls themselves should be as easy to find (ex. prominently positioned within the page, presented in a larger text size, hight contrast, etc.) as possible.

Está muy extendida la creencia de que los botones que permiten ampliar el tamaño de letra son un ejemplo de falsa accesibilidad, una moda, y que no deberían utilizarse (por ejemplo en Too much accessibility. GOOD INTENTIONS, BADLY IMPLEMENTED de Patrick H. Lauke).

Sin embargo vemos que es una técnica suficiente para cumplir con el criterio de conformidad 1.4.4 (AA) que puede ser útil para usuarios con baja visión que no usan magnificadores de pantalla y que no están acostumbrados a las opciones del navegador, como ejemplo personas mayores no habituadas al uso de ordenadores o personas con discapacidades cognitivas.

Para implementar correctamente estos botones (enlaces o imágenes) deben:

  • permitir aumentar progresivamente el tamaño del texto de la página hasta al menos un 200% de su tamaño por defecto
  • ser fáciles de localizar, con un tamaño grande y suficiente contraste
  • estar correctamente etiquetados de forma que se reconozca claramente cuál es su función

10. ¿Cómo se especifica correctamente el color de fondo y primer plano?

En el criterio de conformidad 1.4.8 Visual Presentation: For the visual presentation of blocks of text, a mechanism is available to achieve the following: (Level AAA) se especifican las técnicas que aseguran que el usuario podrá seleccionar los colores de primer plano y fondo:

  1. C23: Specifying text and background colors of secondary content such as banners, features and navigation in CSS while not specifying text and background colors of the main content (CSS)

    Example 1. An HTML Web page uses CSS to specify the text and background colors of all secondary content such as navigation bars, menu bars, and the table of contents. Neither the text color nor background of the main content is specified. The user sets their own color preferences in the browser so that they view the main content in colors and contrasts that work well for them. The distinction between the separate sections of the page are still visually obvious.

    Se puede consultar cómo modificar los colores en los principales navegadores en "Changing colours in your browser" de la BBC.

    OR

  2. C25: Specifying borders and layout in CSS to delineate areas of a Web page while not specifying text and text-background colors (CSS)

    Example 1. A Web page is designed using HTML. CSS is used to specify border colors around discrete areas of the page and to layout the content so that the menu floats to the left of the main content area. Neither the text color nor background is specified. The user sets their own colors in the browser. They can view the page in colors and contrasts that work well for them without disrupting the layout.

    OR

  3. G156: Using a technology that has commonly-available user agents that can change the foreground and background of blocks of text OR

  4. G148: Not specifying background color, not specifying text color, and not using technology features that change those defaults OR

  5. G175: Providing a multi color selection tool on the page for foreground and background colors

En resumen, tenemos dos posibilidades:

  • usar una tecnología que disponga de agentes de usuario de uso común que permitan cambiar el color de primer plano y del fondo de los bloques de texto, como es el caso de (X)HTML. La tecnología (X)HTML dispone de agentes de usuario (navegadores) de uso común que permiten configurar los colores de primer plano y de fondo de los bloques de texto. Por tanto, si usamos (X)HTML no es necesario que hagamos nada para cumplir este requisito porque los navegadores ya permiten que los usuarios puedan configurar las combinaciones de colores según sus necesidades.
  • o, en caso contrario, proporcionar una herramienta de selección de los colores de primer plano y de fondo.

También hay que tener en cuenta que, si la página tiene contenido secundario para el que es necesario mantener una agrupación visual, debemos asegurarnos que dicha agrupación se mantiene cuando los usuarios cambian los colores de primer plano y los colores de fondo. Para ello podemos utilizar algunas de las técnicas que ya se han indicado anteriormente:

  • Especificar en las hojas de estilo el color del texto y fondo del contenido secundario, como banners o mecanismos de navegación, sin especificar un color del texto ni del fondo para el contenido principal.
  • Especificar en las hojas de estilo los bordes para delimitar las áreas de contenido, sin especificar un color del texto ni del fondo para el contenido principal.

11. ¿Cómo marcar adecuadamente un emoticon?

La técnica H86: Providing text alternatives for ASCII art, emoticons, and leetspeak de las WCAG 2.0 nos indica cómo hacerlo adecuadamente.

Recomienda cuando sea posible usar simplemente una palabra en vez de un icono gestual. Pero si se usa un emoticon debe tener siempre un texto alternativo.

La técnica propone tres posibles marcados correctos:

=8-0 (fright): texto alternativo a continuación entre paréntesis

<abbr title="fright">=8-0</abbr>: marcarlo como abreviatura indicando en su atributo title su significado

<img src="fright.gif" alt="fright"/>: incluirlo como imagen con su correspondiente texto alternativo con alt

Relacionado con este punto también se indica que en el caso de un ASCII art largo, además de incluir la alternativa textual inmediatamente antes o después del dibujo, se debería incluir un enlace para saltarlo.

Por ejemplo, inmediatamente antes de un dibujo ASCII art largo de una persona, pondríamos un enlace Saltar dibujo con caracteres de una persona que vaya al contenido inmediatamente posterior al dibujo mediante un ancla. De este modo, el enlace sirve a la vez de descripción del dibujo y de enlace para saltarlo.

12. ¿Es correcto que aparezca en el código HTML un H2 antes que un H1?

En el diseño actual de páginas Web es habitual la maquetación en varias columnas. En este contexto, la pauta 3.5 de las WCAG 1.0 se puede convertir en un quebradero de cabeza, puesto que indica que "elementos H2 deberían seguir a los elementos H1, los H3 deberían seguir a los elementos H2, etc" ["Técnicas HTML para las Pautas de Accesibilidad al Contenido de la Web 1.0"]. De hecho, la validación automática dará un error en aquellas páginas en las que un H2 se encuentre antes que un H1.

Este problema se corrige en las WCAG 2.0. La técnica "H42: Using h1-h6 to identify headings" incluye un ejemplo significativo, en el cual el título del contenido principal coincide con el título de la página y está marcado como "H1" aunque no es el primero que aparece en la página. El contenido de la primera y tercera columna es menos importante y está marcado con "H2".

De modo que no es necesario que H1 aparezca antes que H2, lo importante es que realmente el título marcado como H1 sea de primer nivel y los marcados como H2 de segundo nivel.

Desgraciadamente el validador automático TAW para las WCAG 2.0 sigue mostrando un error en aquellas páginas que muestran un H2 antes que un H1 en el código.

La buena noticia es que me han dicho que lo van a corregir en la próxima versión.

13. ¿Es recomendable incluir una opción de "Leer está página"?

En algunos sitios nos encontramos una opción que proporciona un audio del contenido de la página mediante alguna herramienta automática de conversión de texto a voz como Vozme.

¿Se recomienda esta práctica?

En respuesta a esta duda, la técnica G79: Providing a spoken version of the text (proporcionar una versión hablada del texto) es una técnica suficiente para cumplir con el criterio de conformidad 3.1.5:

3.1.5 Nivel de lectura. Cuando un texto requiere un nivel de lectura más avanzado que el nivel mínimo de educación secundaria una vez que se han eliminado nombres propios y títulos, se proporciona un contenido suplementario o una versión que no requiere un nivel de lectura mayor a ese nivel educativo. Nivel AAA

En la técnica G79 se indica que para determinado tipo de usuarios puede resultar muy útil escuchar el texto leído en voz alta. Indican también que esto es efectivo para pequeñas cantidades de texto y para documentos que no cambian a menudo. Por tanto, es útil cuando lee el contenido textual y no toda la página (cabecera, menús, pie, etc.) como se encuentra en muchos portales.

También hay que tener en cuenta que está asociado a un criterio que habla de texto que requiere un nivel de lectura más avanzado que el de secundaria.

14. ¿Cuánto se ha de poder ampliar el tamaño de un texto?

El criterio de conformidad 1.4.4 (nivel AA) indica que a excepción de los títulos y las imágenes de texto, el texto debe poder cambiar su tamaño, sin un producto de apoyo, hasta un 200% (es decir, hasta dos veces el ancho y la altura) sin pérdida de contenido o funcionalidad. Por tanto, cuando el texto aumente no se deben producir desbordamientos o solapamientos de contenido que dificulten su percepción. Por ejemplo, porque algunos contenidos se salgan de su contenedor y se posicionen sobre otro contenido.

The working group feels that 200% is a reasonable accommodation that can support a wide range of designs and layouts, and complements older screen magnifiers that provide a minimum magnification of 200%.

Above 200%, zoom (which resizes text, images, and layout regions and creates a larger canvas that may require both horizontal and vertical scrolling) may be more effective than text resizing.

Assistive technology dedicated to zoom support would usually be used in such a situation and may provide better accessibility than attempts by the author to support the user directly.

15. ¿Cómo marcar la pronunciación de una palabra?

En el criterio de conformidad 3.1.6 (nivel AAA) se indican distintas técnicas. La más sencilla es colocar la pronunciación entre paréntesis tras la palabra, pero hay otras como incluir un glosario con la pronunciación de las palabras o asociar la palabra con un fichero de audio donde se escuche su pronunciación.

Una de estas técnicas es la H62: Using the ruby element, en la cual se propone utilizar el elemento RUBY.

Ejemplo:

When we talk about these guidelines, we often just call them WCAG ( Wuh-KAG )

Si estás usando Explorer, que soporta este elemento desde la versión 5.0, verás escrita la pronunciación sobre el acrónimo "WCAG"; si accedes desde Firefox, Opera o Chrome la pronunciación la encontrarás tras el acrónimo entre paréntesis (nota 2015: las últimas versiones se Chrome y Chrome ya muestran la pronunciación sobre la palabra); si accedes con un lector de pantalla como JAWS oirás "uve doble ce a ge abre paréntesis gu kag cierra paréntesis".

El código del ejemplo es:

<p>When we talk about these guidelines, we often just call them
<ruby>
<rb>WCAG</rb>
<rp>(</rp>
<rt>Wuh-KAG</rt>
<rp>)</rp>
</ruby>.
</p>

Hay que tener muy presente que esta solución sólo sirve para páginas XHTML 1.1, pues es un elemento que no está definido en versiones anteriores. Por tanto, si lo utilizas con HTML 4 o XHTML 1.0 la página no será válida (nota 2015: en HTML5 también existe el elemento RUBY)

Para más información sobre RUBY: Ruby Annotation. W3C Recommendation 31 May 2001 (Markup errors corrected 25 June 2008).

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>

Pero sería correcto:

<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.)

De forma general, además de usar el texto de la frase que contiene al enlace, también podemos incluir la descripción adicional en aquellos elementos que los producto de apoyo como un lector de pantalla puede relacionar con el enlace. En estos casos es preferible que la información de contexto que aclara el propósito de los enlaces esté situada antes de los enlaces.

Entre los contextos que se pueden determinar por software tenemos:

  • Elemento de lista (LI) que contiene al enlace.
  • En listas anidadas, elemento de la lista padre (LI) que contiene la lista en la que se encuentra el enlace.
  • Párrafo (P) que contiene al enlace.
  • Celda (TD) de la tabla que contiene al enlace y sus encabezados asociados (TH)
  • Elemento de encabezado anterior H1-H6

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 sapiens, 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 que se considere si la palabra se pronuncia igual que en el idioma del texto que la rodea (salvo por el acento o la entonación): 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:

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:

Logotipo del W3C con borde punteado porque ha recibido el foco

Si el foco es visible facilita el uso de las páginas web mediante el teclado al permitir reconocer visualmente y en todo momento cuál es el componente con el cual se está interactuando. Asimismo, resaltar los elementos cuando reciben el foco también sirve para que los usuarios sepan que se trata de elementos de interacción.

Por otra parte, las personas con problemas de atención, memoria a corto plazo o limitaciones para realizar procesos también se benefician al poder reconocer en todo momento dónde se encuentra el foco.

En caso de que queramos modificar la presentación del indicador del foco por defecto, debemos hacerlo de forma que mejoremos claramente su visibilidad (por ejemplo cuando un campo del formulario coja el foco que presente bordes anchos y otro color de fondo) y que se muestre tanto al coger el foco con el ratón como mediante el teclado.

También es importante otro aspecto relacionado con el foco, y es que los enlaces ocultos (por ejemplo para "saltar al contenido") deben ser visibles al menos cuando cojan el foco porque si siempre están ocultos generan desorientación y confusión a los usuarios de teclado al tabular por elementos no visibles.

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 o símbolos (40 si se trata de chino, japonés o coreano)..

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 :

Para cumplir este requisito es suficiente con no interferir en la reubicación del texto cuando se disminuye el tamaño de la ventana (hasta una cuarta parte del ancho de la pantalla). El objetivo es permitir que los usuarios puedan redimensionar la ventana hasta conseguir un ancho de línea ideal sin que se produzca scroll horizontal para leer una línea de texto.

Para ello el ancho de los contenedores principales de texto se deberá definir con unidades de medida relativas.

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 &nbsp;) 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 conformidad 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.

Artículo relacionado: Textos alternativos, imágenes accesibles. Herramientas de ayuda: mapa de decisión y wizard online

23. ¿Es correcto que el contenido de un input se borre al coger el foco?

En el criterio de conformidad 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 algunos criterios de conformidad de las WCAG 2.0 (1.4.3, 1.4.6) se establecen diferentes obligaciones en función de si el tamaño de texto es grande o no.

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 resumen, se considera texto grande al que tiene al menos 18 pt o 14 pt en negrita, medidas que, salvo para las fuentes muy delgadas o inusuales, se consideran suficientes para la mayor parte de las tipografías.

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:

* Como todos los artículos de este blog, este es un artículo NO promocionado.

Autor: Olga Carreras Montoto

Etiquetas: ,

Compártelo en:

Histórico de artículos:

< < Página de inicio

Subir al comienzo de la página



1 comentarios :
Anónimo dijo...

Impresionante!! Muchas gracias por el artículo :)

Fecha: 15 de febrero de 2011, 22:07


Eliminar comentario de ' Anónimo ' con fecha de 15 de febrero de 2011, 22:07

Publicar un comentario