Barriers to web accessibility
Cost, Training and Support top the list.
Nowadays, everything that we do is enriched through access to Internet technology. To “Google” is so synonymous with our everyday routine it is now in the Oxford English Dictionary, to “Facebook” and to “Tweet” are surely to follow suit.
The Internet boom brought with it a cultural revolution and for many of us, being online is now perceived to be as important as access to food and water. We can check email, weather, and news as well as bank, shop, and even chat with relatives half way around the world through the Internet. With the large quantity of mobile devices now available on the market we can access the Internet from almost anywhere at any time.
Mobile devices themselves are becoming extremely popular; with literally thousands of applications to download cellular phones are no longer simple calling and texting devices, they are flashlights, game consoles, spirit levels, e-readers, music players and more recently mobile wallets (or e-wallets). With mobile devices becoming so ubiquitous within our society, access to the Internet has now become a necessity.
For most of us, accessing the Internet is trivial and with a growing emphasis being placed on the user experience, getting things done on the Internet is becoming faster and more efficient than ever – for most of us. However, for a large portion of the population access to technology is not so simple.
In 2006 Statistics Canada released the findings of their Participation and Activity Limitation Survey (PALS) revealing that 1 in 7 Canadians have a disability. That’s 14.4% or approximately 4.4 million people. Of the 4.4 million Canadians with a disability approximately 836,000 Canadians identified themselves as having a “seeing disability”. A new data release planned for 2013 is anticipated to reveal a much larger number.
Given the large numbers you would expect that a lot is being done to help accommodate those with a disability, and you would be correct – well, kind of. If you attended Accessibility Camp TO back in the middle of November 2012 you would have met well over 100 designers, developers, user experience enthusiasts and the like all eager to make technology more accessible. And that’s just in Toronto – there are Accessibility Camp gatherings all around the world full of people with the same ideal: accessibility = usability = common sense. Simple!
But there are barriers to web accessibility that must be overcome:
Making an accessible application takes longer, resulting in an additional cost for a client. But additional is a questionable term. Addition implies extra: adding something to something that already exist. What we’re missing is “included in”. Essential parts of a project, such as project management, are “included in the quote”. The question is: why can’t accessibility also be “included”? This decision does not need to come top-down from management, but can come bottom-up from developers making the decision to make all of their applications accessible. Accessibility should be an integral part of the development process rather than an “additional cost”. And this leads me to my next barrier:
The introduction of the iPhone in 2007 and hence the removal of hardware buttons created some unrest within the accessibility community – and rightfully so, how can you type on a keyboard if you can’t feel (or see) the buttons? But since then apple has done a great job helping third party developers make their apps more accessible. With such an incredible number of development tools available (many of them free) it is important to ensure that training happens and those who design, test and develop technology are aware of accessibility.
3) Other Support
Some might say that designing an accessible application is not necessary given the number of other apps that can work on top of yours to make your content accessible (e.g., screen readers). The same people might also say that those with vision or hearing problems (or any other disability) are likely to have a support assistant to help guide them through interacting with technology. While both might be true it is still important to design with a disabled user in mind. For example, accessibility technology looks at html code, not the web page itself; if your app is not properly coded (e.g., if you do not use html tags appropriately or provide text equivalents for images) then a screen reader will not work. Likewise, if you do not use high contrast, enlargeable text then magnification software such as ZoomText will not work. With regards to support assistants, many users with a disability want to be as independent as possible, and quite rightfully so. Abled users rarely hire a tech assistant to show them how to use an application, the technology is designed so it is intuitive to use – if it isn’t intuitive the user will look elsewhere. Those with a disability should have the same choice.
To conclude, it is important to design and test an application with a disabled user in mind. Testing should be at the core of your philosophy; feedback from users (even support requests) should be used to inform your design. By minimizing accessibility barriers you will reach a larger audience while also improving the usability of your application for all users: if a site is usable for a person with a disability it will be much faster for everyone else to use. This equates to faster loading times, easier site maintenance, fewer support requests and of course an increased positive regard for your site. It’s win-win.