E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 1 (In chronological order)

From: Jukka Korpela
Date: Wed, Oct 23 2002 4:37AM
Subject: RE: Comments on a checklist requested
No previous message | No next message

Ian Lloyd wrote:

> I have put together an A4 sheet for people in my department
> as a quick guide to address accessibility issues

A good idea. Some people might say that we should use just W3C WAI
summaries, but IMHO they are not practical enough. But in any case the Quick
Tips at http://www.w3.org/WAI/References/QuickTips/ should be carefully
considered when preparing a quick guide.

> However, I'm just interested to see if you guys
> think I have got the priorites right?

Hard to tell - the priorities depend on the nature of the pages, the skill
set of authors, etc.

I'd like to make a more constructive contribution (like translating my own
"technical summary" of an accessibility guide in Finnish), but at this
moment I can only present some notes on your list:

> q Always include an alt attribute:

Fine, but...

> o Decorative images: alt="Decorative image: a boat on
> the water"

No!! Use alt="" here.

> o Images as Links: alt="Go to home page"

Much better: alt="Foo Bar Inc. (main page)".

> o Bullet points: alt="*"

Maybe, but alt="Item: " might be better.

For a lengthy discussion of alt attributes for different images, including
arguments for my suggestions above, see
http://www.cs.tut.fi/~jkorpela/html/alt.html

> o but you can use Click here for more information about tax
> assessment, for example

Why? What's wrong with "There is <a href="...">more information about tax
assessment</a> available"? Or, better still, "More information about tax
assessment:" followed by a link that uses the exact title of the linked
document.

> q Use the title attribute to further clarify nature of a
> link if this may be useful (optional):

Useful, but not very high in _accessibility_ tips.

> o Use <a href="file.htm"
> onClick="window.open('file.htm');return
> false;"> instead.

I would say: avoid popup windows, but if you use them, make sure the links
work without JavaScript, too (and then that example).

> o <table summary= "Layout table for display of
> product gallery">

There's been quite some discussion about summary attributes for layout
tables, with no consensus. Maybe this should be left out at this moment. You
could just suggest that tables should have summary attributes that explain
the structure of the table. (Some layout tables are actually structural in
_some_ sense that is relevant here.)

> q Understand the difference between layout tables and data tables

Not really a _quick_ tip.

> o Layout tables need less attention (do not need
> scope or header/id attributes)

I just fought with a page that I needed to print and that had a table with
fixed WIDTH attributes, so that it didn't fit into a normal paper. It
doesn't really matter that much whether the table is "tabular data" or
"layout table", if you have serious problems in making it adapt to the
available canvas width. Instead of general remarks on different types of
tables, I would recommend:
- avoid specifying column widths using fixed units like pixels

> q Always place the form text/label BEFORE the form element
>
> o except for radio buttons and checkboxes, where the
> text/label comes after

This would perhaps be better presented as a single rule, rather than an
absolute rule ("Always..:") followed by an exception. And "form element" is
ambiguous - it could be misread as referring to <form> element. Suggestion:
Please the label before the form field, except for radio buttons and
checkboxes, for which the reverse order is used.

> Frames
> q Don't use them!
>
> o But if you must use them, include a title attribute
> on the <frame> tag to describe the purpose of that frame

That can be useful (in principle at least), but more importantly: use frame
names that reflect the content and purpose, not positioning, e.g.
name="navigation" instead of name="left".

> o If no-frames version is not viable, provide any
> instructions about upgrading to a frames-capable browser

I would omit that. It would just be an encouragement to use pointless
<noframes> content.

> q Provide a <noscript> alternative

No, <noscript> is usually neither needed nor useful. Better advice:
- Ensure that the page is functional when client-side scripting is not
enabled. If this is not possible, include a clear statement that expresses
the situation, and put it inside a <noscript> element. Example:
<noscript><strong>This page contains only a JavaScript-based pocket
calculator. Your browser does not support JavaScript, or has the support
disabled.</strong>/noscript>
Some more ideas on this:
http://www.cs.tut.fi/~jkorpela/forms/javascript.html#limitations

--
Jukka Korpela, senior adviser
TIEKE Finnish Information Society Development Centre
http://www.tieke.fi/
Diffuse Business Guide to Web Accessibility and Design for All:
http://www.diffuse.org/accessibility.html


----
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/