W3C home > Mailing lists > Public > w3c-wai-eo@w3.org > July to September 1998

Re: 1st draft of reference card

From: Geoff Freed <Geoff_Freed@wgbh.org>
Date: 30 Jul 1998 16:17:01 -0400
Message-ID: <n1310306503.92245@wgbh.org>
To: "Stella O'Brien" <smo-brien@lioness.demon.co.uk>, w3c-wai-eo@w3.org
        Reply to:   RE>1st draft of reference card

I think this looks good.  I have a few suggestions.  I'll quote the original text; my suggestions follow GF:

>Make the graphics on your pages accessible. Use the alt part of the <img
>src> tag, and write a concise description of five words or less. 

GF:  I'd leave out the five-word limit, since someone might take this as a browser limitation.   Instead say something like, "...write a concise description of a few words or a short sentence...," which offers more flexibility.

>Similarly, if you wanted to provide more
>details about John's birthday cake, and tell people about the team colours
>selected for the icing etc. then use "rel" to link your image and d-link, and
>use d-link as follows.

GF:  In the GL group, there's a l-o-n-g debate raging about LONGDESC vs the d-link.  Before recommending the d-link, I'd review the guidelines and arguments for both (available at w3.org/wai/gl).  Personally, I think both should be supported, since pre-5.0 browsers won't handle LONGDESC.

>It is more informative and useful to write
>Code
>If you have any comments <a href="mailto:admin1@business.com">send
>email to John</a>
>end Code
>for which the link reads "send email to John".

GF:  Actually, it's best to include the e-mail address *in* the link itself, like this:

Code
If you have any comments <a href="mailto:admin1@business.com">send
email to John at admin1@business.com</a>
end Code
for which the link reads "send email to John at admin1@business.com".
end code

This way a person with a screen reader can just cut and paste the e-mail address into their own familiar form, rather than have to navigate through the somewhat unfriendly IE or Netscape mail form.  You can still click on the link to send mail if you want to, of course.

Geoff Freed
Project Manager, Web Access Project
CPB/WGBH National Center for Accessible Media
WGBH Educational Foundation
geoff_freed@wgbh.org

--------------------------------------
Date: 7/30/98 3:00 PM
To: Geoff Freed
From: Stella O'Brien
There will probably be some problems with the formatting. To facilitate
navigation for this text version the main headings are numbered and appear
as follows so if you use the number and first letter  you should be able to
move through the sections:

1 Use meaningful alt text for pictures
2 Use alt text with applets
3 Provide keyboard shortcuts
4 Make text easy to read
5 Provide easy navigation and links
6 Using frames and tables
7 Get more information

I have used the words Code and end Code (in both cases Code has an
upper-case initial C) to mark out the areas of html examples so these can
be largely ignored if you wish.

Quick Reference for Accessible Web Pages

It is easy and cost effective to make your web site universally accessible.
You have valuable information to share about yourself or your
organisation. Why fail to reach interested customers when a few simple
tips can make your site so much faster and easier to use for people with
portable web devices, anyone with low bandwidth, or disabled users? You
don't need to know anything about telecoms or the extra hardware and
software that some disabled people use. Just make sure
your web site communicates effectively even with the graphics,
sounds, and moving images, turned off.

1 Use meaningful alt text for pictures

Make the graphics on your pages accessible. Use the alt part of the <img
src> tag, and write a concise description of five words or less. alt is used
like this:

Code
<img src="cake.gif" alt="John's football-shaped birthday cake">
end Code

A version which does this

Code
<img src="cake.gif" alt="photo">
end Code

is accurate, but it's useless to anyone who can't see the photo.

If you need to present important information in the form of a diagram,
graph, pie chart etc., then remember that these can not be seen by some
users. The complexity of this information might mean that you need
to provide a longer description as a suitable alternative, and this would
not fit comfortably in an alt tag. Similarly, if you wanted to provide more
details about John's birthday cake, and tell people about the team colours
selected for the icing etc. then use "rel" to link your image and d-link, and
use d-link as follows.

Code
<img src="cake.gif" alt="John's football-shaped birthday cake">
<a href="cake.html" rel=next title="Description of John's birthday cake">D</a>
end Code

Selecting D takes the user to the fuller description. At the end of the
description provide a Return link to take the user back to the image.

2 Use alt text with applets

Some browsers don't support Java applets. Some users switch off Java and
plug-ins to speed up download times or to avoid security risks. So, it
is important to use alt tags if you use Java or plug-ins.

Code
<applet code=plantfood alt="[Animation of results is
unavailable]">
end Code

The text in the applet alt will be displayed  in Java-enabled browsers if
users have Java turned off. Browers which don't support Java will ignore
any <applet> tags, and their users won't know that there is anything there.
You can fix this by providing a quick explanation and description as text
within the <applet tag>.

Code
<applet code=plantfood.class alt="[Animation of results is
unavailable]">If your browser could handle applets, you could watch a
patch of tiny seedlings grow into beautiful, strong, flowers with the aid of
our plant food while a neighbouring patch receives no food and has a less
spectacular display.
</applet>
end Code

If an applet gathers information for a database then the author needs to
provide alternative ways for the user to provide information such as a
form or contact details.

3 Provide keyboard shortcuts

Not everybody can use a mouse or tracker ball. Many people find it faster
to tab between form fields than to select each one by mouse. Make it
possible to tab up, down and across the screen, using directional
arrows,'enter', and other keys to control the cursor. Some people can not
use your forms or database, so always include an email address and
further contact information for users.

Not everybody can see your imagemap. Even if an imagemap is well-
designed and beautiful to look at, many people find it quicker to follow
the links with keyboard shortcuts rather than clicking on specific regions
of it. Depending on the number of links, the user-friendly author can
provide
a) alt text in the area tags;
b) a list of text links just below the image; or
c) a link to a full list of links which is
arranged in an alphabetical, or easily understable way.

Code
<img src="welcome.gif" alt="Library resources list"
usemap="#map1">
<map name="map1"> <area shape="rect" coords="0,0,30,30"
href="reference.html" alt="Reference">
<area shape="rect" coords="34,34,100,100" href="media.html"
alt="Audio Visual Lab"></map>
end Code

4 Make text easy to read

Be clear in what you say and how you say it. Even for sighted people with
big screens, it takes longer to read online text than print. Users scan text,
picking out keywords and sentences and ignoring those areas which do
not interest them. Many users detest long, scrolling pages; they want the
text to be clear, short, and relevant. Provide summaries so that users know
if they want to follow links or to read a document in greater detail.

It is harder for blind users or people with small display screens to scan for
interesting material.  The author can help by using proper HTML markup
to emphasise the structure of the page. Use <H1> for the top level
heading; <H2> for the titles of the main body of text; <H3> and beyond
for finer divisions of information. Use list tags to create lists and bullet
points.

Complex background images and colours obscure text and make it
difficult to read. So do poor colour contrasts; white text on a pale grey
background is difficult to read and to print.

Some people need large fonts or a zoom facility to read a page more
comfortably. Use relative sizing and positioning (e.g. a percentage of the
default size) rather than absolute sizes or positions (e.g, pixels or points)
for both fonts and graphics.

5 Provide easy navigation and links

Knowing that a navigation icon is a button link can not help the user to do
anything useful without further information as to what it does.
For example

Code
<img src="pen.gif" alt="button">
<img src="openbook.gif" alt="button">
end Code

just tells the user that there is a button. If you tell the user what the
button
is for, then the link is meaningful.

Code
<img src="pen.gif" alt="signup">
<img src="openbook.gif" alt="place an order">
end Code

Some authors write unhelpful text links such as

Code
<a href="x">this</a>
<a href="y">Click here</a>
end Code

which read as "this" or "click here" and do not make sense out of context or
when scanning quickly. Use meaningful link phrases: as a poor example

Code
If you have any comments you can email us by clicking <a
href="mailto:admin1@business.com">here</a>
end Code

gives the link "here". It is more informative and useful to write

Code
If you have any comments <a href="mailto:admin1@business.com">send
email to John</a>
end Code

for which the link reads "send email to John".

6 Using frames and tables

Frames are difficult to design, navigate, or print effectively. Use frames
sparingly, and only if you understand them very well, but otherwise
don't. The source of a frame should always be an HTML file. If an image
file is
the source then there is  no means to attach alt text or other useful
alternatives which some users will need.  Provide and regularly update a
<noframes> option for browsers that do not support frames.

Provide a title for each frame so that it is easier to understand the contents
or purpose of each one.

Code
<frame src="nav.html" title="Navigation bar">
end Code

Bookmarking frames can be a problem. Keep the URL's correct by using
target in your link.
For example

Code
<a href=foo.html target="_top">
end Code

forces the browser to replace the entire window with a new frameset, not
just the currently selected frame. This reload means that the URL is
now correct and that navigation actions behave appropriately.

Do not use tables to manipulate page layout or to create multiple columns
because these will not make sense when displayed in some browsers, or
when interpreted by screen readers used by blind people or dyslexics.

Use tables for data. If the tables are complex then you will need to provide
a link to an accessible page where the data are presented in a linear
manner, and which is updated every time there is a modification to the
data on the inaccessible page.

7 Get more information

For updated versions of this tipsheet visit XXX. For more detailed
guidelines, fuller examples, and other useful techniques see XXX.












Best wishes - Stella



------------------ RFC822 Header Follows ------------------
Received: by wgbh.org with ADMIN;30 Jul 1998 14:58:44 -0400
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id OAA04834;
	Thu, 30 Jul 1998 14:52:36 -0400 (EDT)
Resent-Date: Thu, 30 Jul 1998 14:52:36 -0400 (EDT)
Resent-Message-Id: <199807301852.OAA04834@www19.w3.org>
X-Authentication-Warning: www10.w3.org: Host post-20.mail.demon.net [194.217.242.27] claimed to be post.mail.demon.net
X-Sender: lioness@pop3.demon.co.uk
Message-Id: <l03130302b1e667f9e5ea@[158.152.28.240]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 30 Jul 1998 19:50:04 +0000
To: w3c-wai-eo@w3.org
From: "Stella O'Brien" <smo-brien@lioness.demon.co.uk>
Subject: 1st draft of reference card
Resent-From: w3c-wai-eo@w3.org
X-Mailing-List: <w3c-wai-eo@w3.org> archive/latest/73
X-Loop: w3c-wai-eo@w3.org
Sender: w3c-wai-eo-request@w3.org
Resent-Sender: w3c-wai-eo-request@w3.org
Precedence: list
Received on Thursday, 30 July 1998 16:21:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 10:33:24 GMT