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.
Proper Document Construction
Fundamentally content of each publication can be divided into text and graphics. Further, text can be grouped into:
- Body text presented as headings, body paragraphs and lists, such as numbered or bulleted lists
- Data tables, some very simple, some intensely complex.
- Navigational or background text, such as page numbers, headers, footers, etc.
Graphics can also be divided into a few basic groups:
- photos, figures, and charts: those that convey information and thus replace words (following the familiar saying a picture is worth a thousand words)
- logos and the visual branding of a publication
- background images that create a pleasing appearance, such as borders, shaded boxes or lines that separate sections within a publication
Text
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:
- Inconsistent use of paragraph format tags (paragraph styles)
- Numerous manual formatting overrides, contributing to inconsistency
- Difficulty discerning among what is relevant content and what is background art or artifact
- Empty paragraph returns used as spacers
Here is how to remedy these problems:
- Make sure that instead of using manual formatting options from the Paragraph Formatting Toolbar, your publication contains a sufficient number of paragraph format tags (styles). Right from the start, begin building a logical structure through consistent use of headings, lists, captions and other style tags.
- Get familiar with Paragraph Designer properties and use them especially when spaces between paragraphs are needed. Do not use the Enter/Return key to add extra space between lines of text. Instead, use Indent and Spacing Above Pgf and Below Pgf as needed. Use Pagination settings to properly break page text flow. Learn how to use Indents and Tabs to control the position of text, especially inside table cells. Properly setup formatting properties will save you enormous amounts of effort, especially when trying to fix exported tags.
- While exporting to PDF, select all paragraph tags that will become PDF tags source, but be sure that background tags such as headers or footers are not included in the export.
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.
Tables
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:
- Do not create tables that have a single-column, double- row or single-cell with Table Title, to keep an image and a caption together. This is one of the most commonly used FrameMaker users’ tricks that needs to be changed if you don’t want to spend your life manually fixing bad tags in Acrobat.
- Avoid merged cells. Problems in accessibility arise when cells are merged, especially if they are header cells. To the extent possible, provide a column or a row header text that labels the body cells, without the need for merging any cells. If you have to use merged cells, be prepared to edit the table tags extensively in Adobe Acrobat. The Table Editor in Acrobat is not always user-friendly, although it does allow adding cell IDs and scope to TH tags, making them either column or row headers.
- Do not use empty columns, rows, or merged body cells for the purpose of formatting. Instead use paragraph format tag properties in Paragraph designer to assign tab stops and add tabs, if cell content needs to be indented. For spacing columns, use the Resize Column option from the menu to create a desired column width. Empty cells with no content create corresponding tags, thus creating havoc for a reader who without seeing the table grid has to identify cell content.
- Table Title is the only way to add a summary to a table, so use it whenever possible.
- Table footnotes function in FrameMaker should not be used. Table footnotes, a beautifully convenient feature of the past, creates buggy code that requires extensive re-tagging of the table cells in Acrobat. Instead, create cross-references and place the source paragraph at the bottom of the table. If you have multiple references to the same footnote, simply use a number/character inside a table cell. After extensive testing this is the best approach at the moment (written in early 2013). Even though it may require more tweaking of cross-reference formats and paragraph format tags, the bulk of work is done in FrameMaker, not Acrobat, and is thus preserved for future edits. The resulting PDF tags are perfectly acceptable as accessible.
- Images contained in a table need to use ALT text tags, just as all images do.
Figures
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.
Vector vs. bitmap
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.
Placeholders
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.
Conclusion
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.
By Urszula Witherell, Adobe Certified Expert in FrameMaker and Acrobat
Book your training today! Click this link to our Onsite Training Request form.
