Implement PDF Accessibility Support

[simoncozens]

Because software that discriminates against disabled users isn't good software.

Update: I've made a lot of progress on this but there's a lot still left to do:

• Marked content
• Ensuring marked content doesn't cross page boundaries
• Manually marked-up Structured PDF
• Automatically creating structure from commands
• Role mapping
• Artifacts
• Graphics
• ActualText

[simoncozens]

Trying to understand the scope of this. At the very least:

• We need to implement Structured PDF in libtexpdf.
• We need to implement Tagged PDF in libtexpdf.
• Content, artifacts, notes, lists, etc. must all be tagged and arranged in logical structure.
• Graphics need to have Alt tags.
• Text and documents must be tagged with their language.

Structured PDF is the biggie and will require a lot of libtexpdf hacking.

[alerque]

How much of this is implemented coming out of LaTeX and friends? Is this a matter of tracing and reproducing what happens and porting code into libtexpdf or does this need to pilot new ground?

[simoncozens]

Well, there's this but I am not convinced it helps us very much, and it seems like a quick hack rather than a serious implementation. There was a discussion on the xetex mailing list: see this post and follow-ups.

I think in reality a complete approach is going to need libtexpdf support, and that's worth doing anyway because if future software which wants to output PDF decides to go with libtexpdf, having that support in place is a big plus.

[alerque]

Huh. Having run through that thread and down a few other goose trails, it's sounding more and more like this is a big kettle of fish!

[pkulchenko]

Simon, SILE may be in a good position to implement the required changes given its processing, but it's likely to be quite a bit of work from my quick scanning of the docs.

I've had something similar in mind for cross-page linking I'm exploring for my project, so tags and their support are likely to come handy.

[alerque]

@simoncozens Note I moved your todo-list into the top post so that it would show up as a progress bar in the issue tracker.

[alerque]

@klpn's example repo showing how to build an tagged PDF with LaTeX from Pandoc with a Lua filter (discussion here) may be of use as a reference while implementing this.

[the-solipsist]

If this gets implemented, can SILE be used in place of LaTeX when making PDFs using pandoc?

[alerque]

@the-solipsist: This issue is completely orthogonal to that goal. Pandoc support is high on my list to do for other reasons. In fact since 2015 I've maintained a dirty but functional fork of Pandoc that includes a SILE writer.

See jgm/pandoc#6087 and the linked Draft PR. Once sile writer support is added it would be quite natural to also include it as an option for PDF conversion directly hiding the intermediate format and build details much like the current LaTeX writer does.

[the-solipsist]

Thanks, @alerque. I guess I phrased my question very poorly. I am specifically interested in accessible PDFs using pandoc, but with pdflatex as the pdf-engine, that doesn't seem possible as things stand. Accessible PDFs don't seem possible currently with SILE either. I was wondering about what I could do to create accessible PDFs in case SILE managed get to accessibility before LaTeX did, since my workflow depends only a little on LaTeX, but does depend heavily on pandoc.

So my question should have read: "Can SILE be used in place of LaTeX in order to make accessible PDFs using pandoc if issue #110 gets resolved?" The answer, as you've helpfully noted, is: "Not yet, but I'm working on it." I'll keep an eye on jgm/pandoc#6087. Thank you very much for your attempts to address the important issue of accessibility, as well as your work on bringing SILE to pandoc.

[alerque]

Got it. I guess you deduced the answer, but when both of these two lines of work are both done I think it will be quite natural for them to work together—probably just by default with no additional options/steps/work required.