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.

Feeling better?

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.

Line in the sand

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.

Want more?

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.

And if you’d like me to blog on a particular accessibility barrier that your organisation is facing, please leave a comment or contact us and I’ll be happy to do so.

Tags:

4 Comments to “ Line in the sand – getting past the legacy content accessibility problem ”

  1. Pingback: October 21, 2012: Weekly Roundup of Web Development and Design Resources

  2. Alison says: Reply

    Great article – A refreshing, honest and sensible approach on accessibility and Legacy content. Its great to know that our organisation is not alone in trying to establish what the “right thing” to do is around legacy content. A line in the sand approach is a great analogy.

    • hassellinclusion says: Reply

      Many thanks for your comments, Alison.

      Yes, your organisation is certainly not alone in having concerns re accessibility of legacy content.

      Glad you like my way proposed forwards.

  3. Chuck Letourneau says: Reply

    Spot on! This message needs to be widely understood (not by accessibility professionals) but by terrified clients facing apparently insurmountable retrofit tasks.

    One additional parameter in the equation (to determine the priority for conversion) can come from mining detailed website usage logs to determine the relative frequency of visits to legacy pages: little usage (in a year?) = lowest priority for conversion. Higher priorities are set as necessary. (And yes, this presumes you can reasonably weed-out search-engine and other crawler visits from your logs.

    By itself, this test will fail if the reason a document isn’t read frequently is because its importance is only triggered by some event, e.g. “Read this page in the event of ‘occurrence’”. That is why document relevance, which you mention, is so important in the equation.

Leave a Comment

Fields with a background colour of light yellow and marked with * are required fields.

Fields with a background colour of red are invalid fields and need re-entry.