Although you can create accessible PDF files in several programs, Adobe Acrobat Professional is required to evaluate, repair, and enhance the accessibility of existing PDF files.

Tags Pane

The Tags pane allows you to view, reorder, rename, modify, delete, and create tags. Many of these actions can be completed more easily using the TouchUp Reading Order tool, but there are some actions that can only be accomplished in the Tags pane.

To view the Tags pane, select View > Show/Hide > Navigation Panes > Tags. This pane displays the all the tags within the PDF, organized in a tree structure. This tags tree can be navigated, expanded, and collapsed using a mouse or the arrow keys on the keyboard.

Many of the tags are similar, if not identical to HTML. The most notable exception is the tag, which is similar to the tag in HTML.

How To

Highlight Content

• When the Highlight Content option is selected in the Options menu, selecting a tag should highlight the corresponding text, image, or other element in the PDF file.

Find Tag from Selection

• Just as selecting a tag highlights the content in the body of the PDF file, there is a way to accomplish the opposite effect of highlighting the tag that corresponds to selected content. First, click on the  Select Tool. Next, select text, an image, or a table. Finally, select the Options menu at the top of the Tags pane and then select Find Tag from Selection. This will highlight the tag or tags that contain the content you previously selected.

Change Tags

• At times, you will encounter a PDF file that contains incorrect tags. You can modify these by right-clicking the tag you want to change, selecting Properties, then the Tag, and then selecting the appropriate new tag type from the dropdown list labeled Type.

Add tags to an Untagged Document

• To add tags to an untagged document, choose Tools from the right-hand menu, then select Accessibility > Add Tags to Document. This process can sometimes be time-consuming, and you will almost certainly have to edit some of the tags, but it is usually faster than doing all the work manually. This is especially true if the document contains tables.

PDF files are not typically created in Acrobat. They are usually created in another program and converted to PDF. There are dozens or probably hundreds of programs that can create PDF files, but very few of them produce tagged PDF files. If you are using Microsoft Word or PowerPoint, OpenOffice.org Writer, or Adobe tools such as InDesign, you can often create accessible, tagged PDF files without opening Acrobat. Of course, the accessibility of the PDF depends on the accessibility of the original document.

Microsoft Word

The majority of the PDF files on the web were probably created in Microsoft Word. The good news is that it is possible to create accessible PDF files in Office, as long as the following requirements are met:

1. The file must be accessible. That includes providing alternative text for images, proper headings, appropriate link text, etc. For more information, read the WebAIM tutorial on Microsoft Word.
2. Office 2000-2003 users must have Acrobat installed, as well as the add-in.
   Office 2007 users must have either Acrobat or the Microsoft PDF add-in installed.
   Office 2010 users can create tagged PDF files natively or with the Adobe add-in.
3. The file must be exported correctly. If a file is created by printing to PDF, it will not be correctly tagged.

Tips and Tricks

• Choosing appropriate text alternatives:
  Imagine that you’re reading the web page aloud over the phone to someone who needs to understand the page. This should help you decide what (if any) information or function the images have. If they appear to have no informative value and aren’t links or buttons, it’s probably safe to treat them as decorative.Decorative images don’t add information to the content of a page. For example, the information provided by the image might already be given using adjacent text, or the image might be included to make the website more visually attractive.In these cases, a null (empty) alt text should be provided (alt="") so that they can be ignored by assistive technologies, such as screen readers. Text values for these types of images would add audible clutter to screen reader output or could distract users if the topic is different from that in adjacent text. Leaving out the alt attribute is also not an option because when it is not provided, some screen readers will announce the file name of the image instead.
• Prioritize information in text alternative:
  Aim to put the most important information at the beginning. Include “Clemson University, Clemson South Carolina” in the alt tag for SEO purposes.
• Length of the text alternative:
  The alt text should be the most concise description possible of the image’s purpose. If anything more than a short phrase or sentence is needed, it would be better to use one of the long description methods.Complex images contain substantial information using long description methods are typically:
  • graphs and charts, including flow charts and organizational charts;
  • diagrams and illustrations where the page text relies on the user being able to understand the image;
  • maps showing locations or other information such as weather systems.

  In these cases, a two-part text alternative is required. The first part is the short description to identify the image and, where appropriate, indicate the location of the long description. The second part is the long description – a textual representation of the essential information conveyed by the image. Remember that complex images can be difficult to understand by many people – in particular people with learning disabilities and people with low vision. Long descriptions benefit many people, and it is good practice to make them available to everyone, for example, as part of the main content. It may also be possible to reduce unnecessary complexity in your images and make them easier to understand for everyone.

  It is also good practice to refer to and summarize more complex images from the accompanying text. For example, a reference such as “The following graph shows that visitors were lost in the first quarter, but the numbers recovered in the second quarter” helps to point out the relevant information that the image is intended to present.

• Punctuation within alt attributes:
  • As for any text, using punctuation in the text alternative makes the information easier to understand. In particular, remember to add space characters in the alt text when there’s no space character between the image and adjacent text, to avoid having words running together when they are read by a screen reader.
  • If you use a null (empty) text alternative (alt="") to hide decorative images, make sure that there is no space character in between the quotes. If a space character is present, the image may not be effectively hidden from assistive technologies. For instance, some screen readers will still announce the presence of an image if a space character is put between the quotes.
• Superfluous information in the text alternative:
  Usually, there’s no need to include words like “image”, “icon”, or “picture” in the alt text. People who can see will know this already, and screen readers announce the presence of an image. In some situations, it may be important to distinguish between paintings, photographs, or illustrations, etc., but it’s best to avoid the more generic use of the terms.
• SVG graphics:  Scalable Vector Graphics (SVG) is an XML-based vector image format for two-dimensional graphics with support for interactivity and animation. The SVG specification is an open standarddeveloped by the World Wide Web Consortium (W3C) since 1999.SVG images and their behaviors are defined in XML text files. This means that they can be searched, indexed, scripted, and compressed. As XML files, SVG images can be created and edited with any text editor, as well as with drawing software.All major modern web browsers—including Mozilla Firefox, Internet Explorer, Google Chrome, Opera, Safari, and Microsoft Edge—have SVG rendering support.
  • SVG graphics can be referenced in the src attribute of an <img> element like other image formats (PNG, JPEG, GIF).
  • As SVG images consist of tags like HTML, their code can also be used in HTML5 directly. In this case you can provide a text alternative in a <title> element within the SVG image. To improve accessibility support, that title should be referenced from an aria-labelledby attribute of the <svg> element, for example:<svg aria-labelledby="svgtitle1"> <title id="svgtitle1">Settings</title> [other svg code] </svg>
• Logos:
  Logo images with text are exempt from some of the accessibility requirements. For instance, there is no minimum contrast requirement.

Web Forms

Forms are commonly used to provide user interaction on websites and in web applications. For example, login, requesting information, registering, commenting, and purchasing. The same concepts apply to all forms, whether they are processed client or server-side.

Aside from technical considerations, users usually prefer simple and short forms. Only ask users to enter what is required to complete the transaction or process; if irrelevant or excessive data is requested, users are more likely to abandon the form.

• Labeling Controls:
   Use the <label> element, and, in specific cases, other mechanisms (e.g. WAI-ARIA, title attribute etc.), to identify each form control.

  <label for="firstname">First name:</label>
  <input type="text" name="firstname" id="firstname"><br>
  
  <input type="checkbox" name="subscribe" id="subscribe">
  <label for="subscribe">Subscribe to newsletter</label>
  

  The title attribute can also be used to identify form controls. This approach is generally less reliable and not recommended because some screen readers and assistive technologies do not interpret the title attribute as a replacement for the label element, possibly because the title attribute is often used to provide non-essential information. The information of the title attribute is shown to visual users as a tool tip when hovering over the form field with the mouse.

• Grouping Controls:
  Use the <fieldset> and <legend> elements to group and associate related form controls.Grouping related form controls makes forms more understandable for all users, as related controls are easier to identify. It also makes it easier for people to focus on smaller and more manageable groups rather than try to grasp the entire form at once.
  The <fieldset> element provides a container for related form controls, and the <legend> element acts as a heading to identify the group.The legend for a group of controls can also highlight common attributes of all controls, for example, to advise that all fields in the group are required.

  <fieldset>
  <legend>Output format</legend>
    <div>
      <input type="radio" name="format" id="txt" value="txt" checked>
      <label for="txt">Text file</label>
    </div>
    <div>
      <input type="radio" name="format" id="csv" value="csv">
      <label for="csv">CSV file</label>
    </div>
    […]
  </fieldset>

  Depending on the configuration, some screen readers read out the legend either with every form element, once, or, rarely, not at all. To accommodate this consider the following:

  • Make the legend as short as possible for situations in which it is read together with the label each time.
  • Make the individual labels sufficiently self-explanatory for situations in which legends are not read aloud, without repeating the legend in every label.
• Form Instructions: Provide instructions to help users understand how to complete the form and individual form controls.
  Provide instructions to help users understand how to complete the form and use individual form controls. Indicate any required and optional input, data formats, and other relevant information.Important: Screen readers often switch to “Forms Mode” when they are processing content within a <form> element. In this mode they usually only read aloud form elements such as <input>, <select>, <textarea>, <legend>, and <label>. It is critical to include form instructions in ways that can be read aloud. This will be explained further below.

  In addition to overall instructions, it is also important to provide relevant instructions within the labels of the form controls. For example, to indicate required input fields and data formats in the text of the labels.

  <label for="expire">Expiration date (MM/YYYY): </label> <input type="text" name="expire" id="expire">

• Placeholder Text: Provides instructions or an example of the required data format inside form fields that have not yet been edited by the user.Placeholder text is usually displayed with lower color contrast than text provided by users, and it disappears from form fields when users start entering text. If the placeholder text contains instructional information or examples that disappear, it makes it more difficult for users to check their responses before submitting the form.While placeholder text provides valuable guidance for many users, placeholder text is not a replacement for labels. Assistive technologies, such as screen readers, do not treat placeholder text as labels. Moreover, at the time of writing this tutorial, placeholder text is not broadly supported across assistive technologies and not displayed in older web browsers.

  <div> 	<label for="search">Search:</label> <input type="text" name="search" id="search" placeholder="e.g. Apple Pie"> </div> <div> 	<label for="email">Email: </label> <input type="text" name="email" id="email" placeholder="joe@example.com"> </div>

• Validating Input: Validate input provided by the user and provide options to undo changes and confirm data entry.In addition to providing instructions, validate user input to help users avoid mistakes. HTML5 defines a range of built-in functionality to validate common types of input, such as email addresses and dates. In some situations, such as validating custom controls or supporting legacy browsers, additional scripting may be necessary to validate user input.

  Forms frequently include required input that needs to be clearly identified using labels. Also, the requiredattribute can be added to form controls, to programmatically indicate that they are required. Most current web browsers support this attribute and will communicate missing required input to the user, using standard web browser dialog mechanisms. These dialogs are expected to respect the settings and preferences of the user in the web browser (and operating system), such as default font-size, colors, and language.

  <label for="name">Name (required): </label> <input type="text" name="name" id="name" required aria-required="true">

  The aria-required attribute informs assistive technologies about required controls so that they are appropriately announced to the users (as opposed to validating the input). Most current web browsers automatically set its value to true when the HTML5 required attribute is present. In this example, it is provided redundantly to support web browsers that don’t communicate the required attribute to assistive technology.

  Validation should aim to be as accommodating as possible of different forms of input for particular data types. For example, telephone numbers are written with different separators and digit groupings. Your form will be easier to use if it can interpret multiple notations. Also, it is helpful to be liberal with input. For example, postal codes aren’t confined to just numbers in some countries, so using an input of the type number can easily become a problem for many of your website users.

• Multi-Page Forms: Divide long forms into multiple smaller forms that constitute a series of logical steps or stages and inform users about their progress.
  Where possible, divide long forms into multiple smaller forms that constitute a series of logical steps or stages. This helps make long forms less daunting and easier to understand, particularly for people who are less experienced using computers or who have various cognitive disabilities. The following basic principles should apply for multi-step forms:
  • Repeat overall instructions on every page.
  • Split the form up according to its logical groups of controls. For example, in an online shop, shipping and payment information are typically separated.
  • Make it easy to recognize and to skip optional stages. For example, highlight optional steps in the main heading of the web page and provide an option to skip.
  • If possible, the first step of a form should explain how many steps will follow. Each step should inform the user about the progress they are making.

Tips and Tricks

• Keep it simple: Complex tables are more work for content creators as well as being harder to interpret for users. It’s usually better to break up complex tables into simple individual tables, each containing the data for one sub-topic. Multiple simple tables can provide the same information as the mutli-level table but it makes the information easier to understand for everyone and easier to code. Also, simple tables are much better supported by tools to create web content, including WYSIWYG (“What you see is what you get”) editors.
• Table separation: If several tables follow one another, don’t use a single table and put in an additional row of <th> cells. Screen readers may read aloud all <th> cells in a column, resulting in confusion. Start a new <table> when the topic changes.
• Data separation:
  • Make sure that each separate piece of data has its cell. Don’t use headers in one column and all data in a second column, as this will make it almost impossible for screen readers to work out the relationships between data across columns.
  • Don’t use line breaks (<br> elements) to create table rows as the data in the pseudo-rows may no longer align correctly when text is resized.
• Alignment: Align text to the left and numeric data to the right (in left-to-right languages), so that people using larger text sizes or smaller screens will be able to find it. This is especially useful if a cell spans more than one column. It’s helpful to give column headers the same alignment as the data in the cells below.
• Styling header cells: <th> elements are used for header cells, using <td> elements with different styling will make tables less accessible if not inaccessible. It is also helpful to differentiate <th> and <td> cells visually.
• Zebra tables: Styling even and odd rows in a different way can be helpful to people who have reading difficulties or who enlarge text. It acts as a visual guide. Highlighting the cell (and row/column) on mouseover and keyboard focus to support people to see where they are. Make sure that the contrast ratio between the text and background is good for both headers and data cells. The contrast between all text and its background is at least 4.5:1 for normal-size text.
• Flexibility: Due to the layout model of tables, they sometimes don’t fit on small screens small or are too wide if the user is zooming in. In such circumstances, it’s important that the table isn’t cut off (for example by using overflow: hidden in CSS).
• Tables for Layout: Tables should not be used for layout purposes. Use Cascading Style Sheets (CSS) for layout. If there are already layout tables present, don’t use structural elements (like <th> or <caption>), and do add role="presentation" to the <table> element.

Caption and Summary

Captions and summaries provide information that can help users find, navigate, and understand tables. While they are not required in every case to meet WCAG 2.0, captions and summaries are fairly straightforward ways to provide such information that is often needed.

• A caption functions like a heading for a table. Most screen readers announce the content of captions. Captions help users to find a table and understand what it’s about and decide if they want to read it. If the user uses “Tables Mode”, captions are the primary mechanism to identify tables. The caption is provided by the <caption> element.
• A summary conveys information about the organization of the data in a table and helps users navigate it. For example, if a table has an unusual structure (as in the examples below), information about what content can be found in which row or column can be provided to the user. A summary is usually only needed for complex tables.

If both caption and summary are provided for one table, the summary should not duplicate information present in the caption.