WordPress PDF Accessibility — Practical Guide for SA Businesses

WordPress PDF accessibility is the practice of ensuring that every PDF document linked or embedded on your WordPress site can be read by people using screen readers, keyboard navigation, and other assistive technologies — and getting it wrong means a portion of your audience simply cannot access your content. If your site is part of your website cost planning in South Africa, document accessibility is a line item that regularly gets missed until it becomes a compliance risk.

According to the 2022 Stats SA census, 15.7% of South Africans — approximately 9.7 million people — report some form of functional difficulty with seeing, hearing, communicating, walking, or remembering. That is a significant portion of the population encountering inaccessible PDFs every day, not a niche edge case. This guide covers what accessible PDFs require technically, what the SA legal picture actually looks like, and how to decide whether to fix an existing PDF, replace it with HTML, or serve an alternative format.

What Does WordPress PDF Accessibility Mean?

An accessible PDF is a document that communicates its structure — headings, paragraphs, lists, tables, form fields — to assistive technologies through embedded tags. Without those tags, a screen reader encounters a wall of unordered text or, worse, an image it cannot read at all. WordPress PDF accessibility therefore spans two distinct layers: the quality of the PDF file itself, and how that file is served or embedded on your site.

The technical standard is set by the W3C's WCAG PDF Techniques, which detail 23 specific implementation approaches — from tagging heading hierarchies and table rows to setting the document language and hiding decorative images as "artifacts." PDF/UA (ISO 14289), the international technical standard for universally accessible PDFs, builds on these principles and adds requirements around font embedding and Unicode character mapping that WCAG alone does not specify.

The core requirements every accessible PDF must meet:

• Tagged structure — headings, lists, tables, and paragraphs are marked up with semantic tags
• Alternative text — every meaningful image has a text description; decorative images are marked as artifacts
• Correct reading order — the tag sequence matches the intended visual flow
• Table headers — data tables use TH tags so column and row relationships are announced
• Form field labels — interactive fields are labelled so a screen reader can announce their purpose
• Document language — the /Lang entry specifies the language so screen readers apply correct pronunciation
• Document title — the Title metadata field is populated and matches the visible heading

SA Laws That Create Document Obligations

South Africa has no legislation that explicitly mandates website or document accessibility for private companies. That is the accurate starting point — and it is also the starting point most SA operators misread in both directions.

Misread one: "there's no law, so I have nothing to worry about." The Promotion of Equality and Prevention of Unfair Discrimination Act (PEPUDA, 2000) prohibits unfair discrimination on the grounds of disability in any domain — including the provision of services. Publishing documents that only some users can access creates a discrimination argument that courts have been prepared to hear. The South African Human Rights Commission can investigate such complaints. See our broader web accessibility in South Africa guide for the full legislative picture.

Misread two: "the government must comply but private businesses are exempt." Government websites are held to at least WCAG Level A under GCIS guidelines; the Government Information Technology Officer (GITO) standard requires national and provincial government sites to meet WCAG 2.0 Level AA. If your WordPress site handles government procurement, tenders, or publishes materials that government entities are required to receive, the accessibility expectation travels with the relationship.

South Africa has also ratified the UN Convention on the Rights of Persons with Disabilities (CRPD), which commits the state to accessible information and communication. The CRPD does not directly bind private companies, but it shapes how courts and regulators interpret the Constitution and PEPUDA.

The practical risk for most SA businesses is not a court case. It is a complaint to the Human Rights Commission or a damaged relationship with a client or partner who requires accessible materials. PDF accessibility South Africa is still largely self-regulated in the private sector — but self-regulation has not protected businesses from complaints under PEPUDA. Keeping your site accessibility checklist current — including your document workflow — is the cheaper path.

Born-Digital vs Scanned — Which Document Type Is Harder to Fix?

Scanned image PDFs are substantially harder and more expensive to fix than born-digital PDFs: they contain no selectable text, so OCR must convert the image to actual text before any accessibility tagging can begin. Which type you have determines your remediation path before any other decision matters.

How do you tell which type you have? Select text in the PDF. If the cursor selects individual words, you have a born-digital document. If you can only drag a rectangle over the whole page, you have a scanned image PDF.

A third category sits between the two: born-digital PDFs that were exported without accessibility settings — no tags, no alt text, no reading order — even though the source document existed. These are often the easiest to fix because the source file is recoverable and the remediation is a one-time export change, not a complete rebuild.

Source-First: Build Before You Export

Retrofitting accessibility into an exported PDF is always harder than building it into the source document. The principle is straightforward: every tag, heading, list, and alt text entry you establish in Word, Google Docs, or InDesign travels cleanly into the PDF export — if the export is configured to include accessibility metadata.

The six source-document steps that produce an accessible PDF:

1. Apply heading styles, not bold formatting. Use the built-in Heading 1, Heading 2, Heading 3 styles in Word or Google Docs. "Bold and large font" is visually similar but creates no structural tag in the exported PDF.
2. Use built-in list formatting. Bullet and numbered list tools generate proper list tags. Text with manually typed hyphens or asterisks generates unstructured text.
3. Add alt text to every meaningful image. Right-click → Format Picture → Alt Text in Word; Image options → Alt text in Google Docs. Leave the field empty for purely decorative images so the export marks them as artifacts.
4. Structure tables with header rows. Identify the first row as a header row. In Word, Table Properties → Row → Repeat as header row. In InDesign, use the Table Options header row setting.
5. Set the document language. In Word, File → Options → Language. This generates the /Lang metadata tag on export.
6. Export with accessibility options active. In Word: Save As → PDF, check "Document structure tags for accessibility." In InDesign: Export Adobe PDF → Advanced → Enable Accessibility and Reflow with Tagged Adobe PDF.

After export, run Adobe Acrobat Pro's Accessibility Checker (Tools → Accessibility → Full Check) to confirm tags are present and reading order is logical. Acrobat Pro's Tags panel and Reading Order tool let you repair issues the automatic check surfaces without returning to the source file. A tagged PDF WordPress can serve to users is the result of this process — not the result of uploading any document and hoping the Media Library handles the rest.

Plugins and Tools for the Document Workflow

Plugins address the embedding and discovery side of PDF accessibility — they do not fix the documents themselves. Understand that distinction before evaluating any plugin. Getting WordPress PDF accessibility right means treating the plugin layer and the document layer as separate problems that require separate solutions.

Equalize Digital Accessibility Checker (free and paid tiers) scans your posts and pages for accessibility issues and flags a "Link to PDF" warning whenever it detects a .pdf link. The warning is not an error — it is a prompt to manually verify that the linked document meets accessibility standards, since no automated tool can scan PDF content from inside WordPress. The plugin also surfaces other WCAG-related issues across your site. It fits naturally into an editorial workflow where accessibility is reviewed before a post goes live.

PDF.js Viewer embeds PDFs directly in your page using Mozilla's PDF.js rendering engine — the same engine used in Firefox. It provides keyboard navigation and basic screen reader support in the viewer interface itself. This helps sighted keyboard users but does not help screen reader users who need the document's underlying structure to be tagged. Embed accessibility and document accessibility are separate problems.

Accessible Docs takes a different approach: when a visitor clicks a PDF link, a popup invites them to request an accessible version by email. The document is processed by the AccessibleDocs platform and delivered to the user. This is a practical fallback for organisations with large backlogs of untagged legacy PDFs that would be expensive to remediate individually.

Whatever plugin you use, follow Equalize Digital's recommendation on link text: always include the file type and size in the anchor text — for example, "Download the 2026 rate schedule (PDF, 340 KB)". This gives screen reader users the information they need to decide whether to open the link before committing to the download.

An accessible PDF WordPress users can navigate requires both a properly tagged document and a correctly labelled link — the plugin handles the link; the source remediation handles the document. For booking and functionality plugin decisions, the same principle applies: the plugin is only as good as the content it serves.

Fix, Replace, or Serve an Alternative — a Decision Table

The right approach to any PDF on a WordPress site depends on three variables: whether it is born-digital or scanned, how frequently it changes, and how central it is to a legally sensitive or compliance-critical workflow. The table below maps those variables to a recommended action.

The decision to replace a PDF with an HTML page deserves particular attention. HTML content maintained in WordPress is inherently more accessible than even a well-tagged PDF: you control heading structure directly, the page is mobile-responsive by default, and screen readers navigate it with no plugin dependency. WordPress document accessibility is consistently stronger when content lives in pages and posts rather than file downloads.

If a document changes quarterly or annually and is not legally required to remain in PDF format, a well-structured WordPress page is inherently more accessible and is indexable by search engines in a way that many PDFs are not. One resource that rarely needs to stay in document form: a services rate card. Another that almost always should: a signed contract.

Why South African Businesses Choose Growth Pulse Media

Growth Pulse Media was built by an operator who scaled a South African ecommerce business from the ground up — paying the invoices, dealing with the integrations, and learning which technical decisions create real risk versus which ones are noise. That background shapes how we approach web design work: practical over theoretical, SA-specific over copy-pasted global advice.

When we build or audit a WordPress site through our web design services, document accessibility is reviewed as part of the build, not tagged on as an afterthought. We work with a limited client load so every site gets senior attention — no handoff to a junior who ticks the "PDF link" checkbox and moves on. We operate in-house, in Johannesburg, and we know the SA procurement and compliance environment that shapes what "accessible" actually means for a local operator.

Our credentials include Registered Shopify Partner and Omnisend Certified Partner status. All audits and build reviews are completed by the same team that built the work.

Who This Is NOT For

Frequently Asked Questions

Is WordPress PDF accessibility legally required in South Africa?

South Africa has no legislation that explicitly mandates PDF accessibility for private companies. However, the Promotion of Equality and Prevention of Unfair Discrimination Act (PEPUDA) prohibits unfair discrimination on the grounds of disability in the provision of services, and inaccessible digital documents can be the basis of such a complaint. Government entities are held to WCAG standards, and those expectations can extend to suppliers and contractors. Legal risk is real; it is not hypothetical.

What is the difference between a tagged PDF and an untagged PDF?

A tagged PDF contains embedded structural markers — heading tags, list tags, table tags, alt text entries — that assistive technologies use to navigate and read the document in logical order. An untagged PDF presents its content as an undifferentiated stream of visual elements that screen readers cannot interpret meaningfully. Tagging is the foundational requirement for PDF accessibility; no other remediation step matters if the document is untagged.

Can a WordPress plugin make my PDFs accessible?

No plugin makes an inaccessible PDF accessible. Plugins control how PDFs are embedded, linked, and surfaced on your WordPress site — they can enforce descriptive link text, prompt users to request accessible alternatives, and audit your pages for PDF link warnings. The document itself must be fixed at the source or remediated in a tool like Adobe Acrobat Pro before it will be accessible to screen reader users.

Should I replace PDFs with HTML pages on WordPress?

For content that changes regularly, is not legally required to be in PDF format, and does not need to preserve a specific visual layout, replacing a PDF with a well-structured WordPress HTML page is almost always the better decision. HTML pages are inherently more accessible, mobile-responsive, and search-engine-indexable. PDFs are better suited for content that must be downloaded, printed, or preserved in a fixed visual format — legal agreements, signed documents, technical schematics.

How do I check whether my PDF is already accessible?

Start with Adobe Acrobat Reader: if you cannot select individual words by clicking, the PDF is a scanned image and has no accessibility at all. For born-digital PDFs, open Adobe Acrobat Pro's Accessibility Check (Tools → Accessibility → Full Check) to surface structural errors, missing alt text, and reading order problems. Automated tools catch only a fraction of barriers, so follow up by navigating the document with keyboard-only commands or testing with a screen reader such as NVDA (free) or JAWS.

Dirk van Greuning Founder, Growth Pulse Media

Founder of Growth Pulse Media and a specialist in South African search dominance. Dirk translates his experience in scaling South African businesses into high-velocity digital strategies for B2B and retail leaders. He writes about SEO, lead generation, and paid media from an operator's perspective — prioritising pipeline value over impressions.

Connect on LinkedIn