Accessbility Standards & Tips
November 6, 2008
There are couple of accessibility tips and standards, I’ll be talking about today. This will help make your website of application accessibile to people with disability also.
Rule #1: Always use a DOCTYPE
This is a general W3c standards for any HTML or XHTML markup to have a DOCTYPE, to know which version of document you are using.
Rule #2: Always mention the language: You know what language you’re writing in, so tell your readers… and their software.
Screen reader software (JAWS) needs to know what language your pages are written in, so it can pronounce your words properly when it reads them aloud. If you don’t identify your language, JAWS will try to guess what language you’re using, and it can guess incorrectly, especially if you quote source code or include other non-language content in your pages.
How to do it?
- If you’re using any variant of
HTML 4, change your<html>tag to this (use your own language code if not English):
<html lang="en"> - If you’re using any variant of
XHTML 1.0, change your<html>tag to this (use your language code in both places):
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"> - If you’re using
XHTML 1.1, change your<html>tag to this (again, insert your own language code):
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
Like the DOCTYPE, you should identify your language on every page of your web site.
Rule #3: Construct meaningful page titles
Every page of your web site should have a unique and meaningful page title.
JAWS has a special keyboard shortcut (INSERT + F10) which displays (and reads) a list of the currently open windows, by window title. In the case of web pages, this would be your page title. It also reads the window title while ALT-TABbing through open windows. Other screen readers, like Home Page Reader, read the page title out load as soon as you visit the page.
Lynx displays the page title in the first line of output, so it’s always the first thing that Blind users reads in Braille.
Rule #4: Provide additional navigation aids
You may be familiar with the tag in relation to external stylesheets. But did you know you can also use a similar syntax to point to your home page, and to previous and next pages in a series?
<link rel=”home” title=”Home” href=”http://url/of/home/page” />
<link rel=”prev” title=”Title of previous page” href=”http://url/of/previous/page” />
<link rel=”next” title=”Title of next page” href=”http://url/of/next/page” />
These links, normally invisible to visual browsers like Internet Explorer, can be displayed in alternate browsers and help users navigate through your web site.
Rule #5: Present your main content first
One of the main advantages of using a purely CSS-based layout is that it is easy to rearrange elements within your HTML source without affecting the visual layout, so that your main content displays while the rest of the page is still loading.
If you have a table-based layout with a navigation bar along the left, your navigation bar is being presented to blind users before your main content and this creates lot of problem.
Rule #6: Use colour safely
Rule #7: Use real links
Avoid JavaScript a pseudo-link that executes a piece of Javascript code when you click on it, to create links. Tool like Lynx does not support Javascript.
Rule #8: Add titles to links
The title of a link generally shows up as a tooltip in visual browsers, but it can be presented in non-visual browsers as well.
Rule #9: Define keyboard shortcuts
One of the least known features of HTML is the accesskey attribute for links and forms, which allows the web designer to define keyboard shortcuts for frequently-used links or form fields.
When JAWS reads a link that defines an accesskey, it announces the access key as well. For example, the link Home page would be read by JAWS as “link: Home page, ALT + 1″. Disbaled user can focus on the link by pressing ALT+1, then follow it by pressing ENTER.
Rule #10: Dont open links in new window
In all dominant browsers, using the tag to force a link to open in a new window breaks the Back button. The new window does not retain the browser history of the previous window, so the “Back” button is disabled.
Although JAWS does announce “New browser window” when a link opens a new window, this is easy to miss, as it is spoken wedged between the reading of the link text and reading of the new page. Home Page Reader has a better solution; it plays a distinctive sound every time a new window opens. And Window Eyes, another popular screen reader, gives no indication of new windows at all.
Rule #11: You should define an acronym whenever you use it
CSS, HTML
Rule #12: Use captions for your tables
Rule #13: Use Table headers for tables
<th>Quality</th>
</tr>
</thead>
Rule #14: Provide summary for table.
<table border=”0″ cellspacing=”4″ cellpadding=”0″ summary=”Monthly calendar with links to each day’s posts”>
Rule #15: Provide text equivalent for images.
Every single image on every single page of your site should have a text equivalent, so-called “alt text”, specified in the alt attribute of the <img> tag.
Rule #16: Provide text equivalent for images maps.
<img alt="Site navigation links" src="footer.gif" width="500" height="212" usemap="#Map"><map name="Map">
<area alt="previously..." shape="rect" coords="203,114,258,129" href="/archives.html"><area alt="by category" shape="rect" coords="277,113,348,129" href="/category/"><area alt="about the site" shape="rect" coords="364,113,401,128" href="links.html">
<area alt="about leslie" shape="rect" coords="418,114,488,130" href="leslie.html">
<area alt="Powered by Movable Type" shape="rect" coords="-4,190,131,210" href="http://www.moveabletype.org"></map>
Rule #17: Use relative font sizes
Rule #18: Use real headers for headings
Mark up your web site as an outline, using real
<div>
<h1>,</p>
<h2>,</p>
<h3>tags. Screen readers rely on these tags to interpret the structure of your pages. Your pages do have a structure, but without proper header tags, screen readers can’t find it.</h3>
</h2>
</h1>
</div>
<h1>
<h2>
<h3>
Rule #19: Label form elements
The <label> tag allows you to associate a form label with any kind of form input element: text box, multi-line text area, checkbox, radio button, whatever. This allows screen readers to intelligently announce what a particular input element is, by reading the label. Furthermore, if you use a <label> tag to associate a checkbox (<input type="checkbox">) with the text next to it, your web-based form will work like a GUI application: clicking anywhere on the text label will toggle the checkbox.
<input id=”author” name=”author” /><br /><br />
<label for=”email”>Email Address:</label><br />
<input id=”email” name=”email” /><br /><br />
Rule #20: Make everything Searchable
Entry Filed under: Web Standards. Tags: Accessibility, Web Standards.
2 Comments Add your own
Leave a Comment
Some HTML allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <pre> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
Trackback this post | Subscribe to the comments via RSS Feed
1.
Srinivasu | November 6, 2008 at 10:43 am
Hi Shyamala,
Great post. I hope people will make use of these tips.
Just to add – if one decide to provide keyboard shortcuts, ensure that they don’t conflict with OS / browser keystrokes.
Good luck,
2.
slger | November 6, 2008 at 3:56 pm
Hi, here’s a few tips from a visually impaired blogger.
Rule 17, Headings, is really, really important. I always take a headings tour of a page to learn what is there. Leaving out headers tells me the page has not only been created ignoring accessibility but also probably not designed to present its content in any logical manner.
The screen reader playing field is changing. JAWS is a standard for people coming through the rehab and educational systems, but in ill favor for its lawsuits against other screen reader vendors, and $1k cost. A wonderful free open source alternative is NVDA from http://nvaccess.org. It is keeping up well with web advances, with support from Mozilla. Installation is trivial, and the screen reader runs off a USB stick self-voiced. No screen reader does everything, of course, and the web world is locked into an innovation-funding tangle among browsers, site designers, and users needing accessibility. Vision Losers not funded by social services now have a choice of screen readers. Retiring baby boomers will increasingly influence web markets, with few using the standard JAWS.
With a free highly functional screen reader, now, every page should have been tested for the accessibility rules you advocate. Plus, you might learn to like listening to rather than only viewing web pages.
With more blogging, the choice of platform is critical. I find few problems with WordPress, easily traversed by links and headings. Reading blogs from other platforms is often hard if headings are not used, or if templates throw tempting navigation and blogrolls before content.
Finally, note, as W3C emphasizes, the convergence of accessibility and mobile devices, leading to streamlined use cases. Contrast http://amazon.com with http://amazon.com/access, the accessible version that facilitates faster purchases.
Thanks for listening to my pet peeves.
Susan Gerhart
“As Your World Changes” http://asyourworldchanges.wordpress.com