After reading an interesting post on accessibility over on Paul Irish’s blog I thought I would post my musings on the subject.
Accessibility has always been an important issue to me, not only is it the right thing to do it is also a legal requirement for businesses to ensure their websites are accessible (fines have been levied against several large organisations including the Olympics in Sydney back in 2000).
The main issue I have come across when building an accessible website is maintaining a balance between what the client wants from the site and how to make that accessible to everyone. I have worked closely with user experience (UX) directors to help achieve this balance however UX isn’t an exact science and the UX for a website and therefore the accessibility requirements does vary from site to site. For example, a site like Sound Cloud will struggle to offer a good user experience and accessibility to people who are completely deaf, due to the content being user generated its not easy for the to offer text versions of songs. Equally, Flickr consists of a huge number of user uploaded photos but a hard of sight person may struggle with the site as the users may not have put adequate descriptions of the images.
One argument I have heard from clients in regards to making poor accessibility decisions is ‘Apple does it’ however even though Apple is an icon in the digital era, the most valuable company in the world and produces products which lead the market in both usability and accessibility it doesn’t necessarily mean they get it all right. An example of this is the search box on the main navigation which uses AJAX to quickly get results, it also has the functionality to return a search results page if you press enter so to the average user the functionality is good however when I ran tests on this with a screen reader I found that it could get quite confusing to a user who was expecting to press a submit button after filling in the search box, there isn’t one. With no button the only way to submit the form is by pressing enter, obvious to someone who can see the page but not obvious to someone who has difficulty with there sight.
Without a focus group of internet users who have trouble with hearing or with their eyesight it can be hard to get a full understanding of how they use your site. Unfortunately its not always possible to take into account every use case that users may face however we need to ensure we try our best to plan for several different use cases. Fortunately for the Mac users among us there is a tool which helps us with this, Mac OS X ships with VoiceOver, a screen reader aimed to make the operating system accessible. This can also be used by developers for getting an idea of how a screenreader reads your site but it should not be seen as the definitive solution, like the way we have dozens of browsers that render websites differently, there are many different screen readers out there all of which do there job slightly differently.
Jason Kiss wrote a nice article over at his accessibility blog about how HTML5 and ARIA roles work with screen readers, what is very interesting is the differences between the different screen readers and the differences between the way in which they work with different web browsers. The main reason they work differently with different web browsers is due to the way in which the web browser provides the content to be read by the screen reader, unfortunately this inconsistency makes a developers lives multitudes more difficult as it is often impossible to take into account every browser/screen reader combination simply due to project time constraints.
Reading about screen readers can only provide you with an idea of how your site might work in a screen reader however Zoe Mickley Gillenwater has posted a series of videos demonstrating this over on her blog. This is very useful to give us an idea of what to expect from screen readers, the one thing that I really noticed is that some screen readers are still using very unnatural speech generation, very much ‘I am a robot’ type talking and if it were me personally using a screen reader I would read the minimum amount of text possible to find out what I want to know, it would be useful to see case studies on how long someone with a screen reader spends on a page, is it longer than someone without or is it shorter.
Fortunately it looks like the W3C are coming to our rescue with the HTML to Platform Accessibility APIs Implementation Guide which should hopefully start to clear things up for both browser vendors and developers about how the APIs should be implemented and used. However W3C do have a reputation for taking there time with these things (CSS 2.1 was only finalised June 2011) so I don’t expect a final draft for at least a couple of years but this does not stop us starting to look at it (after all we have all been using CSS3 for a couple of years already and thats not finalised).
In conclusion, there is a lot to think about when it comes to accessibility on the web, but as developers its our job to not only make our websites accessible but to also push browser and screen reader vendors to start to make our lives easier. Through working together we can make the web more accessible, to quote Paul Irish ‘Accessibility should not be opt-in but opt-out.’.