Arial is a sans serif typeface, designed in 1982, based on Monotype Grotesque. The font has a similar proportion and weight to Helvetica.
It is a font with a contemporary look. Since 1992 it has shipped with every version of Microsoft Windows, which has helped it become ubiquitous.
It is a favourite of desktop publishers, though less so with designers; who think it inferior to Helvetica. The story goes, that it was designed primarily to avoid having to pay royalties (to Linotype) for the use of Helvetica.
It is rarely recommended for print work (though it is a print font). Helvetica is considered a better-looking, more flexible font.
Arial is recommended by RNIB and other organisations concerned with accessibility. If you search for guidelines for document accessibility they all tend to say, use Arial, with a minimum size of of 14pt.
However, I am not aware of any research that shows Arial to a better font than similar sans serif fonts. I think it’s more likely that it was the sheer ubiquity of this sans-serif font that led to the recommendation.
There are similar contemporary-looking, clean and easy-to-read fonts that would do the job just as well. I.e. Calibri, Century Gothic, Helvetica, Tahoma, and Verdana or Myriad Pro.
Note that all of the above fonts are sans serif. Serif fonts are rarely recommended – as more ornate fonts are considered more difficult to read. On lower resolution computer screens the serifs can be distorted, making the words look blurry.
Having said that, slab serif Fonts (a type of serif typeface characterized by thick, block-like serifs) such as Rockwell, Clarendon, and Museo Slab are considered easy to read and accessible. They tend to be used for headings rather than body text.
Photo: “Pool of Knowledge” by Ian Muttoo is licensed under CC BY-SA 2.0
On my WCAG 2.1. training course, I outline why designing a flexible website is the key to accessible website design – by flexible I mean designing your site so that visitors can change it to suit their own needs.
It’s a good approach for you because you don’t need to design a million different websites, e.g. one with big text for people with a visual impairment, another for people who are colour blind and yet another for people with motor impairments. You just need to design one website; one that can flex to accommodate a million different needs.
I said that you should aim to, ‘divorce content from presentation’. Unfortunately, that can all sound a bit theoretical, so in this article, I will give you some practical examples of how that works in practice.
1. For people using older browsers ensure you set font sizes using relative units (e.g. em units or percentages) rather than absolute units (e.g. pixels or ppints). If you use absolute font sizes visitors to your site using older browsers might not be able to resize the text to suit their needs.
2. Ensure your website is ‘responsive‘, i.e. it reflows or resizes itself to work on all devices – no matter their size or shape. If your website is not responsive visitors may have to scroll left and right, to see all of your content or it may be unusable on smaller screens. I agree with the Bureau of Internet Accessibility who explain that making your website responsive is essential – but it is not the full story.
3. Don’t use background images for important content. It is not possible to add text description (i.e. via the alt attribute) to background images. For a portion of your visitors, some of your content will be missing. For example, enabling high contrast mode in Mozilla’s Firefox automatically hides background images. It does this to ensure that all of the text on the page has the desired high contrast – with the background. If those background images have essential content in/on them – that content is gone for some visitors. The visitor is no longer getting equivalent content to those people using the default contrast.
4. Ensure all links clearly describe their destination. Screen reader users can quickly navigate around a page by extracting all of the links – so I can quickly jump to the one I want. If the links are all called ‘click here’ or ‘more’ or ‘PDF download’ then they need to read the entire page to get the context for every link. The designer did not build in flexibility; they built-in a barrier that only became apparent when a screen reader user tried to access the site. Never turn off user scalability; this will make it difficult for visitors to resize the text.
5. Similarly, a screen reader user can summarise headings on a page – to get a sense of how the content is organised. This will only be possible though if the content is organised in a logical way using appropriate headings, i.e. an h3 heading is used to indicate that the content of the headings is related to but subservient to the content in the preceding h2 heading. If there are five headings on a page and they are all marked up using h1 – visually they may look related – but as far as the screen reader (and access tools) are concerned – there is no logical order to any of them.
6. Ensure your site is keyboard-friendly. Many assistive technologies rely on keyboard accessibility – not just screen reader users. For example, people who use mouth and head sticks and those who use adaptive keyboards.
Try using your tab key to navigate your website. Check if any links are being missed, check that the links are in a logical order, check that there is a visual indication of the link you are on; one common method is to have the link outlined in a colour that contrasting colour. If there is no ‘focus indicator’ it is very easy to get lost when using a keyboard to navigate.
Non-profits need to ensure their websites are accessible. This jargon free guide will help.
Just a quick follow up from my New Year Newsletter in which I gently encouraged you to think about your website and online marketing strategy. One area I mentioned in my newsletter was website accessibility. As I am sure you already know, it is considered a form of discrimination if disabled people are not able to access website content (the Equalities Act 2010). So with that in mind I thought I’d take the opportunity to look at the benefits of accessible website design from a slightly different perspective, i.e. the business case.
In September last year I spoke at the Accessibility Scotland conference and an audience member asked whether there was a ‘cast iron’ business case for making a website accessible? They were having trouble trying to get their managers to prioritise accessibility or put any resources into ensuring the website was accessible to disabled people.
‘Off the top of my head’ I could not remember any statistics to quote, though I did mention the usual stuff about a more accessible site generating more traffic, being easier to use and having reduced maintenance costs.
However, it seems that these logical arguments do not ‘cut any ice’ when it comes to making the case; what people want are facts, figures and case studies showing increased traffic and increased sales.
So with that in mind here are three major case studies showing the benefits of accessible website design in real terms.
These case studies clearly show that an accessible website design reduces maintenance costs, increases usability and increases traffic. In short, accessible website design is good for your business.
Even if you are not planning a brand new website from scratch I can help you realise some of the benefits outlined above by making your existing website more accessible. The first step in that process is to have your website audited to see if there are any aspects that are inaccessible to disabled peoples. You will then be in a position to have those issues addressed; thus increasing the accessibility and usability of your website.
As an website accessibility auditor since 1996 I am one of the most experienced and skilled practitioners in the UK. I will check your site against the WCAG 2.0 guidelines to ensure that your site is compliant with the BS8878 Web Accessibility Code of Practice.
An audit by myself goes way beyond tick box checks; I will check that your site is accessible and usable to the real people who visit your site.
Contact me today to take advantage of this unique expertise to utilise my expertise to attract more visitors to your website and make it easier to use by everyone. No matter what your budget or how big or small your website is I will be able to provide an audit that fits with your needs.
“Jim’s patience and close work with his designer meant we got a vibrant new image that we could use across all media.” Clare MacGillivray, Development Coordinator Edinburgh Tenants Federation
Or phone to talk over your ideas: 0141 576 9446.
Photo by yvestown on Flickr – used under a Creative Commons licence
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.
British Standard 8878 (BS 8878) is the Web Accessibility Code of Practice developed by the British Standards Institution, launched on December 2010.
The standard outlines procedures to help ensure that websites (and other web based services) are accessible to disabled people. In short, it provides guidance on good practice; how to develop your strategy and what practical steps to take to implement that strategy.
One assumption it makes is that accessible website design is a good thing and that it is something every organisation should be working on.
When building your new website:
BS 8878 aims to be more ‘holistic’ than other guidelines such as the Web Content Accessibility Guidelines (WCAG) which focus much more on technical issues.
Given this wider approach, it covers:
There are positive and negative factors that would influence you in considering whether you should adhere to BS 887.
In my opinion The BS 8878 is an extremely useful and important document as it recognises that website accessibility is a more complex subject than just applying the right techniques to a web page (i.e adding text labels to images).
It is also about how organisations operate in relation to equality (e.g. policy development), how organisations tender for website developers, how accessibility is tested and who tests it (e.g. disabled people) among other things.
A navigation menu is – if we are speaking structurally – a list.
I still see websites that don’t markup their navigations links as lists; I guess the reason for this is that designers don’t want to have ugly big bullet points littering their menu’s, or seemingly uncontrollable margins throwing out their carefully crafted layouts.
Is it possible to use the correct structural markup, and still make your menus look the way you want them to?
The simple answer is yes; you can use CSS to style lists to look more-or-less any way you want.
First, undermine your previous assumptions by visiting the Listamatic website to see examples of different list styles (with the CSS used for each).
Then visit Mark Newhouse’s Taming Lists tutorial to learn how to make your own.
And finally – if you can’t be bothered learning how to do it yourself – have a look at Accessify’s List-o-matic – where you fill in a few forms, and the List-o-matic tool does all the hard work for you.
Using the appropriate markup for all the structures in your web documents is the first step towards making them accessible; web pages need to be accessible to the ‘user agents’ people use first, before they can be accessible to the people themselves. Using valid standards based markup means you have the best chance of your pages being understood by those intermediate ‘user agents’ (usually that means computers and web browsers).
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.
Other posts in this category