PDF accessibility basics every freelancer should know
Accessibility isn't only for government work. Even a freelance invoice or proposal benefits from a few simple choices that make it readable by screen readers and people with low vision.
When you export a PDF, it carries more than what's visible. Underneath the layout sits a structure that determines how assistive technology — screen readers, refreshable braille displays, reading-mode browsers — interprets the document. A beautiful PDF that's structurally broken will read as nonsense to someone using a screen reader.
Why this matters for freelancers
Public-sector clients increasingly require WCAG 2.1 conformance for documents. Private clients are catching up — a growing share of enterprise procurement now includes an accessibility clause. Even on personal work, sending a tagged, well-structured PDF means anyone in your client's organisation can read it, full stop. That's the actual goal.
The four checks that cover most cases
1. Tagged structure
A tagged PDF includes a hidden tree describing each element: heading, paragraph, list item, table cell. Modern browser-based PDF exporters (including AetherSign) emit tags automatically when you use real HTML elements — h1, p,ul, table. The opposite, using adiv with custom CSS to fake a heading, produces an untagged document.
2. Logical reading order
Visually, your eye jumps around a page. A screen reader doesn't. It walks the document linearly, top to bottom of the tag tree. Multi-column layouts and floating images are the usual culprits for broken reading order. The fix: build your document as a single linear flow first, then style for visual layout — don't rely on absolute positioning to create columns from unrelated elements.
3. Alt text on meaningful images
Every image that conveys information needs analt attribute. Decorative images — a divider line, a background flourish — should have an empty alt=""so screen readers skip them. The worst case is the missing alt attribute, which causes some readers to announce the file name.
4. Contrast and font size
- Body text: at least 11pt for printed PDFs, 14px for screen-first.
- Contrast ratio of 4.5:1 against the background for body text.
- Don't rely on colour alone to indicate status — "red total" means nothing to a colour-blind reader. Add a label or icon.
Tables: the hardest part
Tables are the most common accessibility failure in invoice-style documents. A screen reader announces a table cell in the form "row 2, column 3, $1,200." That only makes sense if the table has proper header rows (th elements with a scope attribute). Stick to realtable markup with thead,tbody, and at minimum a th for each column header.
Quick checks before you send
- Open the PDF in your reader and try keyboard navigation: Tab should move through interactive elements in a sensible order.
- Use a free tool like PAC (PDF Accessibility Checker) or Acrobat's built-in Accessibility Check for a deeper report.
- Run the document through your browser's "Reader Mode" — if it strips to a coherent article, your structure is probably solid.
The shortcut
If you author your documents in semantic HTML and export with a browser-based tool, you get most of this for free. The underlying engine (Chromium's print pipeline) emits tagged PDFs and preserves reading order from the DOM. That's why AetherSign emphasises semantic markup behind the scenes — accessibility is a default, not a checklist item.