Introduction
The World Wide Web Consortium (W3C)
is an international industry consortium jointly hosted by the MIT Laboratory
for Computer Science in the USA, the
National Institute for Research in Computer Science and Control in France,
and Keio University in Japan. There are approximately 450 member organizations
of the Consortium.
The W3C provides a number of services including a collection of World Wide
Web resources for developers and users, reference code examples to represent
and promote standards and various prototype and sample applications to
demonstrate the use of new technology.
The W3C are committed to the disabled and formed the Web Accessibility
Initiative (WAI) to promote Web accessibility. The WAI is pursuing accessibility
of the
Web through
five
primary areas of
work:
- addressing accessibility issues in the technology of the Web
- creating guidelines for browsers, authoring tools, and content creation
- developing
evaluation and validation tools for accessibility
- conducting education
and outreach
- tracking research and development.
There are two versions of the Web Content Accessibility Guidelines (WCAG). WCAG
1 contains 14 main guidelines with a total of 65 in all. WCAG
2, still in draft format, has reorganised and combined
many of the WCAG 1 guidelines to create
21 new ones.
Each guideline has a one or more ‘checkpoints’ which developers
should consider to ensure the accessibility of a Web page. Each checkpoint
has a priority level based on its impact on Web accessibility.
The WCAG provides a number of examples and techniques to help Web developers
to implement the guidelines. There is also a downloadable training course entitled
the Curriculum for the Web Content
Accessibility Guidelines 1.0. The course is a few years old and needs updating.
Saying that, it does provide a good foundation to the topic.
WCAG Priority Levels
There are 3 WCAG priority levels. Compliance with the recommendations
of each level ensures greater accessibility of Web pages.
Priority 1 - Web developers MUST satisfy these checkpoints or some groups
of people will find it impossible to access information on their site. This
is considered
to be the absolute minimum level of compliance.
Priority 2 - Web developers should satisfy these checkpoints or some groups
of people will find it difficult to access information on their site. This
is considered
to
be the preferred level of compliance.
Priority 3 - If Web developers satisfy these checkpoints the majority of
users will be able to access ALL of the information on their site. This is
considered to
be the
optimum level of compliance.
WCAG Conformance
The WCAG guidelines have three levels of conformance.
- Conformance Level "A": all Priority 1 checkpoints are satisfied.
This is known as 'WCAG A' compliant.
- Conformance Level "Double-A": all Priority 1 and 2 checkpoints
are satisfied. This is known as 'WCAG AA' compliant.
- Conformance Level "Triple-A": all Priority 1, 2, and 3 checkpoints
are satisfied. This is known as 'WCAG AAA' compliant.
There are 14 main WCAG guidelines as follows: -
1 - ‘Provide equivalent alternatives to auditory and visual
content.’
The aim is to provide content that, when presented to the user, conveys essentially
the same function or purpose as auditory or visual content. Although some
people cannot see images, movies, sounds, applets, etc. they may still use
pages that
include equivalent information to the visual or auditory content. The equivalent
information must serve the same purpose.
For example, each image should
also
include alternative text via the ALT attribute. Suppose the alt text for
a button says 'button'. This does not convey the purpose of the button. It
is much better to put 'link
to home page'
or something along these lines.
This guideline emphasizes the importance of providing text equivalents of
non-text content. The beauty of a text equivalent lies in the fact that it
can be rendered
in ways that are accessible to people with various disabilities using a variety
of assistive technologies. Text can be easily output to speech synthesizers
and Braille displays, and can be presented visually on computer displays
and paper.
Synthesized speech is critical for individuals who are blind and for many
people with the reading difficulties that often accompany cognitive disabilities,
learning
disabilities, and deafness.
Braille is essential for individuals who are both deaf and blind, as well
as many individuals whose only sensory disability is blindness.
Text displayed visually benefits users who are deaf as well as the majority
of Web users.
Non-text content such as video obviously benefits some users, especially
non-readers or people who have difficulty reading. In video or other visual
presentations,
visual
action
such
as body language or other visual cues may not be accompanied by enough audio
information to convey the same information. Unless verbal descriptions of
this visual information are provided, people who cannot see (or look at)
the visual
content will not be able to perceive it.
2 -
‘Don't rely on colour alone.’
It is vital to ensure that text and graphics are understandable when viewed
without colour. If colour alone is used to convey information, people who cannot
differentiate
between certain colours and users with devices that have non-colour or non-visual
displays will not receive the information. For example, 'Press the red
button' is not much use to someone with red-green colour blindness.
When foreground and background colours are too close to the same hue, they
may not provide sufficient contrast when viewed using monochrome displays
or by people
with different types of colour deficits.
It's quite a good idea to take a screen grab of a few random pages, open them
up in your graphics program, and convert them to grayscale.
3 -
‘Use mark-up and style sheets and do so properly.’
Documents must be structured correctly. Content should be presented using
style sheets rather than with presentation elements and attributes. Improper
use of mark-up hinders accessibility. It is much better to use <EM> and <STRONG>
tags rather tha <I> and <B>.
Misusing mark-up for a presentation effect, for example using a header to
change font size, makes it difficult for users with specialized software
to understand
the organization of a page.
Content developers must not sacrifice appropriate mark-up because a certain
browser or assistive technology does not process it correctly. For example,
it is appropriate
to use the TABLE element in HTML to mark up tabular information provided
that the table is coded correctly.
4 -
‘Clarify natural language usage.’
HTML allows developers to mark-up their documents in a way that facilitates
pronunciation or interpretation of abbreviated or foreign text. When
content developers mark
up natural language changes in a document, speech synthesizers and
Braille devices can automatically switch to the new language, making the document
more accessible
to multilingual users.
Content developers should identify the predominant natural language of a document's
content (through mark-up or HTTP headers). Content developers should also provide
explanations of abbreviations and acronyms.
In addition to helping assistive technologies, natural language mark-up allows
search engines to find key words and identify documents in a desired language.
Natural language mark-up also improves readability of the Web for all people,
including those with learning disabilities, cognitive disabilities, or people
who are deaf.
When abbreviations and natural language changes are not identified, they
may be indecipherable when machine-spoken or Brailled.
5 -
‘Create tables that transform gracefully.’
Tables often present problems to users of screen readers irrespective of
their purpose. It is important that tables are coded so that they linearise
correctly. A great way to check how pages look when linearised is to experiment
with the settings under "Page style", especially the "User mode",
in the Opera browser. Web designers can
unchecked "Tables" and
see if their Web pages transform gracefully when they are linearised.
Incidentally, Opera is currently only $39 but there is also a free version
which includes advertisments.
Tables should primarily be used to mark up tabular information although many
content developers use tables to lay out pages; this is a contentious issue.
6 -
‘Ensure that pages featuring new technologies transform gracefully.’
Designers should ensure that pages are accessible even when newer technologies
are not supported or are turned off. Although content developers are encouraged
to use new technologies that solve problems raised by existing technologies,
they should know how to make their pages still work with older browsers
and people who choose to turn off features.
7 -
‘Ensure user control of time-sensitive content changes.’
Developers should ensure that moving, blinking, scrolling, or auto-updating
objects or pages can be paused or stopped. The BLINK and MARQUEE elements
are not defined in any W3C HTML specification and should never be used.
Some people with cognitive or visual disabilities are unable to read moving
text quickly enough, or at all. Moreover, screen readers are unable to
read moving text.
Movement can also cause such a distraction that the rest of the page becomes
unreadable for people with cognitive disabilities.
People with physical disabilities might not be able to move quickly or
accurately enough to interact with moving objects.
8 - ‘
Ensure direct accessibility of embedded user interfaces.’
Embedded objects, including items such as Windows Media files or QuickTime
movies, are often presented within their own interface. These interfaces
must be accessible. If the interface of the embedded object cannot be
made accessible,
an alternative accessible solution must be provided.
9 -
‘
Design for device-independence.’
Developers should create pages that allow users access via a variety of input
devices.
Device-independence means that the user may interact with a Web site
with their preferred input or output device. Examples of such devices
include;
mouse,
keyboard, voice and head wand.
Generally, pages that allow keyboard access are also accessible through
other speech input devices.
10 -
‘
Use interim solutions.’
Pages should be constructed so that assistive technologies and older browsers
will operate correctly.
For example, older screen readers read lists of consecutive links as
one long link. These active elements are therefore difficult or impossible
to access
unless
the links are separated by something other than white space, for example
a transparent gif.
Again, this is a contentious issue. How old is an old browser? Many developers
design for version 4 browsers and above. Some designers totally ignore version
4 browsers.
I guess it depends to a certain extent on your target market.
11 -
‘Use W3C technologies and guidelines.’
Web sites should be constructed using W3C technologies and guidelines. When
this is not possible, or doing so results in material that does not
transform gracefully, an alternative accessible version of the content should
be
provided.
Many non-W3C formats (e.g., PDF, Shockwave, etc.) require viewing with
either plug-ins or stand-alone applications. Often, these formats
cannot be viewed
or navigated with standard Web access or screen reading tools.
Non-W3C formats should be converted to HTML/XHTML although this does not
always create an
accessible document. Each page should be validated for
accessibility and usability
after the conversion process.
Avoiding non-W3C and non-standard features (proprietary elements,
attributes, properties, and extensions) will tend to make pages
more accessible
to more people using a wider variety of hardware and software.
When proprietary
or
inaccessible technologies must be used, equivalent accessible
pages must be provided. Even when W3C technologies are used, they must be used
in accordance with accessibility guidelines.
If a page does not easily convert, developers should either
revise the page until its original content converts
properly
or provide
an HTML
or plain text version.
12 - ‘
Provide context and orientation information.’
Complex relationships between different parts of a page may be difficult
for people with cognitive disabilities and people with visual disabilities
to understand.
Therefore, developers should provide context and orientation information to
help users understand complex pages. This information is useful for all users.
For example, each form element should include a label which make it obvious
that it corresponds to a particular element. If you use frames make sure that
each frame is titled correctly.
13 -
‘
Provide clear navigation mechanisms.’
Clear and consistent navigation systems are important to people with cognitive
disabilities or blindness, and benefit all users. Developers should provide
a clear and consistent navigation system. This will ensure that users will
be able to find the information they are seeking easily.
14 - ‘
Ensure that documents are clear and simple.’
Consistent page layout, recognizable graphics, and easy to understand language
benefits all users. In particular, they help people with cognitive disabilities
or those who have difficulty reading. It is important to ensure that
images have text equivalents for people who are blind or have low vision, and
for any user who cannot or has chosen not to view graphics.
Using clear and simple language promotes effective communication and is
particularly important for those users whose first language is not
the language of the Web page.
Conclusion
The WCAG guidelines can seem overwhelming, confusing and sometimes contradictory.
Learning to create accessible web pages can be difficult and time consuming
but the benefits to potentially millions of people are well worth it. I believe
that anyone with even a basic understanding of (X)HTML can learn and apply
accessibility principles and concepts. To this end I will be looking at each
of the WCAG guidelines in future articles. |
