Recently at work, accessibility has been getting more attention. How accessible are the products we make and how can their accessibility be improved? What does accessibility mean to our clients, how relevant is it to their project and how can they be convinced of it’s importance? Important questions, but as the person on the sharp end of delivering accessible websites what I need to answer is; realistically what we can we do to make the sites we build as accessible as possible within existing budgets and timescales?
Everyone I work with sees the benefits of valid semantic HTML, unobtrusive JavaScript, and other web-development best practices; we’re not seeing accessibility as something to be begrudgingly bolted on or a box to be ticked. We want to do our best to make our products inclusive, but the aim of accessibility on the web is often summed up by “making all content easily accessed by everyone regardless of any disabilities they might have” (or more eloquent words to that effect). Easier said than done—we all know that’d be just lovely, but in reality there are limitations of technology, time and budgets that prevent everything being quite so cosy (not to mention the limitations of my knowledge). It’s a huge task to deliver everything we’d like to, and can often make ordinary web designers feel a bit they’re being asked the impossible.
We need to find a practical path where we can deliver real benefits but avoid getting bogged down in the unacheivable. Given that there is no possible hope of me knowing about all the possible disabilities and impediments of people who use the websites we build, let alone having any true understanding of how that disability affects how that person interacts with the web, and given that we don’t have that time to learn to use, develop for and test in a wide range of assistive technologies (or even all visual browsers), what is the best way forward?
I’m starting to think the answer lies in not trying to ‘fix’ accessibility problems that relate to specific disabilities or technologies. We shouldn’t make websites thinking about specific disabilities or problems, rather we should concentrate on how to deliver the text content in the easiest, most straight forward and usable way. This way we keep the site’s content separate from it’s presentation and behaviour; but if we do this properly we’ll also be separating accessibility from disability. By concentrating on improving the quality of our HTML and content then we’ll be creating a benefit for all our users regardless of whether they access the site using their mobile, a screen reader or even Internet Explorer. If we approach accessibility not as something that needs to do be done but rather as something that comes out of creating high-quality websites then everyone will be better off, and us web designers can concentrate on what we do best.
I’m going to appropriate a term from advertising, and call this basic accessibility that comes out of good HTML under the line. It’s very not visible, it’s not very glamorous, it should probably even be taken for granted but it does do 99% of the work of creating an accessible site, in this case the line is visibility. By contrast over the line accessibility would include visible techniques that are intrusive on the page, such as on-page text re-size methods, style sheet changers and the like. These are attention grabbing, visible techniques, that more often than not say more about the web site’s desire to look accessible than actually provide genuine help. These features are more about adding usability than accessibility, but by their very nature the designer has to choose one set of people that he will add a usability feature for. The decision that needs to be taken when implementing over the line features is; is there a significant group of people who use the web in a particular non-normal way and can I understand their needs well enough to implement a feature that will be of genuine benefit to them? The time to implement this should be weighed up against the time spent improving the under the line accessibility that will offer benefits to everyone.
I want to be clear that what I’m not saying here is that we do not need to have an understanding of how people with disabilities use the web in order to create accessible websites. Burying our heads in the sand isn’t going to help anything. What I am saying is that we should use our knowledge of how people with disabilities interact with websites to inform ourselves about the errors and problems in how we are currently creating HTML. If something we are doing causes an accessibility problem for someone, we should first look to see how we can create the site in a better way so that that issue just doesn’t arise in the first place. We should not try to bolt on a user specific work-around. This way we’re likely to also be solving the problem for people with disabilities we haven’t thought or or can’t test for.
I’m also not saying that over the line techniques are not useful. They clearly can add value to many sites, but if they seem to be required we should think long and hard about why a site needs them and how we could, and if we should, have built the site differently so that it would have been accessible without adding extra features.
I’m not an accessibility expert, so I’m not trying to set out the last word in accessibility. In this article I’m trying to formulate my thoughts on what can be done day to day in my work, in the reality of the environment I work in. This inevitably involves compromise—that’s just commercial reality, but here I’ve set out an approach that I think, and hope will help to alleviate some of those compromises.
Comments closed for this article.
Comments: