Accessibility of publications is an important consideration due to legislation requiring that all information posted online should be available to all readers, including those with visual and motor skills impairments.
Specifically, Section 508 of the Americans with Disability Act states what it means in terms of access to any digital form of information. This article deals with specifics on how to build your document so that add-on devices (AT) can extract the necessary components of the files and allow special devices to convert the content of the documents from what can be seen to text that can be read out loud.
It should be recognized that most accessibility standards are written for web formats. HTML and XML are tagging standards that drive all web pages. What makes a designer’s job particularly challenging is the fact that many publications are still designed for print on paper and are exported to PDF. These are posted online to be viewed within a web browser.
The PDF format has become a sort of digital paper. It preserves the visual layout of a publication; it allows protecting the content from changes or unauthorized copying; and it is very commonly used as an archive format. However, even though it is often meant to replace physical paper, it is also so much more than that. We can include video (not just static photos), audio, slideshows, and allow for interactivity that is not possible with paper. Since PDF is viewed on digital devices, content needs to be more than visual. This implies that the publication needs to include a structure that can be converted and easily interpreted by devices that are used by persons with disabilities.
PDF, unlike HTML and XML, is not text-based, but originates with PostScript, a computer drawing language, which is essentially a set of instructions for a printing device controlling how to distribute ink on paper. From the accessibility standpoint this causes a problem. PDF is, first of all, a picture. Great improvements have been made in allowing the extraction of text and images. Currently, only Adobe InDesign gives designers options to assign what is relevant information and what is just a visual adornment.
To add confusion to the matter, the presence of PDF accessibility tags alone does not make a document accessible. The order in which they are organized, how their roles are defined, and many more details will make a document accessible or not. Unlike HTML or XML code validators that can find errors in syntax, accessibility issues in PDF extend beyond tags. Accessibility checkers help find errors, but if one reads any disclaimer, you will quickly realize that a document needs to be logically arranged using tags, and that can only be accomplished by a human expert.
Any publication in PDF will only be as good as its construction in the original application. Having spent weeks on remediation of a complex document, I decided to put together a reference to prevent certain problem from happening. Just like the construction of a foundation of a new house should be done right to avoid problems, also a document should be built properly from the start. This is what will assure good quality access for those who are impaired and thus give a publication conformance to Section 508 standards.
If you ever tried to renovate an old house, you will understand the metaphor. All references to fixes, remediation, touch-up, etc., imply that the publication has to be fixed, even though it was just created. Since none of the fixes can be applied to an updated version of the same document, it is easy to see why the focus should be on a proper initial construction.
This article deals with Adobe FrameMaker for Unstructured documents, but the principles discussed should be applied to all commonly-used applications, including Microsoft Word, and Adobe InDesign. Accessibility of publications that include PDF interactive forms will be discussed at a later date.
FrameMaker allows users to export publication content to various formats. HTML, XML, RTF are not discussed here, although similar principles of document construction also apply. I have to also mention Structured FrameMaker documents. These are publications built from the ground up to conform to strictly defined structure standards, making the content easy to share with other applications for digital output. Again, the accessibility of these types of documents is not discussed here.
Fundamentally content of each publication can be divided into text and graphics. Further, text can be grouped into:
Graphics can also be divided into a few basic groups:
All publications begin with written words. We have headings of many levels, body text, lists numbered and bulleted, and so on.
Structure in FrameMaker is created through paragraph and character format tags, known in other applications as styles. On export to a PDF file, FrameMaker converts styles that are used for the purpose of visual formatting to PDF tags that can be used by AT readers to identify headers, lists, bullets, and more. This generally is a straightforward process, provided the needed tags are created in this FrameMaker dialog box on export:
Tags resulting from the conversion should not be confused with HTML type tags. PDF tags are meant to hint at the type of content, so that readers using add-ons, such as JAWS, can navigate through the document and find content of interest. Typical problems, though, are:
Here is how to remedy these problems:
Fixes needed in Acrobat will require editing a Role Map in Acrobat’s Tags panel to convey a structure of document headings and paragraphs. If your paragraph tags are setup and used correctly this should be a very quick adjustment.
FrameMaker has a very long history as a technical document production tool. With it, though, come construction techniques that should no longer be used. This is especially true of tables and figures.
First and foremost tables should not be used for the purpose of layout. Tables should be used only to present and organize data. They can include images, if an image is part of the data.
Tables consist of parts such as the Table Title, Heading and Footing rows and body rows/columns and cells.
Here is a list of bad FrameMaker techniques to avoid:
Figures or charts are typically created in Microsoft Excel. Presently the only graphic export format option is PDF. Those PDF files then can be imported to FrameMaker as images. This creates a number of problems.
Since the exported PDF figure typically contains text (labels, numbers, and legend info), that text is read by add-on software, regardless of how the graph is tagged. Although it contains an ALT text and is simply tagged as <Path>, there is no way to suppress the digital readers recognition of the fonts used in the chart. This results in re-reading of the content of the chart, as an incomprehensible string of numbers and labels. One cannot see this; it is only noticeable when a reading option is on, either by activating Acrobat’s Read Out Loud option, or using JAWS (Job Access With Speech), a commonly used computer screen reader that allows blind and visually impaired users to read the screen either with a text-to-speech output or by a Refreshable Braille display.
One of the solutions to this problem is opening the PDF chart in Adobe Illustrator, converting the text to outlines, saving the file as .AI, and finally placing it in a FrameMaker document. The resulting vector graphic is properly recognized as an image and only an ALT tag is read. However the process has major drawbacks. It requires writers to own and be able to use Illustrator, it is time-consuming, and creates multiple file formats. For those who regularly work with Illustrator this may be an acceptable choice. A major benefit is preserving the artwork in vector format, thus giving a high imgae quality to charts, even when zoomed in for visual viewing.
A simpler process is to open a PDF chart in Acrobat Pro and save it as a bitmap. This converts the content of a chart to pixels. Digital reading software is thus forced to use a description of the graph using ALT text tags. The visual quality of the chart might be a concern, but this can be addressed through acceptable resolution settings.
Another typical problem with figures arises when figures and captions are positioned in FrameMaker table cells for the purpose of keeping them as one object. Discussed under the topic of tables, it is worth repeating in the context of figures. This was a great technique at a time when paper print was the final output—it was easy to keep a single column table as a placeholder. From the PDF accessibility standpoint, though, this technique should no longer be used.
On PDF export, a full set of table tags is created with no actual data. Since an image is placed inside a table, the ALT tag is ignored by the reading software, thus skipping vital information provided by an author.
Instead of using a table for the purpose of formatting or creating a placeholder, create a sufficient number of paragraph tags in the document and use those to position figures as content of anchored frames. Anchored Frame properties allow great flexibility for positioning figures, and the Object properties option allows the author to include ALT text. ALT text tags can also point a reader to a linked expansion file that provides data used to plot a graph.
The main goal of accessibility is to provide access to information contained in a publication in a logical order, without unnecessary clutter. Specialized reading software can provide more than reading. It allows an impaired person to navigate, skip content, and analyze data. All this will work only if the underlying structure is well prepared, before a document is made available online. Authors are well positioned to write content with accessibility in view.
Following the above guidelines will create a rather clean set of PDF accessibility tags. Fixes needed in Acrobat Pro will be rather minor. The Role Map dialog box will need to be used to create a proper structure of headings and lists. Occasionally some elements not properly tagged at the time of export may need to be tagged as artifacts. Acrobat Pro Accessibility Checker will help find areas that need to be touched up.
This is by no means a comprehensive discussion about accessibility in FrameMaker. As the software is updated and both Acrobat and FrameMaker producers are aware of issues faced by readers with impairments, we can expect more automated solutions. However, it all starts with a proper foundation or correct technique, and these choices are made by the publication authors or designers themselves. A project well started is well done.
Book your training today! Click this link to our Onsite Training Request form.