Optimizing Workflows for accessible Online Editing
In an older post I presented various test methods. Most testing procedures aim to test prototypes or finished websites. For the small test in between, on the other hand, handychecklists are preferred.
Article Content
Checklists or Workflows
The disadvantage of checklists is that they are usually unsystematic. On the other hand, most onliners use multiple tools and the accessible online editor definitely needs to use multiple programs to make their content accessible. Checklists bring few advantages, they should be replaced by test processes.
A good review process is based on the typical editorial workflow. In the following I want to illustrate this using the example of a text.
The accessible text
Most editors are likely to write their texts in a local text application. Google Docs may have its merits, but if you already have a PC with a word processor installed, you're more likely to use it. The finished text is copied into the editorial system using copy paste. As a rule, the text is first formatted in the editorial system, since MS Word, for example, does some mischief with formatted text and the formatting does not function smoothly in the editorial system. Let's look at all this in detail.
Step 1: Write
First, the text is written in the word processor of your choice. After the first draft of the text is complete, it is checked for completeness. Have I included everything important in the text? The so-called w-questions help: what, when, why, where, who? Depending on the length of the text, we can also check whether the text contains information that is superfluous. Long texts can also be a barrier.
Next, we check whether the structure of the text is consistent. In journalism, it is common to put important information first and push unimportant information further back. Does the first sentence make it clear what the text is about and for whom it is interesting? In this step, further links can also be included, and the final link can be made in the editorial system.
Step 2: Fine tuning
So the content of the text is complete. Now comes the fine work, we check the text for comprehensibility. For example, are there bad formulations, foreign words or expressions that we do not want to use? Our focus is not on the elegance of the text, but on its comprehensibility. We can save the elegance for greeting cards.
The final step in fine-tuning is the spelling and grammar check. Pure text editors are a disadvantage here, since no usable test routine is usually integrated. We could just copy the text over to a word processor, although it pays off if we haven't formatted the text yet. Word and Co. don't like HTML and hit every bit of formatting code, so that the spell check becomes an ordeal.
Step 3: Formatting
When the fine-tuning is complete, we copy the text into our editing system or into the editor, where we do the formatting. As said above, WYSIWYG editors don't like pre-formatted text, so it's recommended to either do the formatting directly in the content management system, or use HTML, Markdown, or something similar. Even that can be problematic if a different character set is used in the editorial system than in the text editor. Therefore, I suggest doing the formatting in the content management system.
Depending on how experienced you are, it may be advantageous to use a checklist at this point. Finally, headings, lists, abbreviations and so on would have to be formatted.
Step 4: The final test
After we have done all this, we still have to check the final document. That wouldn't be a problem with a screen reader, but we use the Firefox Accessibility Extension, which is more beginner-friendly. There are corresponding tools for the other browsers.
As a rule, modern content management systems have a preview mode where the finished HTML structure is already used. If this is not the case, we have to publish the page and check it live .
So we use the Accessibility Extension to check whether headings, lists, abbreviations and so on have been formatted correctly or whether the alternative text for the images has been assigned and makes sense. If that's the case, we're done.
Conclusion
The whole thing looks complicated, but corresponds to the normal way an editor works. We all know that it takes twice to ten times the work to correct a mistake than to avoid it. For example, a forgotten alternative text can mean that we have to go into the content management system, search for the text in question, correct the error and check it again. We can certainly put those ten to fifteen minutes to better use.