Testing Accessibility as a Web Editor

There already exist a lot of often very complex testing routines or processes for developers of accessible websites. But they are in most cases not useful for web editors who want to check if their text or images are accessible. They mostly work with checklists.

The problem is that these checklists aren't specified to the usual work flow of the editor. For example you edit a photo in Gimp. You upload the photo to your website and then you see that the contrast is not high enough. You then have to restart your editing in Gimp and upload the photo again only to see that the size of the photo is too small and so on.

Instead of this procedure I want to suggest the use of a check process instead of a check list. The process can be inspired by the usual working flow and so decreases the count of mistakes which can be made in every working step. Let us take a look on a concrete example, the accessible text.

The accessible text

Most editors write their texts in a desktop word processor like Word or Writer. For web writers it is the best practice to choose a style sheet which styles the text automatically as it will look on the website. As a result you see if there are to short or too long paragraphs before your put your content online. The word processor is also the place to check spelling or grammar mistakes.

First step: Writing

First of all you write the text in the word processor. The next step is to check the content on completeness: Are all necessary information’s contained? Can I delete some unnecessary information or shorten the text? Did I answer all the W-Questions, who, why, where, when...?

In the next step we check the logical structure of the text. In most cases we use the journalistic practice: The first sentence tell us the topic and target group following content give us the most important information, the text follows the reverse pyramid, how we call it in Germany. Important information’s stand first and the importance of facts decreases as the text goes by.

Second step: Fine-tuning

After we closed the informational editing we can start the fine tuning of the text.

The next step is to check the expression, is the text understandable and does it meet our corporate language? For this part you can use a checklist, for example a blacklist of undesirable words or phrases.

The next step is to check spelling and grammar errors. For this task you can of course use the check routine of the word processor most editors read the text after the check routine one more time carefully. I'm a friend of the Two-Eye-Principe, that means that a second person should proof read the text for content or grammar errors.

Third step: Formatting

The next step is to format the text. It depends of your Content Management System, where you want to do this. In my experience most editors prefer to format the text in the CMS. Here you find different approaches: Some systems works with a WYSIWYG mode, some uses HTML and some Wiki syntax. HTML or Wiki syntax you can write in your Desktop software as good as online, it depends of your working method. I prefer to write the code myself this is easier for me because I'm blind.

In most cases it is not advisable to copy a formatted text from your word processor to a WYSIWYG CMS, because the result can make a lot of work in the correction.

For the formatting it can be useful again to use a checklist depending on how complex your requirements are. Do you have to format abbreviations, foreign languages and so on? In this case it is useful to make a short checklist.

Step 4: The final checking

After you did the formatting and save the text you have to make the final check up. This step again depends of your CMS; the final check demands that you get the Website rendered like it looks online. Perhaps you have a HTML preview. If not, you have to publish the Site and check it online.

For this step you can take a Browser toolbar or bookmarklets.

With the Web Developer Toolbar you can check a lot of things like alt texts for images, headings or abbreviations. I would suggest making a small check process for this step, for example, you first check headings, then abbreviations, then alt texts and so on.

In this step you have to check two things:

Are all elements formatted, that should be formatted? And are they formatted correctly?
Are elements formatted, that should be not formatted?

Conclusion

That seems to be very complex, but it is in fact not. Sure, the first establishment of such a process means a lot of work. But once established all editors can use the process for their daily work. It saves time because it decreases the count of mistakes. It costs more time to correct a mistake than to avoid mistakes. Every mistake can increase the time you spend on that special issue.

The second advantage is that you can integrate these steps in your normal work flow. When you see accessibility as an extra working step it is clear that it costs you a lot of time. When you integrate it in your daily work flow you change your view on this topic, it will be a natural part of your work like spell checking or link cheeking.