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.

What are ARIA Landmarks?

ARIA landmarks are attributes you add to elements to create semantically defined sections of a page that allow users of assistive technologies to navigate the page more easily. Think of ARIA landmarks as building a set of “skip to” links like “skip to main content”. You can add ARIA landmarks to define the following regions.

• application
• banner
• complementary
• contentinfo
• form
• main
• navigation
• search

By adding these landmarks you are in essence building a set of “skip to” links to allow users to jump to any of these sections and know what the function of each section is.

Adding ARIA Landmarks

Adding ARIA landmarks is very simple. You just need to add an attribute like role=”main” to the appropriate encompassing element. For example, if you have

<div id=”mainConent” role=”main”>…</div>

everything within the <div> will be considered the main content of the page. Similarly, if you have

<div id=”nav” role=”navigation”>…</div>

the contents of that <div> will be defined as the navigation section.

In addition to the role attribute, you can also add the aria-labelledby attribute to explicitly label each section. This is useful for a role like “complementary” where some part of the page is not considered the main point of the page but compliments the main point. A user can jump to this complementary section and know what it is about. For instance, on an “About Us” page on a school Web site that is describing the school, there might be a section off to the side that is showing live score updates from the sports teams. The score information is complementary to the main point of the page but still has important meaning. The code for something like this would look like

<div id="mainContent" role="main">
   About Us
   ....
</div>

<div id="scores" role="complementary" aria-labelledby="scoresLabel">
   <h3 id="scoresLabel">Live Scores</h3>
   ...
</div>

This way the user knows exactly what is in the complementary section. Adding ARIA landmarks will have no visual impact on your page so they are an easy way to add more accessibility to your Web page.

Does This Mean I Don’t Have to Provide a Separate “Skip To” Link?

ARIA Landmarks are fairly well supported in screen readers so most users will be able to take advantage of them. There are some older screen readers that don’t support them and some users with newer screen readers might not know how to use this feature. The most helpful data we have on this comes from WebAIM’s screen reader survey. While it shows a 42% increase in awareness of ARIA landmarks over the past year, only 40% of people indicate they use them, and a full 30% still don’t know that the functionality event exists. That being said, if you only provide ARIA landmarks you will be meeting the letter of the law in terms of providing a way to easily skip repetitive navigation, but not providing the traditional “skip to” links will probably make your site more difficult for some screen reader users to navigate. As with almost everything on the Web, we live in the in-between times where newer and better technologies are out there but adoption isn’t high enough to make it the de facto standard. For now, I would still include the “skip to” links in addition to ARIA landmarks.

A Working Model of ARIA Landmarks

Here is a working model of ARIA landmarks with explanations for how to use the various roles.

More Information

W3c ARIA Authoring Practices

Another blog post about using ARIA Landmarks

HTML5 Section Elements and ARIA Landmarks

The Problem

Indicating that a particular form field is required can prove problematic for people with visual disabilities. Here is how a required field is normally implemented.

First Name

Required

The problem with this is the text “Required” is hardly ever heard by a screen reader user since it is not part of the label.

Solution #1

The main option to make the “required” message accessible has been to include the “required” text with the form label itself.

First Name (required)

Please note that this is a perfectly accessible and correct implementation, however, some people don’t like to implement it this way because it impacts the aesthetics of the page too much.

aria-labelledby to the rescue

By using aria-labelledby you can simply make both “First Name” and “Required” into labels.

<p>
   <span id="firstNameLabel">First Name</span>
   <input type="text" name="firstname" id="firstname" aria-labelledby="firstNameLabel firstNameRequired" />
   <span id="firstNameRequired">Required</span>
</p>

When a screen reader user enters this form element, they will hear something similar to “First Name. Required. Edit. Blank.” Here is a working demonstration of this technique. This blog cannot properly display input elements with aria-labelledby attributes within the post, so the examples must be viewed from a different site.

The Problem

Web forms frequently ask for a single piece of information that is broken up into multiple input fields. The most common examples of this are dates, phone numbers, and Social Security numbers. The problem with these is that the way they are frequently implemented can cause difficulties for people with certain disabilities, and they also don’t technically meet accessibility standards. Here is how they are frequently implemented.

Select a date

Here are the problems with this technique.

1. “Select a date” is a label (although many times it isn’t even made into a label) but it is not attached to a form element. That is understandable because which form element would you attach it to. You are only allowed to associate a label with one input element, so it usually does not get associated at all.
2. When the user goes to each of the “Month”, “Day”, and “Year” input elements, since there is no explicit label the user must guess from the context what is being asked for. I daresay most screen reader users have probably become quite adept at this skill out of necessity. Additionally, screen readers applications now attempt, with varying degrees of success, to discern a relationship between two elements when none is explicitly defined. Screen reader users will usually hear something like the following when trying to enter information.
   1. When entering the month, “Select a date. Combo box. Jan. To change the selection use the arrow keys.” (It’s possible they won’t even hear “Select a date”)
   2. When entering the day, “Combo box. 1. To change the selection use the arrow keys.”
   3. When entering the year, “Combo box. 1990. To change the selection use the arrow keys.”

Solution

We can make a much more accessible implementation of this using the aria-labelledby attribute in place of explicitly tying a form label to an element with the “for” and “id” attributes. The aria-labelledby attribute lets us attach multiple labels to a single input element. In the following code each input element is linked to two different text elements by the aria-labelledby attribute.

<p>
   <span id="selectDate">Select a date</span>
   <span id="monthLabel">Month</span>
   <select name="month" id="month" aria-labelledby="selectDate monthLabel">
      <option value="Jan">January</option>
      <option value="Feb">February</option>
      <option value="Mar">March</option>
      ...
   </select
   <span id="dayLabel">Day</span>
   <select name="day" id="day" aria-labelledby="selectDate dayLabel">
      <option value="1">1</option>
      <option value="2">2</option>
      <option value="3">3</option>
      ...
   </select>
   <span id="yearLabel">Year</span>
   <select name="year" id="year" aria-labelledby="selectDate yearLabel">
      <option value="1990">1990</option>
      <option value="1991">1991</option>
      <option value="1992">1992</option>
      ...
   </select>
</p>

In this case a screen reader will read something similar to the following:

• When entering the month, “Select a date. Month. Combo box. January. To change the selection use the arrow keys.”
• When entering the day, “Select a date. Day. Combo box. 1. To change the selection use the arrow keys.”
• When entering the year, “Select a date. Year. Combo box. 1990. To change the selection use the arrow keys.”

Here are two working example of this technique with some CSS styling. This blog cannot properly display input elements with aria-labelledby attributes within the post, so the examples must be viewed from a different site.

The Catch

If you implement your form in this way you may run into an issue. Some accessibility checkers will say it’s invalid because you are not explicitly tying a <label> to an <input> element. In my opinion this is a perfectly valid way to present a form and the accessibility checkers need to update their criteria. This is an example of where machine validation doesn’t rule the day.