Accessibility for content providers
Database-driven websites are commonplace for many organisations. Content management systems (CMS), blogging tools, etc. are no longer the preserve of large enterprises, and with them the days of requiring a web expert or design agency to put up the latest press release have gone. The balance of control has shifted and now it is the people who create the content in the first place who are able to write their own text.
However with that power comes responsibilities and one of those is to ensure that the website is accessible. For most public sector organisations in the UK this means that they must comply with the double-A (or AA) guidelines of the Web Content Accessibility Guide (WCAG) from the Worldwide Web Consortium (W3C).
Most content providers are focussed on the text that they are creating and how it is to be styled. However at the same time they are involved in generating computer code. That code not only dictates how the text might be displayed visually in your browser but also how it is assessed solely as structured content (e.g. a hierarchy of headings) and delivered to someone (or even to another system such as a search engine) in a different format.
For instance someone with a screenreader can ask that program to give them a list of all the links on a page, because they are not in a position to scan through the text looking for the styling that you’ve decided to use and reading text takes a longer time. However on many sites they might be hearing a whole list of links that say ‘read more’. But read more what? Which one is the link that’s of interest to them? For sighted people it’s quite easy because they can see that there is a list of news items, and for each one there is a title, summary and link that invites them to ‘read more’.
If you start looking around for resources on website accessibility then you’ll find yourself either at the abstract end of the spectrum (I’ve included the links to the WCAG below, but be warned) or deep in geek country. They’re not for the faint of heart. So we’re putting together a series of posts on this blog looking at what issues are relevant when you, as a content provider, are sitting in front of your rich text editor.
What are the issues?
A good place to start, to get an understanding of who we’re doing this for & what issues they face then I would recommend Dive Into Accessibility. The document is aimed at technical bloggers so you can stop reading after Day 5 when he starts to look at how to change the code produced by the blog. This will be the sort of thing that your developers should be concerned about on your website - that is unless you’re running your own blog, in which case you should read the rest of the document.
If you’re feeling brave then you might want to tackle the Web Content Accessibility Guidelines (WCAG). The standard that is in use currently is WCAG 1.0 and you can refer to the Checklist of Checkpoints to see what is required for double-A compliance, for which you’ll need to pass all Priority 1 & 2 checkpoints.
Don’t believe your eyes
One of the most common accessibility problems is caused by users selecting styling on the basis of how the content will appear on the page. The main bugbears seem to be headings and lists, but sometimes the rich text editors throw a spanner in the works with how they implement indented text.
So a short answer is that headings should be marked up as headings rather than making the text bold and the right size; similarly headings shouldn’t be used just to make text bold; lists of items should be marked up as lists even if they don’t have bullet points; and text that you want to emphasise with bullet points shouldn’t be marked up as lists.
Over the course of this series we’ll cover these issues in more depth, but at the moment it’s a question of shifting how you look at your content and how you use the formatting options available. In a number of cases we’ll be suggesting that you go back to your developers & designers and make requests for extra styling options. That will reduce the temptations to stray off the straight and narrow, as for instance you’ll have an option to indicate that a paragraph needs to be highlighted with a bullet point without using styling it as a list.
Beware the copy & paste
Currently the bane of my life.
A client has either received content by email or they’re taking an existing document in say Word and putting it onto the web. So they cut and paste the text, and unfortunately along with it comes a mass of formatting. And then we get the email or phone call asking why the text on a particular page is all different sizes or fonts, what’s happened to their wonderful look & feel that we unveiled for them recently.
Accessibility issues also come into the frame as well. If the content is coming from a format that is used for printing then issues about document structure will have gone by the board. For example it make absolutely no difference on paper if the word-processed document used heading styles or just had the text made bold, increased in size and maybe some extra spacing around it. It still looks the same in print - but it won’t be the same when it is added to a web page.
The easiest way to get yourself out of the mess created by copy and pasting from a program that understands formatting is to put it first into something that has no concept of text styling like Notepad. Copy the text from its source and paste it into Notepad, then copy it again from Notepad and paste it into your rich text editor. That will give you unformatted text that you can then style up.
