Supporting Accessibility with WCAG 2.0 Level AA Compatibility

This fifth blog post in a series of five is the sequel to “Creating mobile friendly website”.

Facilitating the publishing process is not the only benefit resulting from an optimal usage of Microsoft Word. Surprisingly enough, it can also contribute to generating more accessible files, in other words, files readable online by persons with disabilities. A growing number of public bodies are required by regulation to make their online content accessible to all citizens, including those suffering from a visual handicap. The leading standard in this field is the Web Content Accessibility Guidelines (WCAG) 2.0 from the W3C, which many legislators have started to rely upon.This is the case in Australia, Canada, and Hong Kong. Unfortunately for website administrators working in the departments and agencies of those jurisdictions, there is still no user-friendly tool available to ease the conversion of large documents to WCAG 2.0-compliant HTML files.


One leading principle of WCAG 2.0 is that text alternatives must be provided for any non-text content. The objective is to enable the transformation of this content into other forms people need, such as large print, braille, speech, symbols or simpler language. If not necessarily intuitive to use for most authors, various features of Microsoft Word are available to meet this guideline right at the time of drafting. For instance, in Word 2003, alternative text can be inserted on pictures by right clicking on them and selecting Image format… > Replacement Text > Title… . Doing so results in <imgalt=” “/> tags being added to converted HTML files. Similarly, the language of foreign citations can be specified by selecting the text and by defining their languages, thus inserting a <spanlang=””> tag in the HTML. In fact the vast majority of WCAG 2.0 Level AA success criteria can be met simply by using the appropriate features provided by Word.

Hearing It remains that the HTML generated by Word is incompatible with some of the criteria included in the standard. However, here again, cleaning filters applied at the time of conversion can be of tremendous help. For instance missing features can be compensated at this stage by adding required information, such as unique titles for individual table cells. In other cases, existing features can be used to develop workarounds, for example using Word styles to generate summaries for tables. Lexum’s leading accessibility expert, Frédéric Pelletier, estimates that, using these techniques, some clients have been able to achieve 90% compliance with WCAG 2.0 Level AA without requiring any additional human intervention. This can be considered a very high level of success, especially taking into account the fact that most legal documents can simply never be 100% accessible by nature. For instance, the use of underlining by judges to put emphasis on portions of citations is both incompatible with WCAG 2.0 and an integral component of judicial decisions that cannot be removed.

In this context, just as the use of a properly designed decision template allows the Judiciary of Rwanda to fully automate the publishing of its law reports, it also enables it to produce accessible reports if it chooses to do so. Even though a variety of authors (judges) drafted the original files without any regards to accessibility requirements, standardization of the file format eases the application of the appropriate features where needed. The total effort required to implement compliance is obviously limited at this stage, compared with manually editing the HTML files at the end of the publishing process. Again, a compatible publishing platform is all that it takes to reap the benefits associated with the production of accessible documents.