WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Question about guideline 31 for Accessible and UsableWeb Sites

for

From: Jukka K. Korpela
Date: Apr 13, 2006 5:30AM

On Thu, 13 Apr 2006, John S. Britsios wrote:

> The guideline 31 "Do not exclude labels form fields" for Accessible and
> Usable Web Sites found here
> http://redish.net/content/papers/interactions.html

The guideline seems to be "Do not exclude labels from fields", i.e. with
"from", not "form". It still isn't clear what this guidelines is supposed
to say and what the status of the guidelines is - the opinions of two
persons? I guess the guideline is meant to say "Use a label for each
field" but it wants to put this negatively, for some reason.

(The page has no left margin, and it has far too small font size, so that
small print is far too small even if I set IE to use the "Largest" font
size. The page also uses a fixed-width table to create a fixed line length
for its content. Hence, it demonstrates poor accessibility.)

> mentions that "When filling out a field makes the page refresh, the software
> starts reading from the top as if it were a new a page.... That is a time
> saver
> for sighted users, but is made the page refresh so that the screen reader
> started over at the top of the page".

That's a point worth noting if you intend to create refresh effects via
client-side scripting. But it's numbered as "16." under Guideline 31, and
it does not appear to relate to that guideline in any way. The document
appears to be somewhat confused, and confusing.

> We added a title to the "Submit" button "Page will reload!", and using a
> server-side solution, we managed that when the user clicks there, the page
> reloads, and the
> user will be go back to the same place he/she have been, and he/she can view
> or hear the success or error message.

A normal submit button needs no such warning, since a submit button is
supposed to submit data and cause some response to be sent. Actually, any
warning about a quite normal phenomenon tends to confuse people, not help
them.

If a button causes a page to be reloaded, it should not be called a submit
button.

In the case discussed in the document, the page is presumable refreshed
automatically as the user has filled in a ZIP code, without pressing any
button. Then there is a problem, but I cannot see why page refresh would
be required when the page can simply modify the contents of some fields.

> What is your opinion about that solution? Feel free to test that on our web
> site here: http://www.webnauts.net (Training Academy or Newsletter).

First, drop the default content "here" from the input box for E-mail
address. It helps no one, and it's an inconvenience. Any default content
in a field should be potentially helpful in the sense that users may wish
to _use_ it.

Second, "Page will reload!" is not helpful. The real problem here is that
submitting the form will not result in a normal response page, confirming
the subscription or issuing an error message. Instead, the response is an
entire page, containing the relevant information in a small area.
Effectively, this means simulating frames, which is as a bad as (or
sometimes worse than) using "real" frames.

The real problem is that the user has difficulties in noticing and
recognizing the response. Warnings won't help much; they may even add to
the confusion. Just make the server send a simple response page, with a
link to the main page.

> Also, if this is an appropriate solution, would it be necessary to add a
> notice before the "Submit" button, that the page will reload? Or add an alt
> tag on the button?

There is no alt tag, and the meaning of the alt _attribute_ is to specify
the textual alternative for an image.

--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/