accesskey _ mod _ content

Images, multimedia and CAPTCHA

For each complex should provide a detailed description in a separate HTML document or in the same on it.

HTML 4.01 or XHTML l a URL of this detailed description will be indicated in the attribute longdesc the image. In Addition, and to ensure maximum compatibility, it can provide text link below the image, linking it up at the beginning of the detailed description. Even so, there is still a need for each image offer an alternative text in the attribute alt briefly identify the type of information transmitted through it.

Code example

Text identifying the complex image

Description of [name of the image]

In contrast, HTML5 longdesc attribute is considered as obsolete. In this case, how to include a detailed description is including the description in the same page or in a separate page connected to a formal link located next to the image.

As decorative image means anyone who does not convey any relevant information and does not possess any functionality. Thinking of a specific Web page, this would mean that the lack of these images are not lost any information.

As decorative image we can understand, which are all those that are complementary in any way the information displayed and/or transmits information for themselves. In Addition, the images are not considered functional decorative (links, banners, etc.)

A video element to be accessible to fulfil the following points:

  • Possess an accessible alternative: For any element of video is necessary to provide an equivalent for the band both visual and aural, i.e., a full transcript of all the information transmitted in the video. Moreover, this alternative should be found in an accessible format.
  • Synchronize equivalent alternative video: Whether or not the multimedia presentations with textual equivalent, should provide an equivalent synchronized (subtitles) of the soundtrack.
  • Provide a description of the important information of the visual track: When you convey important information in the visual band of the video, it is necessary to include a description of the scene (also called Audiodescripción).
  • Light, and appropriate blinks: We must avoid the contents of the elements of video and produce blinks flashes.
  • Playback Control: It was also important to provide the elements of video, a mechanism which allows users to control the reproduction of these (progress, pause, etc.). In Addition, this mechanism, should be able to handle from any kind of device (keyboard, mouse, etc.)

In case the multimedia content in real time the only requirement is that it provide subtitles in real time, in addition to prevent the occurrence of light, and flashes. It is not necessary to provide a complete transcript or textual description sonora. Even so, to facilitate access to such content is recommended to provide a posteriori a version with all necessary measures relating to accessibility.

For more information on videos available on the “ accessibility guide for Multimedia Content ” available in the section .

Any object Flash must be designed on the basis of the common standards of accessibility: appropriate use of color, independence, coherent navigation device, plain language, control of detection of the movement of non-use of light, and in general, the elements contained in the WCAG that may be applied on the interface and functionality of this kind of content. They should be used techniques and tools such as the panel of accessibility (incorporated since version 6.0 and improved in the successive versions) of the development of Adobe Flash. The elements of interaction of the object must allow an orderly tab (in line with the provision on the screen) and any important information on the subject should be interpreted appropriately by a screen reader.

At the same time, and because not all user agents will be made to complete this type of object (for compatibility with MSAA engine ( Microsoft Active Accessibility ), should be provided an equivalent in (x) HTML + CSS. This alternative should be included between tags OBJECT the Flash, and complementarily context in the document itself (with the object but independent of This) or a link to a separate document.

If the object is purely decorative Flash (does not offer the textual information, offer functionality and not only been used as an accompaniment visual) it is not necessary to provide alternative at the same.

Regardless of whether the Flash object decorative is or has an accessible alternative, it must not interfere or make access to the rest of the contents of the page to persons with disabilities. Well, you will not be able to strike that might lead to attacks on people with epilepsy fotosensitiva, may not block or interrumplir keyboard navigation for all other content and you must have mechanisms to control the playback of audio and pause or stop the movements and animations.

Finally, to embed a Flash element in a separate, it is advisable to use a code (X) HTML grammars valid according to published by W3C: it is common to the use of attributes and elements desaconsejados as EMBED , generated by the very development tool. Instead, a code should be used equally functional and tolerant W3C grammars.

Code example






The evolution of techniques CAPTCHA has revealed the traditional solutions, such as the characters in images, not only are insecure, but also hinder the interaction with people with disabilities. At present, recent developments such as Google reCAPTCHA, multi-device and systems of russian identities constitute the best way to distinguish a human or a machine.

However, although there are some solutions CAPTCHA better than others, there is still the ideal solution. What is important is that the CAPTCHA placed on the website will be able to correctly identify persons with disabilities as rights.

The working group Accessible Platform Architectures (APA ) (Opens in new window) in cooperation with the Research Questions Task Force (RQTF) (Opens in new window) , developed the draft " Inaccessibility of CAPTCHA (Opens in new window) ". This publication dates from 2005, although it is constantly being revised with a view to reflect the latest technological changes in the area.

In this document analyses the different approaches of existing CAPTCHA, together with their accessibility barriers associated. Also included references to the latest research on this subject, in addition to addressing the systems of russian identities, dual-factor authentication, biometrics 3D CAPTCHA, etc.

This document helps to implement the requirements set out in the approach in accordance 1.1.1 Textual content of the WCAG 2.0 and 2.1.