2.  PDF accessibility basics  Making good PDFs, Avoiding Bad PDFs  Departmental approach to PDFs  Problematic PDFs and how to deal with them  Lunch  Using Adobe Acrobat Pro XI to test and remediate PDFs 1:00  Creating accessible PDFs from Adobe InDesign, 2:30

3.  Mark Hale, IT Accessibility Coordinator, ITS  Todd Weissenberger, Web Accessibility Coordinator, ITS  Anne Kent-Miller,Creative Coordinator, University Creative Services

4. ACCESSIBILITY BASICS

5.  PDF is one of the most common document types on the web, but the format can pose multiple challenges for accessibility.  This session will address the fundamentals of PDF accessibility, including  five characteristics Adobe uses to define an accessible PDF,  source document accessibility, and  quick tests for accessibility.

6.  “Wherever there’s economic activity, PDF files are the medium of recording for assessments and agreements, for conveying ideas and disseminating critical information. PDF files are, in many ways, red blood cells for the larger economy.” (PDF Assn.)  PDFs were the most rapidly growing part of the web in a recent survey

7.  Faithful visual representation of documents  Platform-independent delivery  Commonly used for printing and distribution  Not initially designed for accessibility  Text extraction in Acrobat 4  Tags in Acrobat 5  Significant progress on accessibility since v.7

8.  Search engines (“Google is blind”)  Mobile platforms  People with disabilities

9.  Can be Perceived by everyone  Can be operated by everyone  Understandable  Robust  Good content is POUR

10.  People with disabilities frequently use software to help them deal with electronic documents  Magnification  Conversion of text to speech (screen readers)  Reflow in Reader

11.  WCAG 2.0, Level AA (for web delivery)  PDF/UA is a new ISO standard

12.  Logical structure and reading order, represented in tag structure  Alternate text descriptions for figures, form fields, and links  Navigation aids, including bookmarks and/or table of contents derived from structure  Security that doesn’t interfere with AT  Fonts that allow characters to be extracted to text

13.  Text content—not image-only  Tags for document structure, semantics  Logical reading order  Keyboard navigability: headings, bookmarks  ALT Text equivalents for images  Document metadata: language, title

14. Scanned/Image-only Untagged Text Tagged Text/ALT Order, bookmarks Forms, Multimedia Available only to visual users in an optimal environment Available to AT users, lacks document outline or structure, may have issues with order, images, contrast Available to AT users, who can navigate through document outline. Images include appropriate text equivalents. Provides a high degree of interactivity. All form elements are labeled, tab orders harmonize with content order, media are accessible Ensures that all users experience the content in a logical order, with keyboard access to document structure and internal links

15.  ILL scan in Reader, enlarged, reflowed  Journal in Reader, enlarged, reflowed  Adobe document in Reader  Adobe document in Acrobat

16.  Easiest place to build meaningful structure  Styles tie structure to appearance  Structure passes through to PDF if the PDF is created properly (don’t Print; use Save As)

17.  Heading heirarchy: H1, H2, …  Lists  Columns for layout  Tables for data, not layout  Figures which are not groups of objects  Avoid floating text boxes, empty paragraphs, lists created with graphics, tables for columns

18.  Click on visual headers and look at the ribbon  Do appropriate styles turn on in ribbon?  Turn on Navigation pane (Alt, W, K)  Navigate by headers in pane  Turn on formatting symbols (Ctrl-Shift-8)  Look for visual artifacts that will produce bad tags  Run Accessibility Checker in Office 2010/13  In File menu, Prepare for Sharing …

19.  Word document with some structure, some not

20.  Manual tests in Adobe Reader  Acrobat Pro XI Accessibility Checker  PDF Accessibility Checker (Zugang fur Alle)  PAC 1.3 is simpler, more relevant now  PAC 2.0 checks PDF/UA, very comprehensive  Acrobat XI has check and remediation tools

21.  Click on a page  If the whole page lights up, it’s an image  Double-click on a word  If the single word lights up, it’s at least text  Open File Properties  It will say Tagged yes/no  Also note creation date, Application, PDF version, and PDF producer

23.  Open Tags Navigation Panel (Alt V S N g)  Do the tags match the visual structure?  Are there incorrect or extraneous tags?  Try Reflow with 200% - 300% enlargement (Ctrl-4)

25.  PAC 1.3 is quick and simple (Doc in a Box)  PAC 2.0 measures new standard (Mayo Clinic)  Acrobat XI (Check and correct)  CommonLook (said to be very good, but hard to learn)

27.  Text yields a better level of access than image-only  Can be tagged manually or automatically  Auto-tagging may require a manual check

28.  Office 2010 or 2013  Adobe Acrobat XI and Reader XI  PAC 1.3 (or 2.0 for the brave)  InDesign CSS

29.  Accessibility starts with source documents  Remove, rebuild, remediate  Make a plan:  Inventory your PDF holdings  Consider the purpose of a given document  Prioritize by use, audience, role, exposure

30.  Use Advanced Search in Google:  Search site:its.uiowa.edu filetype:pdf from inside UI (98 results)  Same search string at www.google.com,outside UI (692 results)www.google.com

31.  Lynda has lessons on Word and InDesign  lynda.uiowa.edu, search for Word styles  Adobe has Accessibility videos in adobe.tv  Adobe documentation  www.adobe.com/accessibility, has guides by product

32.  “Never try to teach a pig to sing. It wastes your time and annoys the pig.” ▪ Mark Twain (or Robert Heinlein)  Multimedia usually belongs elsewhere  PDF forms are problematic for mobile, as well as people with disabilities

33.  Mark Hale  mark-hale@uiowa.edu mark-hale@uiowa.edu  Todd Weissenberger  todd-weissenberger@uiowa.edu