Accessibility Quick Checks (Part 2 of 3: Content)
This article is the second in a series of three where I look at some quick and easy tests that can be carried out to help determine whether or not a site is likely to be accessible. Of course, passing all of these tests wouldn’t guarantee that your site is accessible, but I think if you did pass all of the tests, it’s much more likely that people would find your site accessible. Again, bear in mind the checklist is intended as a quick n’ dirty guide.
The items break down into three broad areas: coding, content and function although these obviously overlap somewhat. Each article will focus on a different one of these broad areas.
This one will focus on content.
Page Titles
Pages should have meaningful titles so that the user can easily identify where they are in an application or site, so that they can more easily be bookmarked and reference, and because it’s just the right thing to do, ok? The page title should be sufficiently concise: I try to keep everything to 100 characters or less, and I certainly wouldn’t go much higher than this, and I would also suggest that if you’re getting up near this mark, it would help if your page title could be abbreviated slightly without losing its meaning. For example, on post entries on this site, you could lose the “The Pickards » Blog Archive »” that starts off my post titles without losing much of the meaning.
The title length is more of a general guideline however: if the title is meaningful, and it’s not spilling off the end of your page, there is very little to be gained from counting the number of characters…
Note that the text “ — Windows Internet Explorer”, “ — Mozilla Firefox” or similar which appears at the top of your screen at the end of the title is added by the browser — if you are counting characters, don’t include this!
ALL CAPS, italics and underlining
ALL CAPITAL LETTERS should not be used for large blocks of text as it makes it difficult and unpleasant to read. It is okay to use capitalisation sparingly for a single word or phrase to offer additional emphasis, although emphasis should first be applied by using either the emphasis (<em>) or strong emphasis (<strong> elements.
Italics should not be used for emphasis — instead use the emphasis or strong emphasis elements appropriately (the <em> element frequently is presented in italics). Note that this does not apply where you wish to italicize something without giving it extra emphasis. For example, conventions dictate that the names of ships names such as the Mary Rose are italicized. In cases like this, you can quite happily use the <i> element to do so.
Some people will say you shouldn’t, because it’s adding something that’s presentational into your content, but they are talking bollocks because you are presumably seeking to indicate in your content that you are aware of and are following the standard naming conventions. And besides, there’s not much point coming up with a css workaround for an element that causes no problems when used properly and is doing the job perfectly well in this case. So if anyone argues, just send ‘em to me…
With the exception of headings, text on web pages should not be underlined as underlining on web pages is extremely rere on the web other than for hyperlinks and so any ordinary text that is underlined looks like a link and makes people want to click on it, wasting their time and generally making them fed up with you and your site.
Don’t Justify Yourself
… or in particular, don’t right justify text. This can make it extremely read for people with dyslexia to read, as they might experience a phenomenon known as “rivers of white” where the whitespace in between the words appears to run down the page and is very distracting. The MercuryTide site has a white paper on accessibility and usability which has a good visual example of this phenomenon.
Use Plain English
Come on, it’s not that difficult. Instead of using eighteen-syllable words to try and explain your “Corporate Mission Statement”, use the language that you would use in reply, when shortly after telling someone your Mission Statement, they turn around and say “yes, but what is it that you actually do?”
If you make cars, you make cars. You do not manufacture passenger carrying vehicles. You certainly do not facilitate the transportation of commuters through a product-push process. Remember to ask yourself “what am I actually saying?”. And be ruthless with the Zombie Copy.
Avoid inexplicable jargon and acronyms. Use jargon and acronyms by all means but ensure that you provide a definition or expansion of the terms somewhere, so your users aren’t just bamboozled by an endless procession of TLAs that mean SFA.
Use Meaningful Link Text
Links should make sense when read out of context. There are a number of reasons for this.
From an accessibility standpoint, users of screen readers can extract just the links from a page when they’re expecting that page will lead them on to somewhere else. A list of links that reads “our prospectus”, “getting here”, “student nightlife” will be of more benefit to a potential student than a list of links that reads “click here”, “read more” and “click here”.
From a usability standpoint, many users scan the page, looking for links. If the link gives them all the information they need, to make a decision, they either follow it or move on to the next link. If it doesn’t, they’ve got to stop, and read around the surrounding text to find the information that they need, and that slows them down.
From an SEO standpoint, links that are properly labelled will score more highly for those terms in search indexes, and so your website will start to creep up the search engine listings.
And finally — but this might just be me — it really, really bugs me when I see “click here” because I’ve been using the internet for some time now — around 13 years or so — and I bloody well know how to follow hyperlinks, okay? So quit telling me!
…and relax.
Page Weight
Consideration should be given as to how long a page is going to take to download, particularly for an Internet (as opposed to Intranet) application where a certain proportion of users will be accessing the site using a 56 kb dial-up connection.
You can analyse the page weight in one of two ways:
- Using the Web Accessibility Toolbar for Internet Explorer or Opera, and select the page weight/speed report from the “Doc Info” menu. This will give you a basic idea of the size of the base web page, but you’d need to know how much extra to allow for css and images.
- Using the Web Developer Toolbar for Mozilla Firefox, select “View Document Size” from the “Information” menu. This will calculate the total size of all documents, images and css files in your web page. Nice.
So what should your target page weight be? That obviously depends on your site and your expected audience. As a rule of thumb, I’d suggest that the majority of pages should have a total weight (with all images, css etc included) of under 100 kb, although in some circumstances — photo galleries for example — users will expect longer download times because they are after more specific or high quality content.
Cookies, Privacy And Data Protection
This is less an accessibility thing but more about getting your users to trust you. If you set cookies, tell the user what you use them for, how long they remain, and what they can do to remove them. If you collect personal data about a user, explain what you use it for, how long you’ll keep it, whether or not you’ll pass it on to anyone else, and most importantly, whether that person is going to receive a flood of unwanted mailings (post or email) from “a few carefully selected companies”.
Don’t ask for more information than you need. If I’m buying a suit online to be delivered, my name and address are quite reasonable things to ask for. If I’ve made a reservation at a restaurant, a contact number or email might be perfectly reasonable, but why would you need to know where I live?
In short: be open, be honest, be up-front, be reasonable, be trustworthy.
Hello. I am 
