HTML and CSS Reference
In-Depth Information
Videos must be provided with extended audio comments that fully describe the video content. Additionally, a
second version of video content must always be provided with audio descriptions to maximize accessibility. This also
holds for Flash audio-visual materials. Gaps of dialogue must be filled with extended audio descriptions using SMIL.
Video-only content, which is inaccessible to blind and some visually impaired people, must have an audio
alternative in a common audio format such as MP3. Video stream accessibility can be maximized with sign language
interpreters through a synchronized video whose display can be selected by the user.
Captions must be added for video contents that can be turned on and off upon request because they maximize
availability. Captions must provide information for the hearing impaired not only about the dialogue but also the
sound descriptions (unlike conventional subtitles).
Migrating from WCAG 1.0 to WCAG 2.0
Some projects require web site upgrade from WCAG 1.0 to WCAG 2.0. Several WCAG 1.0-compliant sites require little
or no changes at all to meet WCAG 2.0. WCAG 2.0 is based on WCAG 1.0; however, there are some differences in the
approach and requirements.
Sites that meet WCAG 1.0 partly fulfill WCAG 2.0 by default. The two versions of WCAG are compatible.
Consequently, it is possible to meet both WCAG 1.0 and WCAG 2.0 requirements at the same time. Because of the
advanced flexibility of the second version, however, a WCAG 2.0-compliant site does not automatically meet the
requirements of WCAG 1.0. Some WCAG 2.0 success criteria are very similar to WCAG 1.0 checkpoints. On the other
hand, there are WCAG 1.0 requirements that are not needed in WCAG 2.0. Some WCAG 2.0 requirements are more
specific than the related requirements in WCAG 1.0 [38].
WCAG 1.0 is technology-specific [39], while WCAG 2.0 applies to W3C and non-W3C technologies as long as they
provide accessibility [40].
WCAG 1.0 uses interim solutions (“until user agents. . .”), while WCAG 2.0 success criteria compliance assumes
user agent support.
In WCAG 1.0, JavaScript is considered a technology with accessibility problems [41]. In fact, JavaScript can be
accessible, depending on the application and functionality being used (which we'll discuss in more detail later).
Scripting techniques successfully tested with screen readers are considered in WCAG 2.0.
The major steps of migrating from WCAG 1.0 to 2.0 can be summarized as follows [42]:
1.
Conformance parameters should be determined.
2.
Applied technologies should be determined.
3.
The application potential of technical requirements should be analyzed.
4.
WCAG 1.0 checkpoints should be checked related to WCAG 2.0 requirements.
5.
WCAG 2.0 success criteria should be checked.
Finally, strange as it sounds, not everyone is enthused over the highest level of web accessibility. Although
WCAG 2.0 is very impressive from the accessibility point of view, it is criticized for many reasons. For example, the
specifications are very long and complex, the technology-neutral descriptions are rather difficult to implement for
developers, very special requirements are included (especially for AAA conformance, like the real-time caption
service), some definitions are difficult to understand, inaccessible page versions are tolerated when an accessible
version is present, testing is far too complex, and not all content can be written in a way that conforms to the strictest
requirements [43].
Search WWH ::
Custom Search