E-mail List Archives
Thread: RE: Comments on a checklist requested
Number of posts in this thread: 1 (In chronological order)
From: Ian.Lloyd@nationwide.co.uk
Date: Thu, Oct 24 2002 2:49AM
Subject: RE: Comments on a checklist requested
No previous message | No next message
-----BEGIN PGP SIGNED MESSAGE-----
********************************************************************
The contents of this email are intended exclusively for the
addressee. If you are not the addressee you must not read
use or disclose the email contents ; you should notify us
immediately [ by clicking "Reply" ] and delete this email.
Nationwide monitors e-mails to ensure its systems operate
effectively and to minimise the risk of viruses. Whilst it has
taken reasonable steps to scan this email, it does not
accept liability for any virus that may be contained in it.
********************************************************************
I've commented on your comments, Jukka. Thanks for your time!
Ian Lloyd, Electronic Channels
Nationwide Building Society
e-mail: = EMAIL ADDRESS REMOVED =
tel: 01793-655260
fax: 01793-656368
- -----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: 23 October 2002 12:31
To: = EMAIL ADDRESS REMOVED =
Subject: RE: Comments on a checklist requested
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.
- ------- I certainly considered this, buit thought that the quick tips were
too quick, too lacking in detail - had I just provided this I would have
bombarded with further questions: "So, what does this mean then Ian?" ;-)
> 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.
- --------- skill set is pretty high in terms of design/general html, but how
to make html accessible is lacking
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.
- --------- Sorry, but perhaps I have not used terminology correct. There does
need to be a description of the images here. I think the trype of image I
was referring to is what you describe in yor ntes as "an image with rich
content of its own"
> o Images as Links: alt="Go to home page"
Much better: alt="Foo Bar Inc. (main page)".
- ----------- Thanks, taken on board
> 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.
- ---------- I agree, I would prefer that approach, but I also know that
people sometimes need to be told to click here - that they need a call to
action. I am happy as long as the link does contain the essential info, but
I prefer without the Click here, personally!
> 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).
- ---------- Agreed. In a separate guideline on pop-up the first line in my
'General Rules' section reads: "The general rule of thumb is to avoid using
pop-ups wherever possible. A standard <a href=""> will always be better
because: " ... and then I go on to list the many reasons!
> 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:
- --------- Again, agreed - I mean that the noscript alternative should
contain either a few useful links to suggested further help, or that it
should notify the user what they're missing out on and why
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/
-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.1.1 (C) 1997 Pretty Good Privacy, Inc.
iQEVAwUBPbfASm4wJNdvwuyFAQGauQf+OYa24yTwW+VQsUV/GLCTXD5a67ymvJBa
hNLRYNSka+MU0iu/0hNyFt/YB/qTJu2oBEcN0wbCnzPyswyHAMwqgxWZmVVNzBIC
/bosp7yiT8bMQVcFtAGecaHMeURoY9hODczX8mALAQN6rxwIAYv9zuShKCGCUMnw
iX6xxXQ9KtAmFDnAxZLtfRG3YkRoiHbnzZq/E0Akp70wUoBBegeAFQDCQ+3pcr2+
ZUmqjrKw6EsXTOxxbVY5mPuopukToh2mLYsDTuqfH/KyINLCznsEAFX9aoeHecju
dL0phA8xpmxhvi7r0E+5sBiTMp9J94dHkaMlE9VFSIyt67EYdd1/SA==y0OU
-----END PGP SIGNATURE-----
----
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/