The Importance of Role Mapping in Acrobat

  • 0
  •  0

When I first began in accessibility some years ago, I had never heard of Role Mapping in Acrobat. I was a PDF remediator, spending hundreds of hours making PDFs accessible, and I had never heard of one of the most powerful accessibility tools available for a production environment. I would guess that this still pretty much the case today. The reason why so many of us did not know about Role Mapping is probably due to the fact that Adobe Acrobat does such a good job of shielding users from what is under the hood. It’s there, however, and very powerful. To enter the Role Mapping world, right-click on the root tag of a document stream, and select “Edit Role Map,” then expand the list in the right panel. You will see many rows of items that look like this:

	/textbox	        /art
	/heading_level_1	/H1 

What this is in PDF code is a Dictionary. A dictionary object is a table that contains associated pairs of objects or terms, in the classic PostScript back-slash notation. The first item is the key object, and the second notation is the value.

Dictionary objects are central to the cross-platform magic of PDFs. They are the Ellis Island where blocks of information from different programs arrive and are translated into pdf. The Role Map sits in the “Accessibility Immigration Terminal;” it takes strange, alien tags and assimilates them into the Acrobat universe. So, if you find a <heading_level_one> tag and realize that this is not an Acrobat tag, take a look in the Role Map entry for /Heading_Level_One:

	/Heading_Level_One        /H1  

This notation means that every instance of <Heading_Level_One> will map to <H1> and behave like a heading.

Accordingly, you don’t have to go all through the tag tree, find every instance of <Heading_Level_One>, right-click it, choose properties, and change the tag to <H1> . You can simply ensure that <Heading_Level_One> is mapped to <H1> in the Role Map Dictionary.

This can be huge, in a large production environment. Here is an example: We’ve all seen tagged pdfs, usually exported from Word that had lists tagged with <Li_label> and <Li_Title>. I remember spending many hundreds of hours manually converting these to <Lbl> and <LBody>, because this was what the organization I worked for required (the fact that some screen readers will read these simply fine today may not have been so true in those days). With the Role Map, all that work could have been accomplished in two minutes by opening the Role Map, choosing “New Item”, and adding these lines to the list:

	/Li_Label            /Lbl   
	/Li_Title 	     /LBody 

Sometimes, within a role map, you will find that one custom tag will map to another custom tag. This is, according to ISO 14289 (PDF/UA), perfectly legal as long as these custom tags eventually map to a standard Acrobat tag:

	/Heading_Level_One		/Section_Heading
	/Section_Heading		/H1	

When Is Role Mapping Likely to Be an Issue in Accessibility Testing?

Incorrect role mappings violate Section 508-1194.22 requirements that there be a text equivalent for every non-text elements in the document stream, and Section 508-1194.31 that requires that:

“At least one mode of operation and information retrieval that does not require user vision shall be provided, or support for assistive technology used by people who are blind or visually impaired shall be provided.”

In Acrobat, the tag tree serves as the DOM that screen readers use to navigate the document; if the tag definitions are thrown off standard by incorrect role mapping, the screen reader user is deprived on several functional levels of a predictable environment in which to navigate and understand the document.

In environments where staff are charged with remediating large numbers of documents without having a good screen reader available–especially JAWS–role mapping issues may go unnoticed because the document “looks” good and passes the Acrobat Accessibility Checker.

There are two levels of hints that indicate that role mapping should be checked. Level 1 hints are manifest in the behavior of Acrobat both with the screen reader and without. Level 2 hints are structural.

Level 1 hints include:

  1. When using the Touch Up Reading Order Tool, while it is set to “structure types”, you find that the structure types it shows do not correspond to the tags in the tag tree. The Structure Types might be referring to the Container Tag of the tagged elements, but in general the reading order tool should show what is being portrayed by the tag tree. If it doesn’t, check the role map dictionary.
  2. Finding that the screen reader renders the content in odd ways, in spite of how the tag tree appears.

Level 2 hints are based on structure. ISO-32000 (The basic PDF Scripture) refers to block elements (text, tables, lists) as either “Weakly Structured” or “Strongly Structured.”

  1. A weakly structured document is often based on HTML or has been exported as a “Tagged PDF” from Wordd. ISO 32000 describes it thus:

    “The document is relatively flat, having perhaps only one or two levels of grouping elements, with all the headings, paragraphs, and other BLSEs [block-level structure element] as their immediate children. In this case, the organization of the material is not reflected in the logical structure; however, it may be expressed by the use of headings with specific levels (H1-H6)(ISO 32000 14.8.8.3)”

  2. Strongly structured documents can be recognized immediately in the Tag Tree: There are a multitude of <Sect>, <Part>, and <Art> tags, often nested three or four deep. Or, there are <Slide> and <Textbox> tags from PowerPoint. These are grouping tags that reflect the parent program’s schemata for organizing the content. Within each <Sect> tag the heading order begins again at <H1>. Programs like InDesign often have many levels to these organizational tags.

After studying the originating documents of PDFs for some years, I’ve come to the tentative conclusion that strongly structured documents are more likely to have Role Mapping issues than weakly structured ones.

How serious can it get? Consider the following role mappings, taken from recently evaluated documents:

		/Artifact 		/Sect
	  	/Textbox		/Sect

This kind of mapping means that all artifacts–items intended to be removed from the content stream of the document–are mapped to a grouping element and thus inserted back into the stream—where they are not wanted. In addition, per ISO 14289 standard tags are not to be remapped, as with /artifact     /Sect.

Another issue is the type or hierarchy of the elements that are mapped to each other. In the example above, the Textbox (ubiquitous in PowerPoint) is mapped to Section. This promotes every container for average text into an independent section that is eligible to have its own heading hierarchy. It is very common to find that all kinds of incoming items are mapped to /Sect–even items that should map to active content tags. This must be changed–either in the tag tree or the Role Map Dictionary, for the document to render properly.

Occasionally, one can encounter a document where everything has been mapped to one type of content; a great example is the pdf of ISO-32000 itself, where, of dozens of elements in its role map, 95% are mapped to <P>, even Figures.

The advantage to having to fix a thoroughly interesting role map is that one has to gain a deep understanding of both the originating software and the Acrobat tag system. However, pressures of deadline may interfere with the enjoyment of such a philosophical journey. Consequently, here are some rough functional guidelines for dealing with role-mapping issues.

  1. If the issues in the document are Level 1 issues–old legacy tags, for example–or if the issues occur in a weakly structured document: by all means use the Role Map to save time.
  2. If the issues with the document are with Level 2 issues: a highly structured document with dozens of imported roles from Frame Maker, PowerPoint or InDesign:
    • Ascertain whether you have permission to change the document from strongly structured to weakly structured–by retagging it.
    • If you have such permission, by all means retag the document. You will gain 90-95% functionality in the tag tree that results, and can use the Role Map to deal with recurring legacy tags.
    • If you don’t have such permission, in the Role Map find the five most critical or recurring roles that are presenting problems and change them. Experiment with the screen reader to fine-tune the output.

No Comments

    Leave A Comment