This post has come about because we are currently working with a peak government body in the accessibility space and have been discussing accessibility around the office. When accessibility comes up, I always refer new colleagues to an article by Phil Powell which is available on Boagworld. Listening to Phil talk about accessibility was the point where I really began to understand its’ importance – I recommend listening to him (http://boagworld.com/podcast/205/ -  is at about 17 minutes from the end), or reading the article on Boagworld.

Accessibility is a topic which is of importance to all organisations however I would suggest that it is often misunderstood. My discussions with clients and colleagues within the industry would suggest that most think of accessibility as building interfaces for disabled people.  I would suggest that accessibility is much broader than this; it is ensuring that interfaces are available to all people. Accessibility doesn’t just assist those with disabilities it assists everyone; older people, visitors who temporarily do not have access to a mouse, users who do not have the latest graphical browsers and plug-ins, people with slow Internet connections, people who access the web in noisy, or low-light environments, people using mobile devices, people with injuries, the elderly and so on.

Put simply I wrote this post to highlight the article by Phil Powell which I feel is of value to everyone who works with websites.

As a side note, we had a question this week from a client about CMS’s which help to generate accessible code.  This article is also worth a read.

Accessibility is often one of those things  placed in the ‘too hard’ basket, or worse deemed unimportant as it thought to be only relevant to a small portion of the population.  The fact of the matter however, is that accessibility benefits all internet users.  Accessible websites and the information they contain are generally easier to comprehend, more user friendly and often more compatible across a range of web browsers, including mobile browsers.

Image from http://www.korten.in/Accessibility.aspx

While undertaking a full accessibility review can be a daunting process that may require the input from a professional, there are a few simple things everyone can do, to ensure that their websites are more accessible.

1. Do not make your website dependent on colours.
   Colour alone should never be relied upon to convey meaning to users. Links should always be underlined, and important information and forms should always be labelled correctly.It is easy, when designing a website, to think your website is immune from colour blindness problems because it doesn’t use red or green. In reality, there are many different types of colour blindness and the only way to ensure that your design is truly accessible is to check your foreground and background colour combinations to determine if they provide good visibility. 

   The W3C official statement on colour visibility is: “two colours are considered to provide good colour visibility if the brightness difference and the colour difference between the two colours are greater than a set range.” The range suggested by the W3C is > 125 for colour brightness and > 500 for colour difference.”.

   An easy way to check the contrast levels of your website’s colour scheme is to download the Vision Australia Colour Contrast Analyser for webpages: (http://www.visionaustralia.org.au/info.aspx?page=628). This tool analyses all colour schemes according to the W3C guidelines for contrast and provides a pass or fail mark. It can be changed to particularly target different types of colour blindness so all types of visually impaired users can be tested.

2. Place alt text on all images and media.
   Text equivalents should always be provided for all images on your website, as screen readers cannot ‘read’ images, they read the information provided in the alt tags. If the image used contains text, all text should also be included. Having alt text in the image tag ensures users relying on screen readers can hear the description of all images, rather than just hearing the file name. It can also be useful when pictures cannot be downloaded from the server, which often occurs when users are on slow connections. Alt text is particularly essential when an image is used as a main navigational link.Alt tags can be easily placed within the <img> tag of your website’s HTML body code. For those who are unsure, look for the tags that look like this: <img src=”/images/styles/usabilityone.gif” alt=”UsabilityOne”/> The alt text for this image exists after the ‘alt=’ tag, and reads as “UsabilityOne” 

   If you’re not sure about whether to provide alt text for your graphic; the safest solution is to always include it.
   It is also good accessibility practise to ensure your page is not dependent on images for navigation, or that the whole page is an image (e.g. one huge JPG created in Photoshop).

3. Use meaningful and distinctive page titles.
   Another easy way to improve the accessibility of your website is to ensure each of your website’s pages has a different and meaningful title. The title is the text placed between the <title> tags in your website’s source code, and is displayed in the tab of each browser, so you can see the description of each page you’re on (see image below). 

   It is also the first thing a screen reader will come across after a web page fully loads, so it is vital that it gives your visually impaired users a meaningful description of what page they are on, and to differentiate between other web pages.

   Have a look at the titles on each of your web pages that come up in the tab of your browser. Is it succinct and descriptive enough to give a reader an understanding of the page they are on? If someone was just relying on this, could they tell it apart from the other pages within your site? If it doesn’t do these two things, it’s worthwhile manually changing the text in-between the <title> tags in your source code, or asking your web developer to change it to something more appropriate.

   A good habit when creating a window title is to ensure it always follows the format “Page Title | Company/Organisation Name”. This format lists the page identifying information first.

PDF’s in general should be avoided as they cause many usability problems. However there are times when PDF’s have their place on the web; for instance if a document is meant to the printed then PDF is the correct medium. If your site contains PDF’s it is vital that users are aware of when a link will open a PDF.

Indicating the presence of PDF links helps to avoid PDF shock; that is giving users a nasty surprise of being dumped into a PDF file. There are a number of different ways of indicating PDF links. One method is to include a PDF gateway page; a page which summarises the PDF content, warns users that they are getting a PDF file, as well as presenting the file size. Gateway pages are supposed to prevent PDF shock as well as let users determine if the PDF is worth opening. However in our labs we often see users experience difficulty with gateway pages. Users assume the gateway page is the ‘result’ and don’t continue to click the PDF file. It is in-fact breaking the link to the real file. Many government websites use this technique and I’m starting to wonder if it really is the best way to display PDF’s.

My preference would be to include the PDF symbol next to the link along with the file size. If this is included in the link anchor text then screen readers such as JAWS can easily determine the presence of PDF’s. Surely this is enough to determine the presence of PDF’s without the need for a gateway page.

What do you think is the best way of presenting PDF links?

From online flight boarding passes to application forms, we all use PDF more than we probably realise. And with the Federal Government making all paper-based forms available electronically in PDF format as part of its Electronic Services Delivery strategy, PDF continues to be an essential part of our day-to-day lives, both at work and at home.

However, while we encounter PDF frequently, it doesn’t necessarily follow that it is the best method for us to use. In fact, it’s almost taken for granted that it’s just the way to do things – so we at UsabilityOne decided to investigate this further, and bring to light the real user benefits and limitations of interactive PDF forms.

You can check out our findings in our latest report, Incorporating the role of PDF in the Australian Government’s Electronic Services Delivery strategy.

Once you’ve checked out the report, make sure to tell us about your experience of using PDF by commenting here!

This week I came across an interesting article on accessibility by Gary Barber. In this article, Gary complains that behind a facade of interest in, and understanding of, web accessibility, organisations in Australia do not really care about making their websites accessible.

I surely agree with him. There are very few organisations that approach us for help with accessibility who are driven by a genuine desire to make their website accessible. In most cases, companies start worrying about accessibility only when they have to meet some legal requirements. The reason behind this is that organisations still do not realise the great benefits (e.g. financial return) of offering accessible websites (sadly, I remember talking about this 6 years ago and little has changed).

I also agree with Gary on the fact that we need a centralised library of accessibility solutions. Whenever I encounter an accessibility issue for the first time, I spend hours reading about different solutions implemented by various developers, trying to decide what would be the most effective one. The creation of a centralised library would make this process much easier.

There is, however, a statement in Gary’s article on which I disagree: “the WCAG checklists don’t work. (…) Checklists are just too open to management and insecure web team members abusing them and warping the real results.” Yes, in an ideal world we would be running accessibility testing with users who have a disability, rather than reviewing websites against checklists. Unfortunately, this is simply not feasible. Due to the variety of types of disabilities that can affect the users’ online experience, and the even larger amount of assistive technologies that people may utilise, a website must be tested with a huge number of users. Even so, it would not be possible to say with any certainty that a website is accessible to everybody. We have tested websites with a sample of people with highly varied disabilities before, and yet at the end of the project we could not be certain that we had covered every issue simply due to the fact that we were catering to such a wide, diverse range of issues. This is why guidelines (like WCAG) and checklists have been written. They are very useful and effective at identifying many common and serious accessibility issues so that they can be resolved. Sure, complying with WCAG does not guarantee that a website is 100% accessible either, but it is a very good starting point to efficiently address many common accessibility issues.