Forum Moderators: open
Requirements of the accessibility needs of disabled (be it visually or physically or otherwise) and older users has long been neglected in web site design communities, although with the increased exposure of Section 508 of the Rehabilitation Act Amendments of 1998 (the recent penalty imposed on the 2006 Olympics website, for example) requirements and heightened awareness of the needs of disadvantaged users, accessibility is coming more to the fore.
However, much of the time it is treated as an afterthought, rather than being approached in a proactive fashion from the onset of the design and development lifecycle. I am currently writing a paper for a conference on this very topic, which is why I decided to post some simple tips and techniques that are easy to implement and will move your site closer to being truly accessible.
I've outlined 10 tips and techniques here that I feel are a good place to start on making your site accessibible. This information is out there and freely available but I thought it might be an idea to collate some of the more important ones and post them in one place.
Why should I make my site accessible?
It’s basic good manners! You don’t put white text on a white background, as people won’t see it, so you should avoid using colours that are indistinguishable to people with colour deficiencies. About 8% of adult males suffer from one type of colour deficiency of some form – if your site uses a colour scheme that is not compatible with their colour deficiencies, they’ll leave. We do our utmost to support browser versions used by 2 – 4% of people! So we should be catering for this significant user group.
It’s also becoming the law – while Section 508 is primarily for governmental and state sites, I believe that soon enough we will see more formal moves that will mean all new sites should comply to some basic accessibility rules.
There is a large group of people with disabilities surfing the web. They may be interested in the content of your site, they might like to buy the product that you are selling - however, if your site isn't accessible you're loosing users and you're loosing sales... it's as simple as that.
1. Specify the language used on your page.Very, very often overlooked! If you don’t specify the language that the content of your page is written in, screen readers will make a stab at guessing it – and may well get it wrong. This is especially true of technical pages, or pages where the content is based on a topic that uses a lot of terminology or topic specific vernacular.
Tip: Simply using <html lang="en"> will do the trick!
2. Use descriptive page titlesMany screen readers have keyboard shortcuts that allows the user to toggle through the currently open windows by reading out the title of the window.
Tip: <title>My Site Name: Products and Services Page</title>
3. Additional NavigationPapabaer [webmasterworld.com] recently flagged the use of the <link> tag as an extra navigation for Opera and many will know it from using it to call in external CSS files. However, the link tag has a very important use in making your site accessible for people using screen readers, as these will be displayed (for want of a better word) at the top of the page. Try it! Put in some <link>’s and view the page in Lynx – it behaves similarly to a screen reader.
Tip: <link rel="Home" title="Home" herf=http://www.mySite.com/index.html>
4. Content on topMany will know that using CSS to position your content at the top of the html code has may advantages in SEO, however, this is also a very important technique in accessibility. This means that people using screen readers do not have to scroll through the entire navigation of the site before getting to the content. This does lead us into the next point..
5. Skip Navigation LinkIf the content on top option is not viable for you, then it is important to use a "Skip Navigation" link. Just add an anchor before your main navigation <a href="#mainContent" title="Skip Navigation">Skip Navigation</a>, and have a named anchor at the start of your content <a name="mainContent"></a>. This allows users to skip the navigation and start chewing through your copy.
Tip: Obviously you don’t want this on your visually rich page, so some simple CSS will sort this out:
.skipNavigation {
display: none;
}
6. ColourAs mentioned above, cater for the ~8% of people with colour deficiencies. Flag your links clearly, for example green text and red links will be identical to deuteranopic (red/green colour deficiency) users. I always underline my links, but bolding and a good colour variation will do too!
Tip: Use the VisCheck [vischeck.com] online page checker to see how your page looks to people with colour deficiencies.
6. JavaScript LinksAgain, SEO people will tell you not to do this as spiders can’t/won’t follow JavaScript links. Similarly for accessibility reasons. Stats say that 11% of users browse without JavaScript, which includes disabled users whose browsers just don’t support it.
Tip: Put the link in as normal in the href and run your script onClick, overriding the default action with a return false;
<a href="some/link.html" title="Link Title" onClick="runScript(); return false">The Link</a>
7. Link TitlesNeeds no explaination really – does it!
7. AccesskeysThese are basically keyboard shortcuts to various pages on your site. Fully supported in screen readers and somewhat supported in visual browsers, by using ALT+ a number, followed by Enter, users can navigate directly to the page.
<a href="home.html" title="Home" accesskey="1">Home</a>. You can use it for your skip navigation too! There are some unwritten conventions for accesskey assignment: 1 is generally for the home page, 2 is generally for the Skip Navigation and 9 is generally for the Contact Page.
Tip: Many sites have accessibility statements that outline the accesskey values and functions. Have a look at the diveintomark dot org accessibility statement, as a good example of this.
8. Table ElementsUse table headers to specify the legend on data tables:
<tr>
<th>Column 1 Header</th>
<th>Column 2 Header</th>
</tr>
One of most omitted accessibility element is the summary on tables. This acts as a summary of the contents of a table. This summary is never displayed in visual browsers, but a screen-reader user will get a summary of the table before being read it’s contents. Think of it as an ALT tag for tables! <table summary="A summary of the table">
9. ImagesThe alt tag goes without saying, but don’t forget the longdesc attribute. This is a link to a file (generally text, or text only html) that gives a more comprehensive description of the image that the alt text.
Tip: Image maps should always have an associated longdesc, to explain the contents and areas of the image map. Also, don’t forget the title attribute on your <area> calls.
9. FontsHere I will emphatically say: Use Relative Font Units. This is an accessibility issue for users whose eyesight is impaired, but are not totally blind. IE will not increase the size of a fixed font unit (View > Text Size)
Tip: I've found that 80% is a good size to use for your body text!
10. FormsUse labels! This allows visually impaired users to know what each form input element is for!
Tip: <label for="workPhone">Work Phone Number (Optional)</label>
<input type="text" id="workPhone">
HTH!
Anyone else got any tips and techniques that I'd missed?
<edit>Added call for other tips and fixed typos. And DaveN - in Cork, we always drink Murphys!</edit>
[edited by: BlobFisk at 3:45 pm (utc) on June 12, 2003]
I recommend this experience for anyone who is serious about accessibility, its a real eye opener! (pun intended).
Anyway, I'm happy to report that a content first approach works pretty well (provided of course you provide a 'skip to navigation' at the start of your content and a suitable access key).
Example:
<MAP title="Navigation Bar">
<P>
[<A href="#how">Bypass navigation bar</A>]
[<A href="home.html">Home</A>]
[<A href="search.html">Search</A>]
[<A href="new.html">New and highlighted</A>]
[<A href="sitemap.html">Site map</A>]
</P>
</MAP>
Chris D: You're quite right, it was the Sydney Olympics - for those interested a summary of the complaint can be read here [contenu.nu].
Nick_W: The <link> one gets me too! The W3C cite "Alternate, Start, Next, Prev, Contents, Index, Glossary, Copyright, Chapter, Section, Subsection, Appendix, Help and Bookmark" as being valid (W3C Recommendations [w3.org]), but it also says:
"Authors may wish to define additional link types not described in this specification. If they do so, they should use a profile to cite the conventions used to define the link types. Please see the profile attribute of the HEAD element for more details."
Hester: Today: accessibility, tomorrow: successfully counting to 10.... ;)
Mattur: While there is no standard, the list above tallies with diveintoaccessibility's recommendations, and seems to be a growing standard.
I've always associated the <MAP> tag with client-side image maps, so I went back and checked the HTML spec. It says..
The MAP element specifies a client-side image map (or other navigation mechanism) that may be associated with another elements (IMG, OBJECT, or INPUT). An image map is associated with an element via the element's usemap attribute. The MAP element may be used without an associated image for general navigation mechanisms.
So fair play I guess.
Note that this is just one suggested way to handle link grouping - it is not the only one. Personally I use <ul> to markup lists of links, which to me makes more sense (because it tends to render better when no stylesheet is applied)
The W3C is FULL of information, once you learn to find your way around ;-) I really appreciate a section called Scenarios of People with Disabilities Using the Web - it helps you understand the things that make a site inaccessible.
[w3.org ]
Of interest, people here might like to know that the screen reader technology is light years behind our html and CSS coding abilities! For example, using CSS you can set it up so that a screen reader pauses at the beginning of each list item (items in a list without punctuation are not understood to be separate sentences). Unfortunately, while the CSS is valid, there is not currently a screen reader designed for windows that can acknowledge this.
Someone mentioned creating a page outlining your access keys, etc. For more information, do a search on Accessibility Statements - that is what these pages are called. Macromedia has made a half hearted attempt to have one ;-)
Which leads me to add ins for Dreamweaver. There are accessibility extensions available for Dreamweaver 4 and there is an option to turn on accessibility in MX that will prompt you for table captions and summaries, etc. The software is really lacking in it's ability to make it easy to code accessibility features. On my wish list: the title attribute in the property inspector!
Another tip for making your site accessible: Using headings in a logical order. Just because you find h3 to be a better size for a page heading, don't use it instead of h1. Use CSS to mark up your h1 as desired.
One last thing :-) There is a terrific site out there with examples on how to make tables, forms, etc. accessible. Since I am not supposed to url drop do a search for your html source :-) I used this site as the basis for my curriculum when teaching accessibility to webmasters at a local university.
Beware that several browsers (visual and screen readers) cannot currently support this coding style.
My $.02 CDN...which doesn't amount to a whole lot, but every penny adds up just like every customer ;-)
itrainu
Oh ya, I had another penny thought :-) Regarding the lang="en" attribute - this can be used on *any* html element. So if you have a bilingual page, each paragraph or div or whatever should be marked up as div lang="en" or div lang="fr" for example.
re: using absolute positioning for SEO isntead of accessiblity.
I understand your point.
Accessiblity is important and in a perfect world should be the no.1 concern. For most websites I would agree.
However, some folk here (err, not me, obviously) do sites purely to make money - no other reason.
In that instance I would expect the site needs to be measured purely by whether it can bring in large amounts of viewers, separate them from their cash and send them packing (in a nice way, of course)
To a hard core affiliate guy, this can be tracked and measured. If accessiblity improves the traffic and conversion ratio then it is used, if it doesn't then it isn't. This may vary from market to market, but its the hardnosed way of the world.
It shouldn't be like this, but sadly it is.
{for navigation skipping links use..}
.skipNavigation { display: none; }
This will hide it from the visual browsers, but it will display perfectly in text and speech browsers.
Nope. Just tried it. :(
If its marked as display:none then the screen reader doesn't 'see' it either (at least not the IBM one).
Instead I suggest using a 1x1 transparent gif instead. Like this..
<a class="accesslink" href="#content"><img src="/images/transparent.gif" width="1" height="1" alt="Skip to start of content"></a>
Of course, as itrainu points out, it would be a whole lot easier if the screen readers out there actually read the aural stylesheet.
re: using absolute positioning for SEO isntead of accessiblity.
As I said tho, the two are not mutually exclusive. You CAN do a content-first SEO-friendly document that still has a sensible structure and is properly accessible.
I think Papabaers point was that it can be a lot easier if your document structure reflects the order that it appears on the rendered page.
Yup. You can either use multiple style sheets, and set a 'media' attribute on your <link>, or stick an @media <medium> {} section into a sheet. If you don't specify medium, then the rules apply to all media in which they can apply. (Obviously, positioning, font size, and color attributes have no effect in an aural medium, for example, no matter where in the sheet you specify them.) Perhaps something like:
.skipNavigation { display: none; }
@media aural {
.skipNavigation { display: inline; }
}
You might also want to specify one or two other media where it was displayed. I think there are medium names for small-screen and paginated outputs, too, where the link might be nice.
I heard that VoXML (Voice over XML) might overtake the screen reader software companies - ie. VoXML might support aural stylesheets before these companies do.
Any thoughts on this?
itrainu
Thanks for clarifying that - believe me - I know a lot about the SOCOG issue - I couldn't believe another Olympic site could have also made the same mistake so soon (and that I hadn't heard!)
You might also be interested in this Australian 'reporting' process - and the email format page at [bca.org.au...]
These are the instructions for using the form:
"If you have encountered a web page which does not conform to accessibility standards and you are not able to access it using adaptive technology such as screen reader programs, you may wish to lodge a complaint under the Disability Discrimination Act.
If you use Windows, you can link to the attached complaint form, copy it to the clipboard, activate the Human Rights email link and paste from the clipboard into your email text window. Fill in your details, enter bca@bca.org.au in the CC field and mail it.
It is also suggested that you send a copy of your complaint to the web master of the page in question, although this may be difficult to locate if the page is inaccessible."
As this is Australian legislation - this is only applicable to Australian sites - I just thought you may be interested in how the process works here.
Chris_D
Sydney Australia
I wrote a post about a year ago on this subject and never returned to it. I'll dig up my notes because I've got this nagging feeling that even with all the great advice in this thread we're missing something.
I've seen a lot of code, but the people on the other end of that code are a huge part of this equation.
Yeah, I remember that post from you and it was a cracker. I flagged it as I knew I'd need it again at some point:
Accessibility Issues In The Real World [webmasterworld.com]
What if the CSS made it visible in everything but media="screen"? That is, only specify it as display:none for the screen.
Useful for compatability with websites that don't code for screen readers I suppose, but not so useful for those of us who do care and would like to help.
I'm looking for my list but I can't find it anywhere.
Any screen reader is probably *not* going to get aural style sheets, because they read what is being sent to the screen by other software. You'd have to be using a browser that specifically supported speach itself, at least in so far as sending its own stream of text to the synthesizer, which I assume is what Emacs does.
Since there seems no way to hide it (and stick to the standard), is it common procedure to have every page start on top with a visible "Skip menu"? (It feels a little strange for people with regular browsers to have that link, since it doesn't make any sense when the content starts like 50px under the menu...)
Nope. Just tried it. :(
If its marked as display:none then the screen reader doesn't 'see' it either (at least not the IBM one).
That's what I mean with "standard". When you hide it, it's hidden... everywhere... and from reading in this thread it looks like defining another media type doesn't help...?!
On one site I put the 'skip navigation' link way over to the right side, but still the first thing on the site. I figure people who need it will find it, but other people may not notice it.
On one site I put the 'skip navigation' link way over to the right side, but still the first thing on the site. I figure people who need it will find it, but other people may not notice it.
Brilliant idea, Trisha! I have a special CSS class defined for my "Back to the top" links, which does just this. A "skip to the content" link done the same way, between the page title and the "proper" menu", would look perfectly normal. As far as I'm concerned, this has solved all my concerns (about this topic, anyway).