This is the first in a series of posts on ways you can, and cannot, create accessible PDFs from various applications.

Microsoft Publisher is most commonly used as an authoring tool for creating print materials like fliers, handouts, and brochures. A common practice is to also create a PDF version of the brochure to either email to people or post online. So is it possible to create a fully accessible PDF using only Microsoft Publisher? In short, sometimes, but only for simple layouts and it will still take you a fair amount of work. If you just want the moral of the story without all the gory details, avoid using Microsoft Publisher to create PDFs because it is too difficult to do, unless the document has an extremely simple layout and structure. Here are the issues to contend with.

Alternative Text

As with most Microsoft products, any image in Publisher can have alternative text added to it. You need to simply select the image and chose “Format Picture” from the context menu. Then in the “Web” tab enter the alternative text.

The problem occurs when you want to mark an image as a decorative image and you just want to make the alternative text an empty string so screen readers will ignore it. The problem is you cannot set the alternative text to an empty string in Publisher. You basically have two choices

1. leave the alternative text field blank
2. put a single space in the alternative text field

The problem is different screen readers handle these cases differently. If you leave the alternative text blank, JAWS reads each of the images while NVDA ignores them. If you make the alternative text a single space, JAWS ignores the images but NVDA reads each image. VoiceOver ignores all alt text, whether it is empty, a single space, or has real text in it.

In this case there is no best solution for how to add alternative text for decorative images directly from within Publisher. The best solution involves going into Adobe Acrobat and explicitly setting the image as a background object.

Reading Order

This is the most tedious issue to deal with in Publisher. Screen readers will read the objects on the screen in the order they were created. Technically, screen readers read the objects in the order they appear in the stack (z-index). Screen readers will read items furthest back in the stack first and items closest to the front last. Armed with this knowledge you will now need to go through your entire document and systematically select each item individually and choose to “Bring to front”, starting with the first item that should be read first and ending with the last item to be read. The only way to check that you got it right is to open the document in Adobe Acrobat and either use the built-in “Read Out Loud” feature or use a screen reader. Of course, if you missed anything you will have to repeat the previous process almost in its entirety.

Unless your document has a very basic layout this fact alone should deter you from using Publisher to create accessible PDFs.

Semantic Structure

By default, all text entered in Publisher is rendered as paragraph elements in the PDF. In order to add semantic structure to your document, in Publisher you will need to explicitly use styles like “heading” when you have a heading on the page. Even when you add a “Heading” from the “Page Parts” menu in Publisher it is still rendered as a paragraph element in the PDF, so you must go through and explicitly assign the correct style.

If you use other objects like tables there is no way to make them accessible directly within Publisher. That work will have to be done directly in Adobe Acrobat.

In order to check if you have properly assigned headings to all of the necessary elements you will need to either

1. manually click through each element in Publisher to double check which style is assigned to the element.
2. open the document in Adobe Acrobat and inspect the reading order and object properties
3. use a screen reader to ensure each heading is being rendered as a heading

Exporting the PDF

When exporting a Publisher document as a PDF you MUST choose “Save as” from the file menu and choose the file format of “PDF.” In the “Options” you must then check “Document structure tags for accessibility”. If you simply choose “Save as Adobe PDF” from the file menu it will not create an accessible PDF.

Summary

You should probably avoid using Publisher to create accessible PDFs unless your Publisher document has a very simple layout and does not use decorative images. You will end up doing a lot of extra work with a tool set that is not designed to build in and test for accessibility, or you will need to correct errors directly in Adobe Acrobat. If you do make changes directly in Acrobat, if you ever re-export the PDF from Publisher, you will need to repeat all of the manual changes you made in Adobe Acrobat.

How To Display Read-Only (or Non-Editable) Parts of a Form

How should you display the parts of a form that are read-only? There are three main implementations that I have seen, and unfortunately the accessible version is the one I’ve seen used the least. The problem arises from the the way the screen readers interact with forms in Web pages. When a screen reader encounters a form it switches into “forms mode.” In this mode the screen reader will only read the form input elements and any corresponding labels. If additional plain text is inserted between two form elements, the screen reader will skip over the plain text and go directly to the next form input field.

Take the following three examples. In each of these examples the First Name, Last Name, and Email Address fields should be editable, but the Login ID should be non-editable and read-only.

Correct Implementation

Making the “Login ID” field and the data “jdoe” both form elements allows the proper semantic meaning to be defined, and also allows for screen reader users to more easily read this information. Using the readonly attribute prevents users from changing any of the information. Additionally, CSS can be used to make it clear that the input element is not editable. In this example the border is removed from the input field. When a screen reader user encounters this form their screen reader will switch to “forms mode” and they will very easily be able to read the “Login ID” information because it will be part of the form. Screen reader users will also know that the field is read only.

<form name="form1" method="post" action="">
 <p>
   <label for="first">First Name</label>
   <input type="text" name="first" id="first" value="John">
 </p>
 <p>
   <label for="last">Last Name</label>
   <input type="text" name="last" id="last" value="Doe">
 </p>
 <p>
   <label for="login">Login ID</label>
   <input name="login" type="text" id="login" readonly value="jdoe" style="border:none;">
 </p>
 <p>
   <label for="email">Email Address</label>
   <input name="email" type="text" id="email" value="jdoe@internet.com">
 </p>
</form>

Incorrect Implementation #1 – Unattached Form Labels

Making the “Login ID” field a label element and the data “jdoe” plain text is a popular implementation because the “Login ID” is still visually “labelling” something on the page. The problem is that label elements can only provide semantic meaning for a form input element. Without explicitly declaring that relationship, the user will have to intuit the relationship between “Login ID” and “jdoe”. Additionally, when a screen reader user interacts with this form, they will most likely not even know this text exists because when in “forms mode”, a screen reader will not read this text. The screen reader user would have to explicitly change their reading mode and go looking for information that was missed the first time they read through the page.

<form name="form2" method="post" action="">
 <p>
   <label for="first2">First Name</label>
   <input type="text" name="first2" id="first2" value="John">
 </p>
 <p>
   <label for="last2">Last Name</label>
   <input type="text" name="last2" id="last2" value="Doe">
 </p>
 <p>
 <label for="login2">Login ID</label>
 jdoe </p>
 <p>
   <label for="email2">Email Address</label>
   <input name="email2" type="text" id="email2" value="jdoe@internet.com">
 </p>
</form>

Incorrect Implementation #2 – Not Using Form Elements

This implementation treats both the “Login ID” field and the data “jdoe” as plain text. This is a popular implementation because the user should not be able to edit the information, so why should it be a form element at all? Visually this works, but semantically and for screen reader users it is problematic. The information should be part of the form, but it should be treated as read-only. When a screen reader user interacts with this form as it is now, they will most likely not even know this text exists because when in “forms mode”, a screen reader will not read this text. The screen reader user would have to explicitly change their reading mode and go looking for information that was missed the first time they read through the page.

<form name="form3" method="post" action="">
  <p>
    <label for="first3">First Name</label>
    <input type="text" name="first3" id="first3" value="John">
  </p>
  <p>
    <label for="last3">Last Name</label>
    <input type="text" name="last3" id="last3" value="Doe">
  </p>
  <p>Login ID<br />jdoe</p>
  <p>
    <label for="email3">Email Address</label>
    <input name="email3" type="text" id="email3" value="jdoe@internet.com">
  </p>
</form>

When there are a bunch of “read more” links on a page, it is usually fairly obvious from visual cues what the “read more” refers to. However, when screen reader users encounter a bunch of “read more” links on a page, it is not always obvious which part of the page each “read more” link refers to. A simple solution is to use a bit more descriptive text than simply “read more” and use CSS to hide the additional text. In this example the following code is used.

<p><a href="#">Read more <span class="offscreen">About NC State</span></a></p>

This is the CSS rule.

.offscreen {
position:absolute;
left:-999px;
width:1px;
height:1px;
top:auto;
}

Notes:

• The off-screen text needs to be included in the <a> as well, otherwise it won’t be read correctly by screen readers.
• You cannot use the CSS rule display:none or visibility:hidden as that will make the content invisible to screen reader users.
• This code is not unique to me. It is the compilation of different examples I have seen in various accessibility forum posts. I just want to put this example in writing for others.

Here is an example of this code technique.

What about using the title attribute of a link? Screen readers usually never read that text so it’s not a good idea to depend on that as a solution. Ian Pouncey has a good write up about why not to use the title attribute.