Design For Accessibility: Part
1 | Part 2
the second part of this extended two part guide,
Andrew Ward continues to guide the web designer
through the main issues surrounding web design accessibility.
Style sheets make life a lot easier for the html
author as well as the Web site visitor, so it’s
well worth going to the trouble of learning how
to use them. The full specifications are hosted
by the WorldWideWeb Consortium (http://www.w3.org).
Although the specifications appear complicated,
the principle of style sheets is simple enough,
and there are many tutorials available on the Web.
The above site is a good explanation of why style
sheets are to be preferred over other methods of
specifying typography, and especially over the use
of FONT FACE. Regrettably, many Web site authors
learn by example - simply by inspecting how other
sites have been written - and bad practices such
as FONTFACE are propagated very quickly by this
Within the style sheet specification, styles can
be specified in several ways, but by far the easiest
is to use a separate file. Just one file can then
specify the styles - font and background colours,
font styles, sizes and weights - for all the elements
such as titles, headings and body text, for all
pages on the Web site. So changing the appearance
of a Web site, perhaps by enlarging the body text
or changing the suggested font for headings, becomes
a matter of changing one line in one file. Each
html page needs to contain a declaration before
it can use a style sheet. Styles are specified within
the style sheet file itself, and then referenced
by adding the class attribute to html tags where
Style sheets solve several problems, but can still
be misused. In particular, font sizes may be specified
in pixels, point sizes and as percentages of the
base font size. Of these three methods, only the
third is sensible, because this allows the site
visitor to choose the font size that is suitable
for them - taking into account the size, quality
and resolution of the display, the browser version,
the operating system, the hardware platform and
any vision problems or preferences they may have.
Readability also depends on the colour scheme. Some
users may need to choose different combinations
of font and background colour, so unless there is
some compelling reason, authors should dictate the
colour of neither.
With many different display devices in use, as well
as personal preferences, the Web site designer should
not seek to impose any particular size or shape
of the content on the page, as well as the size
of type. Instead, pages should be fluid, so that
the content is rearranged to suit whatever size
and shape browser window the viewer is using.
To achieve this, tables or other formatting techniques
such as <div> that are used to lay out the
page should be specified in percentages rather than
in fixed pixel sizes. There are circumstances in
which this is undesirable: it’s normal for
news sites to display columns of news text as a
fixed size. Otherwise, when viewed at full screen
width on a very large screen they would be very
difficult to read.
In general, producing good quality Web pages necessitates
writing html code by hand. Web authoring tools do
not produce the best html, and do not give the author
sufficient freedom to ensure the best viewability.
Before doing anything else, the author has first
to decide what version of html to use. Like all
decisions this will be a compromise, but for most
purposes, xhtml 1.0 will be the best choice. This
has the advantage of being backwards compatible
with html 4.0 and earlier versions, but forwards
compatible with new types of Internet browsing device.
Full information on xhtml 1.0 can be found at http://www.w3.org/TR/xhtml1.
Broadly speaking, it is very similar to html 4.0
but with two additional requirements. All tag names
must be in lower case, and all tags must be terminated,
so a line break becomes <br></br> rather
than simply <br>.
One way to find the other differences between html
4.0 and xhtml 1.0 but without having to read the
entire specification is to pass a page through an
html validator. The best ones to use are at http://www.w3.org/QA/Tools/#validators.
Search the list and find the best tool for your
use. The W3C MarkUp Validator will highlight anything
in the page that doesn’t comply with the new
specification. However, before doing this it’s
necessary to change the document type declaration
at the beginning of the page to indicate to the
validator that it contains xhtml rather than html.
Many Web pages do not include a document type declaration
at all. Although these declarations were ignored
by earlier browser versions, some browsers today
- such as Internet Explorer 6.0 - will change their
behaviour according to the declaration. If a Web
page doesn’t include this declaration, it
may not display as intended. Another validator is
and has the added advantage that it will validate
an entire site, not just a single web page.
Fluid pages and relative font sizes also help improve
the accessibility of Web pages to users whose vision
may be impaired, or who may suffer from some other
disability that makes viewing Web pages difficult
by conventional means. The World Wide Web Consortium
has produced a set of guidelines for site designers
that help achieve accessibility for a wide range
of visitors, and these are published at http://www.w3.org/TR/WAI-WEBCONTENT.
Broadly speaking, the guidelines for accessibility
are simply good practice for Web site design, with
the addition of features that will help visitors
that are using text-to-speech converters, such as
providing proper alt and title attributes for image
tags. However, there is one particular area that
is more difficult, and that is the recommendation
that tables are avoided for page layout and only
used for tables of data.
Obviously, tables do provide a particularly convenient
way to produce pages that look nice. Without tables
it can be quite difficult to produce presentable
pages easily. The use of style sheets in conjunction
with the <div> tag does go some way to fulfilling
the role that tables play, and there’s some
useful guidance on how to use <div> at http://www.elementkjournals.com/wdv/0105/wdv0151.htm.
Unfortunately, however, most Web design tutorials
still rely heavily on the use of tables for positioning
and layout. Tables can still be used, and the resultant
pages will be usable by text-to-speech converters,
as long as the tables are laid out in such a way
that they would make sense if read out row by row.
An alternative is to produce two entirely different
sites, one for visual use and another that’s
either text-only, or is specifically suited to text-to-speech
converters, but obviously this is an impractically
large investment for most site designers. The documentation
on the W3C web site provides sufficient information
to include control over fine details such as image
placing and spacing.
An accessibility testing and rating system is provided
by the Center for Applied Special Technology (CAST),
Finally, it’s worth considering obtaining
a rating for a Web site. Content control technologies
generally default to refusing access to any sites
that haven’t been rated. In reality, very
few sites do have a rating, so it’s arguable
that no one could leave these settings at their
default values since the result would be an unusable
browser. However, it doesn’t hurt to include
a rating, as these are easily obtainable from http://www.icra.org.
Web site design has undergone many changes over
the last few years, and only recently have the tools
and technologies, as well as the necessary understanding,
been in place to allow good practice site design
for sites built from html pages and templates. Most
old advice should now be discarded, and sites today
should follow the latest standards and guidelines,
to facilitate access by the widest number of users,
both today and in the future.
Design For Accessibility: Part
1 | Part 2