Providing information in accessible format to people with disabilities is becoming increasingly important as organisations better understand the financial, moral, and legal benefits. Progress can already be seen in the design of some websites but less progress has been made in providing accessible PDF documents. This is partly an historical problem because many years ago there was no accessible PDF format. More recently it was felt that there were no good tools for creating accessible PDF. Even now there is still a common belief that creating accessible PDF is both difficult and expensive. In reality there are now tools available to do the job well, even if the choice is fairly limited.

Up to now creating accessible PDF has been considered a two-stage process:

• Converting the source document into a tagged PDF. This function is either built-in, or available as a plug-in, to Open Office, Lotus Symphony, or Microsoft Office.
• Testing and re-mediating this tagged PDF to make it fully accessible. These functions are provided by Adobe Acrobat or NetCentric CommonLook.

When an error is identified there are two possible methods available for fixing it. The simple way is to use the tool to fix the PDF. The other is to go back to the source and make changes that will produce a better output next time. The advantage of changing the source is that future versions of the document will not create the error. The problem with this method is that it is relatively expensive; the change has to be made by the author and then the whole document retested and potentially remediated and this cycle may have to be repeated more than once.

This is a classic example of picking up errors late in a development cycle with the inevitable high costs. This is a well documented problem in software development where it is generally agreed that the cost of fixing an error goes up by an order of magnitude between coding and testing.

Only being able to check for accessibility in the testing and remediating stage is rather as if spell-check was only available to the editor and not to the author of a document. If that was the case the editor would have to mark-up the document with the spelling mistakes and pass it back to the author for updates.

What was needed was a spell-checker for accessibility, an 'access-checker', that would pick up any issues in the source document which might convert incorrectly or incompletely. At CSUN NetCentric announced the beta version of PAW (PDF Accessibility Wizard) for MS Word that provides exactly this function.

PAW is an add-in to Microsoft Office Word 2007. The checks and tests are started by a 'save to accessible PDF' command. This command runs all the checks, issues any prompts for additional information, and then creates the final accessible PDF file. For example if the author has inserted a table into the document PAW will prompt for a description of the table and information about column and row headings. Where the information can be added to the source Word document this will be updated, in the case of information which cannot be added to the source (such as table row headers) then this will be noted separately and reused if the save command is repeated on the same file.

The output of the save is thus both an accessible PDF and an improved Word document. The improved Word document could then be used to create a DAISY file providing an alternative accessible format.

The checks and prompts are based on NetCentric's experience with the testing tool in Common Look for Adobe for Section 508. Having a deep understanding of what checks need to be made by the editor, to ensure compliance, made it easier to develop a comprehensive set of prompts and checks for the author.

An author answering the prompts at the time of writing, when the ideas are fresh in their mind, should be much easier than having to add them in at a later date, when the document has to be reread to refresh the thoughts. The author should be much more willing to add the extra as part of the flow rather than as a later distraction.

The advantage of this solution is that it is one step instead of two, because the conversion, testing and remediation are all performed together. Besides the obvious requirement for Word 2007 there are no other prerequisites.

The access-checker will reduce the number of iterations between the author and the editor hence reducing the overall development time and the total cost. The lack of prerequisite software will also reduce the total cost of a Word to accessible PDF solution. Bloor Research believes that it should pay for itself very rapidly in reduced staff and software costs.