Web accessibility is about the capacity of Web content to be used by people with disabilities. It aims at lifting barriers that prevent disabled people from navigating the Web, understanding its content and contributing to it.For the visually impaired, this means that the semantics conveyed by the visual presentation of a document, which is implicit for most people, must become explicit through the underlying HTML markup so it can be interpreted by devices such as screen readers.
Although identified as a key issue as early as 1995 by the founders of the Web, Web accessibility has not been seriously tackled until very recently. More than a decade after the US Congress did so in 1998, European countries and Canada followed suit with sets of guidelines which makes accessibility mandatory for governmental institutions, as a fundamental right. In Canada, the Jodhan case (2012 FCA 161 (CanLII)) confirmed in 2012 that to deny accessibility of government information and services to a visually impaired person amounts to a violation of her Charter equality rights.
The requirements commonly referred to by the statutory authorities with respect to Web accessibility is the W3C’s Web Content Accessibility Guidelines 2.0 (WCAG). These guidelines describe in detail how information and documents should textually describe their graphical content in order to be accessible not only to the visually impaired but also to other disabled users of the internet. The multiple WCAG checkpoints can, with reasonable effort, be implemented in government websites where the source documents are authored by trained personnel, or where the web pages are dynamically generated through programs from databases. Judgments, however, are generally not included in those 2 categories. Posting court or tribunal decisions on the web entails specific challenges, mostly due to the diversity of the drafters. Judgment files are authored by judges with the help of assistants which may or may not use a standard template. Even when using a standard template, they may not have enough time, willingness or knowledge to lay out their documents so that the resulting HTML file is WCAG compliant. More importantly, widely-used word-processing applications are not currently able to generate WCAG compliant HTML. These applications can’t be used as WCAG authoring tools by themselves. Even Microsoft Word’s recent Accessibility Checker does very little in ensuring WCAG conformance of the document’s HTML output. Even after using this tool, you may have a document that is somewhat “accessible” in Word format but if you save your document as HTML, the result is far from being WCAG compliant.
Lexum’s approach to WCAG compliance strives to overcome the challenges entailed by the use of MS Word by courts and tribunals to prepare their documents, so that most barriers to Web accessibility are lifted once these documents are posted on the Web. Once a court or tribunal is committed to following certain editing practices when preparing decision files with MS Word, Lexum’s technology available in Decisia allows for as much WCAG compliance as possible, given the limitations of this application as a Web accessibility authoring tool.
As far as documents are concerned, Web accessibility can be achieved by two general guidelines:
- Create structured content
- Separate information from presentation
Lexum’s approach to the problem relies mainly on these guidelines. Once editing practices are properly implemented by the court or tribunal for the preparation phase of the decision file, Lexum’s HTML conversion technology ensures that the resulting HTML file complies with WCAG.
The preparation phase includes the usual drafting and formatting steps of any decision. Lexum’s requirements in this respect rely on best editing practices using MS Word’s styles and other functionalities. Those already familiar with MS Word’s styles may already be following most of these best practices. For instance, spacing and alignments should be defined through paragraph parameters instead of using empty paragraphs or multiple consecutive tab or space characters. Also, structural elements such as headings, lists, quotations, tables or images should be defined with MS Word’s proper functions. Taking advantage of MS Word’s formatting features already ensures a certain level of WCAG compliance. Since MS Word lacks some of the functions that would allow complete WCAG compliance, a handful of custom styles are then used to mark elements such as inline quotes or table headers. This markup will be used by Lexum’s technology in the conversion phase and help reach a higher level of WCAG compliance.
After the preparation phase, the resulting rich text document is submitted to Lexum’s conversion software. A raw HTML file is first produced with MS Word. As we noted above, this file lacks much of the WCAG markup, so the conversion software runs this raw HTML file through a filter that inserts WCAG compliant markup in the file. The resulting WCAG compliant HTML file is then ready to be posted on the Web via the Decisia platform.
In conclusion, despite the diversity of authors inherent to the preparation of court or tribunal decisions and the fact that MS Word lacks many of the features that would make it a good WCAG authoring tool, Lexum’s approach to WCAG compliance lifts most barriers to Web accessibility of judgments. As the resulting documents are better structured and presented, benefits not only accrue to disabled persons but to everyone accessing those documents.