In recent years, the accessibility of PDFs for disabled users has become a big topic. Governments in particular may mandate compliance with accessibility standards. The key point is that screen readers, which read electronic documents aloud, should be able to make sense of a PDF document.
A number of governments and organisations state that they "require" perfect compliance (it basically costs nothing to decree that), but to our knowledge there are no report generators that achieve it, and certainly not automatically. We believe ReportLab do very well on accessibility, and have dealt with the main things accessibility checkers reported many years ago (like adding metadata to describe the language the output is in).
ReportLab PLUS is a fairly low-level way of constructing PDF files, so achieving good accessibility is up to the developer using it. Here are some guidelines on testing and improving accessibility.
A perfect accessibility score, while often mandated in software requirements, is not always possible nor economic, especially with a complex graphical representation of data which is hard to explain in spoken words. We've often found in practice that disabled readers are much happier with an alternative form of the same information - for example a web page - which might allow you to agree an exemption for a PDF file, if this is always available.
How to Test
There are many testing tools and your organisation may have its own preferences.
The most popular desktop tool is probably Acrobat Pro.
There are many web services - The UK Government have some accessibility guidance that refers to Tingtun Checker for checking PDF files. This is a freely available site with no subscription needed, so it's our first port of call. Users can check PDFs via a url or the upload facility;
The site currently tests for the following:
- Structure Elements (tags)
- Document Permissions
- Scanned Document
- Alternative Text for Images
- Correct Tab and Reading Order
- Decorative Images
- Table Elements
- Heading Levels
- Form Fields
- Running Headers and Footers
- Submit Buttons
- Natural Language
- Page Numbering
- Document Title
- Link Text for External Links
Improving Accessibility in your ReportLab and Rlextra output
There are optional properties we let you specify, like the language being used and providing alt descriptions for images within the PDF, which help your PDF to score pretty well. A large part of the accessibility score depends on the scripts you use to generate them and the content you put in. For a more further detail, tips and background reading on accessibility please see W3C PDF Techniques for WCAG 2.0 and Checker PDF test.
In ReportLab's Open Source framework (henceforth ReportLab), it depends on what parts of the toolkit you are using. Use the
canvas.setTitle("My PDF Title")
Or maybe is you are using
SimpleDocTemplate('my-file.pdf', title="My Tile")
In our commercial Report Markup Language (henceforth RML), set the title attribute in the
<template title="My Title" etc >
In RML, set the title attribute in the
<template lang="en-GB" etc >
In ReportLab, pass an argument; SimpleDocTemplate('my-file.pdf', lang='en-gb')
Our system does not automatically generate bookmarks according to heading levels. We have a fairly common convention that you will set headings with
<para style="h1"> but there's nothing to force you to do that; and you might not be creating a long flowing document anyway. So it's up to you to create bookmarks for the main sections, which will appear in the left sidebar.
In ReportLab, use the
canvas method - see section 4.2 in the ReportLab userguide;
In RML, see the
Interactive forms are rarely used in PDF; since PDF was launched, the world has moved to people being online almost everywhere, and in the vast majority of cases, any organisation capturing information has a web form. However they may still be used in specialised situations, and we support their creation.
In RML, use the
tooltip tags with the associated form fields eg
This is up to you, the author, but it's very easy to number pages.