Why is PDF Problematic for Accessibility?
PDF (Portable Document Format) is designed to preserve a document’s layout regardless of the device it is displayed on. This makes PDFs well-suited for print and distribution — but it creates a number of accessibility challenges on the web.
A standard PDF has no semantic structure. There is no difference between whether a piece of text is a heading, a paragraph, or a caption — they are simply positioned text blocks. Screen readers and other assistive technologies struggle to navigate the document meaningfully, and the user’s ability to adjust font size and contrast is limited. Additionally, scanned PDFs typically contain no machine-readable text at all, making them effectively empty documents for screen readers.
What Makes HTML Different?
HTML is built around semantics. A level-1 heading is tagged as <h1>, a paragraph as <p>, a list as <ul> or <ol>. This structure allows screen readers and assistive technologies to understand and communicate the document’s structure to the user — and enables the user to navigate directly to relevant sections.
HTML also adapts responsively to screen size and user settings. Font size, line spacing, and colour contrast can be adjusted by the user through browser or system settings. These are exactly the properties that WCAG 2.1 requires of web content — and what makes HTML the ideal format for accessible web content.
Methods for Converting PDF to HTML
There are several approaches to converting PDF to HTML. Manual conversion — where a person manually rewrites the content of a PDF into HTML — is the most accurate method, but is time-consuming and expensive for large document volumes. Server-based conversion services send your files to an external server, as files are transferred to an external server.
Browser-based solutions like PDFAccess combine automation with privacy protection: all processing occurs locally in your browser. No data leaves your device.
Step by Step: From PDF to HTML with PDFAccess
Conversion with PDFAccess is simple and requires no technical knowledge. Go to pdfaccess.net and drag your PDF file to the upload area — or click to select it from your computer. PDFAccess automatically analyses the document and detects whether pages are digital (born-digital) or scanned.
- Digital pages: Text and structure are extracted directly from the PDF and organised into semantic HTML with correct heading levels, paragraphs, and lists.
- Scanned pages: OCR (Optical Character Recognition) is used to recognise and extract text from images. Supports Danish and English.
- Hybrid pages: Pages with a mix of digital text and scanned elements are handled automatically.
- WCAG validation: Output is automatically validated against 5 core WCAG 2.1 AA criteria, with any warnings shown in the interface.
- Download: Choose between structured HTML (.html) with semantic tags or plain text (.txt) for further processing.
WCAG Requirements for Converted HTML
To ensure the converted HTML content meets WCAG 2.1 AA, there are a number of things you should check after conversion. PDFAccess automatically generates semantically correct HTML structure with heading levels, paragraphs, and lists — but certain elements depend on the quality of the original document.
Images in the PDF will appear as image elements in the output. To meet WCAG requirement 1.1.1 (Non-text Content), each image must have a descriptive alternative text. You should also ensure that tables have correct column headers, and that the document title is descriptive.
Checklist: Is Your HTML Content Accessible?
Use this checklist to verify that your converted content meets WCAG 2.1 AA:
- All images have descriptive alt text (WCAG 1.1.1)
- Heading levels are logically and hierarchically structured (WCAG 1.3.1)
- Colour contrast is at least 4.5:1 for normal text (WCAG 1.4.3)
- Text can be scaled to 200% without loss of content (WCAG 1.4.4)
- Links have descriptive link text — not “click here” (WCAG 2.4.4)
- Document language is correctly specified in the HTML lang attribute (WCAG 3.1.1)