Blog para dispositivos móviles | [S] Ir al contenido |
Su navegador no admite frames. <a href='http://www.blogger.com/home'>Acceder a la página pricipal de Blogger</a>

martes 5 de mayo de 2009

Técnicas WCAG 2.0 para 10 dudas habituales sobre accesibilidad

Artículos relacionados
[30-01-11] Respuesta a 25 dudas habituales sobre accesibilidad web
[02-06-09] Formularios accesibles según las WCAG 2.0
[27-03-09] AJAX accesible IV: Técnicas ARIA de las WCAG 2.0
[12-02-08] WCAG 2.0




Última actualización: 15 de mayo de 2009. He añadido Apéndice: Resolución de dudas que ha suscitado el artículo


Las "Techniques for WCAG 2.0. Techniques and Failures for Web Content Accessibility Guidelines 2.0" son un recurso imprescindible que todo el mundo debería sacar tiempo para leer. Bastante tiempo, puesto que son más de 300. Sin embargo merece la pena, ya que resuelven muchas dudas habituales sobre accesibilidad.


Voy a dedicar diversos artículos a comentar algunas de estas técnicas. El de hoy trata sobre cómo el documento "Techniques for WCAG 2.0" da respuesta a las Dudas, con mayúsculas, puesto que son las preguntas que te hacen una y otra vez y que de forma recurrente aparecen en los foros sobre accesibilidad.


Índice



  1. ¿Mi sitio Web es inaccesible si utiliza ventanas emergentes?

  2. ¿Mi sitio Web es inaccesible si utiliza frames?

  3. ¿Mi sitio Web es inaccesible si utiliza 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?


Apéndice: Resolución de dudas que ha suscitado el artículo




¿Mi página es inaccesible si utiliza ventanas emergentes?


Cuando hablamos de ventanas emergentes nos referimos tanto a las que se abren mediante un TARGET como a las que se abren con un WINDOW.OPEN


El criterio de éxito "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 primera duda:



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?


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.





¿Mi sitio es inaccesible si utiliza 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.





Es decir, el uso de frames se recomienda para evitar contenido repetido, pero sólo cuando ya se están usando, sino es preferible otras técnicas.


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 éxito 2.4.1 Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages. (Level A)


De nuevo, y 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.





¿Mi sitio es inaccesible si utiliza 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 (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


¿Mi sitio es inaccesible si utiliza Flash?



En este punto simplemente me remito a la presentación "WCAG 2 Compliance With Flash" (PDF, 151 KB), de The Paciello Group Blog.

En ella 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




Como ocurre a menudo el problema no está en la tecnología en sí sino en los desarrolladores.


Recomiendo también la lectura del artículo: "Flash navegable mediante teclado en Firefox" de Uninstallme.


Nota enero 2011: 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.




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




¿Mi sitio es inaccesible si utiliza javascript?



Javascript no era bienvenido en las normas 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 recomienda 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. Por ejemplo se deben usar eventos de ratón y teclado (SCR2: Using redundant keyboard and mouse event handlers, SCR20: Using both keyboard and other device-specific functions)




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 crear una versión que funcione sin javascript?

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






¿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 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 ello se aconseja asociarlos de forma explícita, por ejemplo:




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




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





En resumen, el texto no debe justificarse. 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 éxito 1.4.8 Visual Presentation: For the visual presentation of blocks of text, a mechanism is available to achieve the following: (Level AAA)





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



Hay varias técnicas relacionadas con el criterio de éxito 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





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



Asociado al criterio de éxito 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 éxito 1.4.4.





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



En el criterio de éxito 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



Apéndice: Resolución de dudas que ha suscitado el artículo


¿Se puede ocultar la aclaración "se abre en ventana nueva"?


Como comento en la duda 1, cuando se abre una ventana nueva mediante TARGET, hay que incluir en el enlace una aclaración del tipo "se abre en ventana nueva".

La duda que surge es: ¿resulta relevante que la aclaración se vea?

Las ventanas emergentes no sólo desconciertan a los usuarios con problemas de visión sino también a personas de edad avanzada, con poca experiencia en el uso de Internet o con alguna discapacidad cognitiva, por tanto sí es necesario que se vea. No se debe ocultar mediante la CSS.



¿Es necesario ofrecer una alternativa al JavaScript?


¿Se debe realizar una versión que funcione sin JavaScript?

La duda surge porque estamos aconstumbrados 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. Un ejemplo sería el expuesto en
Formulario con varios botones. Implementación usable y accesible, o el que se cita en la duda 1 sobre abrir una ventana con WINDOW.OPEN de forma accesible.

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 las tecnologías asistivas, etc. no tiene porque suponer un problema de accesibilidad.

Pero si a pesar de todo no lo logramos (un ejemplo sería el comentado en Accesibilidad, firma electrónica y DNIe en el ámbito de las Administraciones Públicas), 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 y 5. 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, no es necesario que la página funcione sin scripts, sino que cumpla con dichos requerimentos. Pero el requerimento 4 dice "cualquier información o funcionalidad que se proporcione de manera que no sea accesiblemente soportada deben estar disponibles de forma accesiblemente soportada".

Por tanto, si el JavaScript no es sí mismo accesible se debe proporcionar una alternativa accesible.




¿Hay que ofrecer una alternativa a los PDF?


Nos encontraríamos con el mismo panorama que en la duda anterior. El PDF debe hacerse accesible de forma nativa como expliqué en PDF accesibles, sino se debe proporcionar una alternativa accesible.

Resultan muy recomendables los artículos:



Artículos relacionados
[02-06-09] Formularios accesibles según las WCAG 2.0
[27-03-09] AJAX accesible IV: Técnicas ARIA de las WCAG 2.0
[12-02-08] WCAG 2.0

Etiquetas: , , , ,

Compártelo en:

Compartir


Share |

11 comentarios en el artículo "Técnicas WCAG 2.0 para 10 dudas habituales sobre accesibilidad"



Noticias... (18)

Estas son las noticias que han llamado últimamente mi atención:


  • "Francia aprobará nuevas normas sobre accesibilidad de las páginas web de organismos públicos", Ecodiario (24/04/09)

  • "El cermi denuncia falta de accesibilidad de la página web de la universidad autónoma de madrid", EcoDiario (01/05/09). Primero fue la web del Metro de Madrid, ahora la de la Universidad Autónoma de Madrid (UAM), y no será la última:

    "El Cermi ya ha denunciado por estos mismos motivos a Metro de Madrid y continuará con estas actuaciones dentro de una campaña para forzar el cumplimiento de las obligaciones de accesibilidad por parte de las entidades públicas", advierte.


  • " Cadis y UZ desarrollan un sistema de control del ordenador por voz", Diario del AltoAragón (21/04/09). Una de las ventajas del "Programa de barrido controlado con la voz" es que antes, con los pulsadores, cuando se pulsaban con la cabeza, el usuario dejaba de ver lo que había en la pantalla y, además, se cansaban más".

  • "Metalingua: la Web 3.0 ya está aquí", ABC (28/04/09).

    Metalingua, un proyecto con el que sus creadores quieren romper las barreras lingüísticas en la Web a través de la traducción de cualquier fuente (ya sea texto, vídeo o audio) en un idioma determinado a cualquier otro.
    [...]
    La clave de Metalingua es que no trabaja con palabras sino con conceptos, de manera que, a diferencia de otras tecnologías, cuando se implementa un nuevo idioma no es necesario que sea traducido al resto de idiomas uno por uno, sino que el sistema se encarga de relacionar automáticamente la nueva lengua con las anteriores y con las que se integrarán después. Una de las aplicaciones más destacadas de esta tecnología es la búsqueda semántica y multi-idioma: un usuario que busque el término «perro» entendido como animal de compañía puede acceder tanto a las webs que contengan la palabra «perro» como a aquellas que incluyan «dog», «chien»/«chienne» o «hund»/«hündin», traducidas a su idioma materno.

    También cuenta con tecnología de reconocimiento de voz, sistemas de gestión de contenidos y servicios de traducción entre idiomas naturales y entre lenguaje humano y lenguaje informático: un usuario puede utilizar sus propias palabras para hacer una búsqueda en una base de datos aunque no conozca el complejo lenguaje con el que éstas funcionan. Todas estas características hacen de Multilingua un auténtico ejemplo de Web 3.0, una nueva generación de webs destinadas a convertir la Red en un espacio más humano y sencillo de utilizar.


    Web de Metalingua

Etiquetas:

Compártelo en:

Compartir


Share |

0 comentarios en el artículo "Noticias... (18)"