[Catalyst] C::C::FB and captchas or similar

[Octavian Rasnita]

>
> Hmmm... I haven't been focusing on this, but it is worth a read.  I am
> working on making the pages as simple as possible (no AJAXian-ness) for
> a combination of aesthetic and personal time reasons.  Any pointers to
> document design elements to encourage accessibility you can provide
> would be appreciated.

Hi,

The most important things that come to my mind, are the following:
1. All the relevant images should use an alt attribute. A relevant image is 
one that is a label for a link, or a photo that could be saved by the 
visitors, but not a one-pixel image. The images that are not important, 
should use alt="".

2. Dupplicate links, one after another, should be avoided. I have seen many 
cases where an image icon is followed by a text, and each of them are a 
separate link to the same page.

3. If you need to use captcha, specify in the alt attribute of the image, 
something like "If you can't see this image, you can do the following thing 
to access the page..."... because otherwise the blind users won't understand 
that they need to enter a text from an image, and they might submit that 
form for more times, without success. Of course, an alternative way of 
access should be offered.

4. If you present the data like a table, use an html table, and not 
preformatted text. Also, use a "normal" table layout and not 2 parallel 
tables that don't have any relation between them, but only visual.
Also, the first column and the first row of the table should contain data 
and not graphics that makes the table more nice, because the cells from 
those rows are spoken as row and column heads.
For more complicated tables, that contain column or row headers which span 
on more lines or columns, and have sub-headers, there are some rules for 
naming those headers, in order to associate those headers with the cells of 
the table, but I don't remember those rules. I think they can be found on 
w3c.org.

5. A very helpful thing is to begin the content of the page with a heading. 
It is much useful than putting a link at the top of the page with "skip" 
navigation" or "skip to content".
The blind users can jump directly to that heading, with a single hotkey. If 
the page have more other headings, it is also very helpful.

6. Some sites offer a "skip to contents" link, which is invisible, and it is 
put at the top of the page.
It is a one-pixel image link with a "Skip to content" alt attribute, that 
points to the beginning of the page content. Without it and without a 
heading for jumping directly to the important content, the users need to 
read all the navigation links in every page, one by one.

7. If possible, don't use Javascript at all.
If you need to use Javascript for validating a form, it is very ok, but use 
it in such a way that if the browser doesn't support Javascript, the form 
should also work.
So, don't put the onSubmit() event to send the form. Use onSubmit() just for 
validating, and return an alert if the form was not filled correctly, but 
return true and allow the form to be submitted in the standard 
non-javascript way.
(This is not a recommendation regarding the accessibility for the blind 
especially).

If you need to use Javascript that create menus, make sure that the menus 
are also accessible when the browser doesn't support Javascript. I have seen 
a menu made in Javascript that creates a list with sub-lists with links, and 
without Javascript, that list of lists is shown, and the screen readers sees 
it like a common list with links that can be accessed. The Javascript code 
just formats it and shows it like a menu.
Other menus are not accessible absolutely at all.
I have seen other menus made with Javascript that present a list of links, 
that could be clicked by the blind users, then the page is re-loaded, and a 
sub-list of links appears for that list element that was clicked, but it is 
not as friendly as the first one I've told about.

Don't use Javascript in the href=".." attribute of links. Use it in the 
onClick() event of that link instead if necessary.
If using it in the href attribute, that link cannot be opened in another 
window with shift+Enter (or right click, open in new window), and some blind 
users prefer this method, because after reading the opened page, they can 
close the window and return to the previous window, and the focus remains on 
the link that opened the window, so the users don't need to find that point 
again.
This way the search engines will also index the page targetted unlike when 
using javascript-based links.

8. Don't use href="#" and then use an onClick() event that open the page, 
possibly in another window.
Those links cannot be open in a new window if the visitor choose that, and 
they cannot avoid opening a new window if they want to not have a new 
window.

9. Even if opening a new window, don't hide the menus and the address bar.

10. Don't use Javascript to write something in the status bar. That text 
never helps, but it doesn't let the browser inform the user when the page 
has finished loading.

11. When presenting lists, use html lists, and not a simple list of bullet 
chars followed by a text. The screen readers inform the users about the 
number of the list elements, offer the possibility to jump at the end or 
beginning of the list, or jump to the next element in list...

12. Don't use labels for links that can be understood only in context.
So don't use "click here" or "here" links because if the user will jump from 
a link to another, only that text will be heared, or maybe his screen reader 
will make a list of links, and it could be pretty difficult to go to the 
page and see what is the link "click here" for.

13. Don't make an alternative page for the blind users, because most of them 
won't visit that page. That kind of pages are usually not updated, and 
that's why they don't visit those pages.
A site map could be helpful though, if it contains direct links to all the 
web pages from the site.

14. The pages with frames are accessible, but it is a good idea to avoid 
using frames.

15. Using css positioning is nice and recommended, but if the position of 
the elements on the page is in a different order than the order of those 
elements in the html code, it could make the web page structure pretty hard 
to understand.
For example, the user might move the virtual cursor at the top of the page, 
and when pressing tab it will land on a certain link, but if he will press 
the down arrow, the cursor might be on another element.
Unfortunately this is the main "advantage" of css, but the screen readers 
are not very good for working with this type of pages...

16. If using Flash annimations, there are some accessibility recommendations 
on the Macromedia web page, but they are not extraordinary accessible 
anyway, so Flash should be avoided, or the content should be presented as 
common html also.

17. When inserting direct links to .doc or .pdf files, specify this in the 
title of the link, like [pdf] or [doc] for letting the users know what type 
of link is that.
Those files are accessible for screen readers, but not when they are loaded 
with the browser plugin, and most of the times, if they are loaded in the 
browser, the computer freezes for a while, and it is not nice at all.

18. When using forms, don't use Javascript to automaticly send them when 
something changes in the form, for example when the user changed the active 
element in a combo box.
The blind must select with the keyboard all the combo box elements one by 
one, or jump to the wanted one if they know the start letter, and if the 
form is submitted automaticly, it is send after the first element chosen.
Also, those forms that get submitted after selecting something in a combo 
for inserting other elements in another combo, is not nice at all.
If the javascript code contain all the necessary elements and fill all the 
combos without needing to send the form for more times, it is more easy to 
use.

19. Use standard forms, and not forms that are created by Javascript, 
because most of them are not accessible for the blind.
For example, those Javascript programs like HTMLArea that can be used to 
format a text in a form are not accessible at all.
Not to mention that the html code created by that kind of programs is 
horrible, doesn't respect W3C recommendations, but it is not valid html at 
all.

20. Don't force the refresh of the page, without allowing the user to choose 
if he wants this or not.
After each refresh, the focus goes at the top of the page, and the user must 
go down and find the last position he was when reading that page.

I think these are the most important things, and I hope I didn't forget 
some.


Octavian