Speaker: Mike Scott from the Illinois Department of Human Services.
PDF was originally designed for graphic designer so there was a single files format they could send to printers that hand high fidelity between the designer page layout and the publication the print house produced. The heart of PDF is post-script- a printer language.
PDF benefits: looks the same on screen, printed, etc. Free viewer. Can be easily transmitted and shared.
PDF behind –the-scenes: PDF documents can contain three different representations of the same document inside the code. The PS based physical view that we see and print. That's what PDF started with. Then the moved on to content level, used for searching, indexing, copying/pasting. This is the content layer (or content tree). This is another layer of data separate from the physical view. That layer started to make PDF accessibility possible. But this still wasn't a very rich experience. The layout and formatting (Headings, tables, etc) weren't made available to accessible tool users. Finally a third layer was added- the tag layer. This exposed document structure and HTML-like markup to the user. This includes table header markup. It turns the plain stream of text into something semantic and understandable.
PDFs are made either by converting word processor file, or by scanning and OCRing print materials. Optionally, another step is to take it in to acrobat pro and add feature that can't be created/converted (interactive forms, for instance).
The heart of PDF accessibility is the tagging structure (document reading order) and tooltips.
The free acrobat reader has a light-weight accessibility checking tool, but it only checks for the most basic features, so don't rely on it. Acrobat Professional has a more full featured [but still not perfect] tool for checking a pdf for accessibility. More importantly, it provides a way to remediate problems on the fly (add alternate text while working on a document) or, more importantly, use the touchup tool to change the reading order of tags/elements on the page. You also often need to access the tag view (in a tree) to expand and collapse branches to see things. For instance, we look at a document and see that it has headings out of order. Then you can just choose the item through the tag tree and change the heading level. Right now it doesn't allow you to add anything beyond h3 (although acrobat understands all the way up to h6). In that case you need to edit the properties of the element as well, and then you change it (but not through the Touch up tool). You also can't add/manipulate list through the TURO – touch up reading order – tool. It works very well with simple documents, and it can be used in combination with the tag tree. But there is a catch, related to the reading order.
Because the content and tag layer are separate, they may very well be in different orders. So remediating in TURO tool changes the content layer, not the tag tree. But screen reader use the tag tree representation. It will update the content eventually if you finish an entire document, but not until then {I'm not sure I got the gist of the quite right.]
Knowing that you can't trust TURO 100%, there is another way to do a quicker check- in both Reader and Pro. In reader it's "save as text" in Pro it's the "save as accessible text" option.
This allows you to very quickly check for the most terrible problems (broken reading order) for a quick triage. One major drawback is this is just a stream of text (no headings or other structural markup is there).
Another neat feature in the free version is read out loud. It's not as good as, nor does it replace, a screen reader for PDFs. But, it does read the text in the order of "Save as [accessible] text" so you can use it to listen to a documents and identify reading order problems.
Q: Which layer does the save as accessible text come from? Both read out loud and save as accessible text draw their data from the tag tree layer.
All these free tools are useful, but they haven't given us all the tools we need to remediate a document, especially a complex document.
One major issue is that this workflow means that if the source document changes, then you must start over from the beginning.
If you are working with PDF forms in particular (not for PDF in general for this portion of the presentation), there is a better tool- Adobe LiveCycle Designer. This comes with the Pro level. This is a true form design tool that was built from the ground up (previously as another product, JetForm). It is a GUI WYSIWYG based form creation tool. Lots of the normal form elements (like title/heading) automatically becomes a tooltip- nothing extra need to be added. But there is the ability to manually add a tooltip. Anyone using PDF forms should go to designer.
Q: Does LiveCycle designer support JavaScript based form automation/checks? A. Designer does allow the use of script directly, with a rich scripting environment (two languages supported- javascript or formcalc). They haven't used it too much yet, just some basic tasks.
One other way to make it better- especially for documents that aren't forms. We can't create brochures, etc. from acrobat natively. But we have a tool that makes the testing a fixing a little easier. An Acrobat plug-in that does everything TURO should be doing but doesn't, CommonLook (~ $1000 retail, or ~$600 on subscription).
Split screen display- the physical view, and then a special version that is the content, displayed in the order as displayed in the tag view, but with some minimal semantic base display changes (headings are bigger, lists, etc).
Q. Why are the words chopped up? Because of the seemingly arbitrary chunks that adobe chunks text in to. You can go in, grab those chunks, and move them in to the right place. But you can't split the chunk- you have to move the entire bit.
Very simply point, click, select option interface. Much, much better than TURO and the tag tree remediation that comes in Acrobat Pro.
It will also provide great levels of details about complex object like tables. It also provides a checklist of possible problems and steps for correcting them in the document. It reports the problem, and when you dismiss the warning it provides the necessary tool/option to provide/fix the problem. You can also check for color-contrast (to make sure essential information isn't lost to someone that can't perceive the color).
Jon Gunderson has arranged for a free trial view for anyone at UIUC through the IHBE. This is available for about six more months. The only catch is they want feedback on how well it worked for you (to make decisions later on possible acquiring it for campus wide use). You can sign-up for a trial online (as well as some paper based forms here at the conference). The URL for the site is included in the PowerPoint, which will be posted online.
Keys to Success: Try to do as much accessibility work on the source document before converting to PDFs. iCITA offers classes about this (stop by the IT access table and talk to them to find about the free online versions of their sources). At least use the accessibility check in the free reader, preferably the better tools in Pro. Use TURO and the tags panel to fix major problems. Finally, if you do this a lot, try out CommonLook.
Q: What if it doesn't need to be a PDF? Do you suggest a different format? Yes, they often suggest to the users to make a web native format, like HTML. We explain to them that PDF is really about printing, and the move to it in a big way on line has to do with laziness (print to PDF style options). But if print output is key (like a form that needs to be filled out and printed) then a PDF version might be the best.
Q. Regarding IITAA- if the PDF is just a second version, and there is an accessible version, is that okay? Yes, the IITAA section 15.1 and 15.2 says either make the document natively accessible, or provide it in an alternative natively accessible format (HTML is usually the best choice). A link saying if you "request an accessible copy" instead of posting that version then no, you wouldn't be meeting the IITAA requirements.
Q: What about linking to the accessible version from the PDF? A. They don't, but it's a good thought.
