First: I know that this has been asked before:

• 
  How can tagged PDFs be created that support Universal Accessibility and reflowing? (06/2010)


• 
  LaTeX accessibility (05/2011)


• 
  Accessibility issues (10/2012)


• 
  Revisiting producing structured PDFs from LaTeX (06/2013)

There has been a couple of questions closed about accessibility and LaTeX since these questions.

I am also aware of Ross More's paper from 2009 and his presentation from 2010.

The question is still: Is possible to make PDF files that are accessible using LaTeX?

I understand that one can disagree on what accessible means. Different countries/regions will have different (legal) definitions. I am interested in how accessibility is understood in different countries, but for this question my main concern is the US context. Here I believe that Americans with Disabilities Act of 1990 (ADA)/Section 508 is what defines what accessible content is. More concretely, I am thinking being able to read the PDF file using a screen reader (like JAWS). Concretely the desire is to create pdf files that can be used in a class setting at a university where federal law requires that content is accessible. This is a real concern (see for example this).

The standard way to check whether a pdf file is accessible seems to to use Adobe Pro's accessibility checker. This can, for example, reveal whether a document is tagged. But it also seems like one needs to actually test it with a screen reader to make sure that everything is as desired.

Right now using pdfLaTeX and checking with Adobe Pro's accessibility checker I in general get two errors:

• the page lacks a language specification and


• there are no tags.

I am hoping that there has been some development over the last two years on this. Even though I use LaTeX frequently, I still consider myself a casual user. Answers in the past seem to point out that there are ways to do this, but I haven't been able to find a user friendly guide written in English. I have checked some document where text is read by a screen reader, but the problem seems to be the mathematics content.

From what I can understand it isn't possible to create a truly accessible PDF file. If this is true, I am wondering:

Question: What is the current best practice is to create accessible PDF files? Are there are user friendly guides available?

I am also aware of this answer (from 08/2014):

https://tex.stackexchange.com/a/194226/5870

Here it is pointed out in the comments that the created PDF file doesn't pass the accessibility checker in Adobe Pro. Also, one actually has to edit the .sty file that is used. (I still think it is a great answer!) Also, this file might have been created for a German context (but might still have international use?)

It seems the answer was hiding in a footnote of this paper on making ADA compliant PDFs. See this project!

UPDATE: Having spent time attempting to use this tool in conjunction with a complex custom class, I want to temper expectations. While the accessibility.sty package is a useful tool for simple documents, it is incompatible with multiple packages and commands. An improved version of the package, called accessibility_meta, is available here.

Even the updated package is not perfect. For example neither work with the package "fancyhdr" nor with simple commands like "setlist".

This answer presents what seems to me the most efficient way to improve the accessibility of LaTeX documents. Unfortunately, it requires the use of R and Adobe Acrobat. My previous approach involved using only a modified version of Babett Schaltz’s accessibility.sty. (Schaltz created it as part of her 2007 PhD thesis in Germany.) Despite making hundreds of modifications to the original .sty file, the arrival of new incompatibilities with every MikTeX update led me to switch to my current approach.

The first step involves knitting an RMarkdown file, however adding the following commands to the header of your standard LaTeX document will allow you to follow along from step two.

RequirePackage{accsupp}

RequirePackage{pdfcomment}

newcommand{AccTool}[2]{BeginAccSupp{method=pdfstringdef,unicode,Alt={{#1}}}pdftooltip{{#2}}{{#1}}EndAccSupp{}}

Step 1: Generate TeX Output Using RMarkdown

Click this text to access the example Rmd file, or download all of the content by clicking here. The first difference between this file and a plain Rmd is the YAML. The fontsize command does what you might expect. The keep_tex command ensures we have access to the intermediate files for step two. Finally, the header_includes command adds required LaTeX code to the header.

fontsize: 11pt

output:

  pdf_document:   

    keep_tex: yes

header-includes:

   - RequirePackage{accsupp}

   - RequirePackage{pdfcomment}

   - newcommand{AccTool}[2]{BeginAccSupp{method=pdfstringdef,unicode,Alt={{#1}}}pdftooltip{{#2}}{{#1}}EndAccSupp{}}

Step 2: Make Modifications to the TeX

This file will modify the TeX output from step one. It uses R's gsub command to add tooltips and accessibility tags to the document. One can design clever regular expressions to capture caption text for the accessibility tags. To learn regular expressions visit this website. I used a ~100-line variation of this file to add more than 1,000 tags to this 218-page document.

The last line of the script uses the texi2pdf command to generate a PDF file.

Step 3: Run Adobe Acrobat Scripts

The final step requires Adobe Acrobat Pro. Open the PDF file generated in step two and perform the accessibilty actions defined in this Acrobat script. You can install the scripts by simply opening the accessibility.sequ file if Acrobat is installed. You can access the script under Tools-->Action Wizard. For those managing multiple documents, Acrobat offers simple batch processing which you can apply to the accessibility.sequ commands.

Results

After performing all three steps, your document will be far closer to 508 compliance than the original knitr ouput. Among the four issues remaining after processing, logical reading order and color contrast always require manual judgement, Title is fixed with two clicks, and the final Headings-Nesting rule can be skipped according to Adobe. Specifically they say, "The order of headings is not required under WCAG, and is only an advisory technique."

Notice the figure's alternative text tooltip: