Line in the sand – getting past the legacy content accessibility problem
“Yes, but what about our legacy content?”
That’s one of the biggest barriers to doing something about accessibility that I have to get most of my clients past.
“Do we have to do everything? And, if we can’t make everything accessible, where does that leave us?”
When we initially meet, many organisations that work with me are usually embarrassed about their fragmented history of dealing with accessibility. They reckon some parts of their website (or sites) might be accessible, other parts really concern them, and yet others they haven’t got a clue about.
So it always comes as a relief when I tell them that this is pretty much the case with all organisations of any size, even with those who really care about accessibility.
And the fact that they’ve called me in to have the discussion means that they’re already more committed to the idea of accessibility than many organisations out there. So they’re on the right track.
So let’s throw out the thing which keeps people in embarrassed stasis, shall we?
It is impossible to make your website, app or organisation “perfectly accessible”, however you want to define accessibility.
Voltaire was on to something when he said that:
“the perfect is the enemy of the good”.
So out goes perfection.
For me, Inclusive Design is all about art of the possible. Doing all you reasonably can to make your products work for as many of your potential users as you can.
And that sounds much more achievable than perfection.
Good. Let’s move on…
The thought-enabler of drawing a line in the sand can help us to move forwards in creating an achievable accessibility strategy.
Here are some lines in the sand that I’ve found to help my clients:
Line between new-build and legacy
It’s quite alright to say that you are going to draw a line in the sand between the way you’ve used to do (or not do) accessibility and how you’re going to do it from now on.
The biggest barrier for implementing new quality standards – for that’s really what accessibility is – is the worry that you’ll have to do it retrospectively for all the things you’ve already created.
This is for good reason. Especially in the agile start-up world of the web, no organisation wants to be weighed-down spending much of their attention revisiting their old products.
Moreover, the way you do accessibility for new-build projects is completely different from how you add it to existing legacy content and tools.
Doing accessibility for new-build projects is generally cost-effective, if you plan it in from the start, following an Inclusive Design process such as BS 8878.
But adding accessibility to non-accessible legacy tools and content can be difficult and costly, especially where:
- the technologies used in them don’t facilitate accessibility easily;
- the creators of the tools’ code have left your organisation without good documentation;
- or the tool has been provided by a third-party supplier as part of a contract that did not mention accessibility as a requirement.
So it makes sense for your accessibility strategy to draw that line between new-build and legacy.
And it makes sense to let your users know that you’ve drawn this line by putting it in your accessibility statement.
Most accessibility statements are used by organisations to trumpet what they’ve done to try and make their websites accessible. But they are read by disabled people who only look for the accessibility statement when they’ve found the website isn’t accessible to them.
So, what better place than this to acknowledge to your users that you are aware of deficiencies in your website’s accessibility, that you are working on doing better in the future, and that you’re happy for them to contact you to help you do this?
This provides much better PR, and a much better defence against legal action, than not saying anything to your users at all. The only way you can lose with this strategy is if you don’t follow through and improve accessibility of your new products, and don’t listen to the feedback your users send to you.
Line between worthwhile and non-worthwhile legacy
It also makes sense to do a cost-benefits assessment on all your legacy content and tools, looking into how valuable they would be to disabled users if you made them accessible, the costs of doing that, and only doing accessibility improvements on those that it makes business sense to make accessible. This sort of cost-benefits analysis links in with the idea of ’reasonable adjustments’ in the UK Equality Act 2010.
Again, this common-sense approach to help you move forwards with your accessibility strategy is something that it’s useful to put in your accessibility statement, so disabled people are aware of which aspects of your site you are working to improve, which you aren’t, and how they can let you know if they have a point of view about how you made the decision.
How to ‘fix’ the accessibility of legacy content and tools
Where you’ve decided that it may make financial sense to fix the accessibility of some legacy content or tool, but are being hampered by a lack of ability to easily change its code, a new generation of accessibility tools is evolving to help you.
I’ll blog about these tools as they start to prove their worth, in the future.
But if you have a need for cost-effective accessibility fixes for legacy content or tools right now, please get in touch and I’d be happy to take you through the possibilities.
Need some help with this?
If this blog has touched on issues that your organisation is having at the moment, please don’t hesitate to contact us and we’d be delighted to help you move forwards in creating and implementing a cost-effective strategy to improve your site’s accessibility.
I’m going to be blogging more soon on other barriers that organisations experience in moving forwards with an accessibility strategy – looking next at how to embed accessibility in complex organisations with multiple disconnected business-units or “silos”.
So, if this blog has been useful, sign-up for the Hassell Inclusion newsletter to get more insights like this in your email every other week or so.