Non-profits need to ensure their websites are accessible. This jargon free guide will help.
Align your text to the left and leave it ragged on the right. Left-aligned text increases reading speed. The straight left edge helps to anchor the eye when starting a new line.
Never fully justify text as it can create serious readability problems. Even if you personally like the look of fully justified text, don’t do it. Word spacing is likely to go awry and you will end up with large gaps between words and ‘rivers’ of white space running down your pages. Those rivers make reading your content difficult, if not impossible, for people with dyslexia. Anything other than left-aligned text can cause problems for people using screen magnifiers.
There seems to be little agreement on what is the best line length for optimum reading speeds. The most commonly held view is that limiting line length to 9 or 10 words can increase speed and comprehension (based on the assumption that the eye can only focus on about 3 inches of a page at a time). However recent research appears to show that the rules that apply to off-line print don’t necessarily apply to online print.
It is suggested that line length can actually be longer for online content. However, having said that, don’t go beyond about 80 characters as at that point readability will start to suffer.
Reading speed and user preferences are not simple matters, consider the following conclusions by Melissa Youngman and Dr. Lauren Scharff (1998)
“Users read faster when line lengths are long, although they tend to prefer shorter line lengths. When designing, first determine if performance or preference is important. If user performance is critical, use longer line lengths to increase reading speed. However, if user preference is critical, use shorter line lengths.” Usability.gov
Set the leading larger than the default – as a rough guide 1.3em of leading (130%) will make a big difference to the readability of a web page. Leading and line length however are related; the longer the line the bigger you need to make the leading.
Newspapers have very short line lengths and very little leading. They do this so that they can fit as much text into a small space as possible. However, given the variable nature of the devices people use to view web pages, we can never be sure what the line length is going to be for every user. In relation to leading my rule of thumb would be, if in doubt go bigger.
As an aside: you might be wondering why line-height is called ‘leading’. Well, in the olden days typesetters used pieces of lead to set the space between text lines. If you like typography and typography jargon – which I do – here’s a couple more. The space between characters is called kerning and the space between groups of characters is called tracking.
Need more exciting typography jargon? Here’s a glossary of typography terms.
Choose a font that is suitable to your subject matter. An article about ancient manuscripts can justify the use of a flowery old font whereas an article about the design of modern art galleries can’t. For the article about the design of modern art galleries you will be looking at using a clean and uncluttered san-serif font.
Don’t use more than two fonts on a page. It will look like a ransom note. Clearly that will be distracting for visitors and draw attention away from your content.
Off-line, headings are commonly set in a sans-serif* font, with body text set in serif. However, on-line, sans-serif are often used for both headings and body text; the cleaner outlines of the sans-serif fonts tends to make them easier to read on low resolution screens.
Don’t mix serif and sans-serif fonts in your body text, as it makes you look like an amateur, which isn’t good. You may not have considered it as important but poor typography decisions can damage the credibility of you and your organisation.
* Serif fonts are those with little decorative flourishes on them and sans-serif fonts are the clean and tidy ones. Compare Times New Roman with Helvetica and you will get it.
Avoid using italics for small text sizes. Italicized fonts can look particularly bad at small sizes as italics are not easy to render using a square pixel grid. If you must use italics, avoid using them for large blocks of text.
Don’t use all caps for bodytype – or even capitalise all words in headings. The uniformly of size and shape of capitals make them harder to read than lower case letters.
Readability is increased when only the first letter in a heading is in capitals; each capital – being less recognizable – acts as an interruption to the eye as it scans across the text.
Ensure good contrast between the text colour and the background colour. If the contrast between your text and background colours is low, some of your visitors won’t be able to access your content. That’s why the WCAG contains guidelines for colour contrast. For complying with WCAG AA standard text the contrast ratios need to be 4.5:1 for standard text and 3:1 for large text. Large text means 14 point and larger (typically 18.66px).
Make it easy for visitors to understand what is a link and what is not a link. Don’t rely exclusively on mouseovers to identify links, as this can be confusing and reduces usability. (From Usability.gov).
For service based websites in particular, arrange your text for scanability, i.e. have lots of headings and provide the most important ideas at the start of paragraphs. Use lists rather than dense passages of text when possible.
Most of your visitors will not be interested in reading every word on your page. So make it easy for them to find the information they are seeking quickly by using headings as signposts; signposts for the various issues and topics you are covering in you text.
Use a writing style and language that is appropriate for your audience. Don’t dumb down or dumb up. Think about who you are writing for and write for that audience.
Ignore the idea that you should never use jargon. If your audience expects it and when using it will actually make your meaning clearer, use it.
On the other hand if you are not writing for a specialist audience don’t try to be clever by using jargon just for the sake of it. Think about your audience and tailor your style to suit.
Don’t strive to use ‘easy read’ thinking that that will make your content accessible to a wider audience. It will accommodate one part of your audience but it will put another part off (probably the larger part). Easy read is designed for people with learning difficulties – an easy read version is an alternative version, i.e. a version aimed at a particular audience.
Contact me If you value experience (over 20 years as a web developer) and unrivalled technical know-how. Do you need a new beautiful responsive, accessible website? Get in touch. Tel: 07810 098119.
For as long as I can remember I’ve puzzled over whether or not to put in default characters in edit boxes and text areas in my web forms. On the one hand if I don’t my page will not will not pass Guideline 10.4 (WCAG 1), and will have no chance of WAI AAA compliance.
Guideline 10.4 exists to ensure visitors using some older screen readers (which don’t recognise empty form fields) – can fill in web forms.
Unfortunately, if I add default text in my form fields I create problems for another set of users, i.e. those who have to delete my text before entering their own. I also create additional work for my forms processing script; which has to check for, and remove any remaining default characters (many people don’t bother deleting the default characters when adding their own text).
I have gone through periods of not adding default text – and having to explain why my forms don’t pass AAA web accessibility tests – and adding text, and dealing with the associated problems. I had resigned myself to the thought that this was one of those web accessibility problems that has no simple solution.
Here is an example from a field in my comments form (only the relevant attributes are shown).
<input type = "text" name = "membername" value = "Name" onfocus="if(this.value=='Name')this.value=''">
Fantastic – one more accessibility compliance problem solved. Get back to me if you are aware of any issues with this technique that I have failed to appreciate.
Links and references
In this tip I recommend you check out a new Toolbar for Internet Explorer developed by Steven Faulkner, of the National Information and Library Service (NILS). Support for the toolbar is confined to Internet Explorer on Windows, so I haven’t been able to try it out myself (I use a Mac) – however, Gez Lemon of the website Juicy Studio is giving it glowing reviews – and I trust his judgement.
According to the blurb, ‘It is designed to help the user to interrogate aspects (structure/code/content) of a html document that can have an affect on the accessibility of that html document. ‘
It does all sorts of things I would find useful as a developer of accessible websites (validation, screen resolution changes, CSS on/off, links to online checking tools and so on), so I think you will find it very useful. You can find installation instructions, and a full feature list for the accessibility toolbar on the website.
The Web developer tool for Firefox is also worth checking out: http://www.chrispederick.com/work/firefox/webdeveloper/ – and it is according to Mike Pepper, ‘bloody good’.
Although client-side images are preferred over server-side image maps – as equivalent text can be provided for each image map ‘hot-spot’ – server-side image maps are sometimes necessary. For example, a server side image can be used when the active regions of a client-side image map cannot be easily defined using an available geographic shape. In such cases the answer is to provide redundant text links relating to each link provided by the server side image map.
The following markup example is typical of the code used to reference a server side image map.
<a href="/cgi-bin/mymap.map"> <img ismap src="imagemap.gif" > </a>
The web pages accessed by the clicking the mage map in the above example would be completely hidden to someone using a screen reader or a text-only web browser, as there is no alternative way of accessing the links provided.
An example of the server side image with alt attribute added and an alternative set of links to the same content:
<a href="/cgi-bin/mymap.map"> <img ismap src="imagemap.gif" alt="Alternative text links are provided at the foot of the page."> </a>
You then make the following links available at the foot of the page,
<p><a href="about.html">About Us</a> | <a href="research.html">Research</a> </p>
As you can see in the example above the alt attribute provided information about where to find the text based links. The alternative text based links provided at the bottom of the page imply that the image map has two hot-spots, one to find information about the organisation and another for information related to research.
Yes, you can use all the ‘stuff’ that as a designer you deem appropriate to your audience and message, and still have a site that is accessible, and passes ‘Bobby’ (and other accessibility tools) accessibility checks.
However, what is required when using these technologies is a bit of clear thinking about what their purpose is on your site, and how, if the content is important, their functionality or message can be provided in alternative ways.
Admittedly it is not all easy, captioning of multimedia for instance is a specialist and difficult skill to master, but most accessibility techniques are not ‘rocket science’ and will actually add to the ‘richness’ of the experience for your visitors, rather than detract from it.
When creating text for your alt attributes always add a full stop at the end of the text. This will help people who are using screen reading software to differentiate the image label from any surrounding text.
It is also a good idea to add a full stop to the end of each item in a list – helping to make the distinction between each item clearer for those who do not have any visual clues.
Use HTML attributes, or CSS to set web page colors, but don’t use a mixture of both.
For example, if you set the background colour in a table cell to black using an HTML attribute (e.g. bgcolor=”#000000″), and used CSS to create contrasting white text (style =”color: #FFFFFF”).
Your page will look fine and you will be happy until you get emails from users surfing with style sheets off (or those using browsers that don’t support style sheets). Those visitors won’t be able to read your text.
I haven’t come across anyone yet who can read black text on a black background.
In the past choosing an accessible, readable font for your website wasn’t difficult, basically because you didn’t have many fonts to choose from. You were restricted to using web safe fonts, i.e. those fonts that were likely to be installed on your visitors computers.
None of these solutions was more than a sticking plaster on the basic problems that designers were not free to use the fonts they wanted to when designing a website.
One current solution is to rent the fonts you want to appear on your site, i.e. a third party owns lots of nice fonts which you can use on your website; and when a visitor loads your web page your desired font is downloaded from that third-party site and used to display your content.
If the users browser doesn’t support this new font download solution – the fonts specified in the CSS are displayed; so what we have is a relatively easy to use, robust and accessible solution to the font problem. That is, as long as the designer has chosen fonts that look nice and are readable across the different platforms and browsers, i.e. not all fonts will look good on a low resolution computer screen.
It is a very simple solution, but it does have the drawback that you pay for the privilege. Business being business its not a case of a one off-payment; to continue to use the fonts you continue to pay for the on-going service of being able to download and use them.
This very simple tip will help you to check whether the colours you have chosen for your web pages have adequate contrast.
Take a screen shot of one of your web pages, and open it up in an image editing program (e.g., Photoshop). Desaturate the image to remove all colour so that you end up with a greyscale image.
Viewing the page as a set of contrasting grey areas makes it much easier to see whether, for example, there is sufficient contrast between the background colour and text. I was reminded of this tip while reading the Techdis article Colour and Contrast Accessibility Issues: for the design of e-learning materials by EA Draffan and Peter Rainger.
Other posts in this category
I provided feedback on the WCAG 2 (as representative of Guild of Accessible Website Designers) have two decades of experience and worked with hundreds of organisations.
07810 098 119