Converting a PDF to Markdown does not automatically make it accessible. Plain text may be easier to resize and navigate than a fixed page, but extraction can remove the semantic relationships that assistive technology needs. A visual heading can become bold prose, a table can become an unlabeled sequence of values, and a two-column page can acquire the wrong reading order.
Accessibility work begins after extraction by restoring meaning explicitly. Test the rendered destination, not only the raw Markdown.
Establish the correct reading order
Read the Markdown from top to bottom without looking at the PDF layout. Does each sentence follow naturally? Multi-column documents often alternate lines, while captions and sidebars can interrupt body text. Reorder blocks using the source as evidence.
Do not use visual position words such as “on the right” when the new format is linear, unless the reference remains meaningful. Replace them with section or figure references. Keep warnings and prerequisites before the steps they govern.
For long pages, inspect the sequence with styles disabled or in a screen-reader-friendly outline. Correct reading order benefits keyboard users, small screens, search, and downstream text systems as well.
Rebuild a logical heading hierarchy
Headings provide the primary navigation map for many assistive technology users. Use one descriptive H1 when the framework does not supply it, H2 for major sections, and H3 for subsections. Do not pick levels to achieve a visual font size.
Avoid skipped levels and empty headings. Replace repeated running headers with real topic titles or remove them. A heading should identify the content that follows; labels such as “More” or “Section” are not useful out of context.
Review the heading outline separately from the body. If two adjacent sections have the same vague name, add the distinguishing subject.
Write meaningful link text
PDFs often show bare URLs or phrases such as “click here.” In maintained editorial content, use link text that describes the destination: “PDF.js documentation” or “download the CSV example.” This lets a user understand a list of links without surrounding prose.
Do not change quoted material silently. If a bare URL is the actual reference, it can remain. Verify every target and indicate file type or external behavior when that information matters.
Avoid opening new tabs without a reason. If the application does so, communicate it consistently. Remove broken tracking fragments and line breaks from extracted URLs, but do not alter signed or authenticated links by guessing.
Restore lists and instructions
Use proper Markdown list syntax rather than hyphens inserted as decorative characters. Keep continuation paragraphs indented beneath the correct item. For nested lists, ensure the hierarchy represents real substeps rather than visual indentation from the PDF.
Numbered procedures should preserve the intended order. If exact legal or technical labels matter, retain them explicitly rather than relying on automatic rendering. Warnings should be identifiable through text, not color or icons alone.
Do not transform every checkbox image into an interactive task. State whether it represents a required action, a status, or merely an example.
Give images equivalent purpose
Text extraction may omit images. Decide which visuals are informative. Add them as stable assets with alt text that communicates the relevant information. “Screenshot” is rarely sufficient; “Settings page with Export format set to Markdown” explains the purpose.
Complex charts may need a nearby data table or extended description. Decorative images should use empty alt text in the rendered HTML so they do not add noise. Captions and alt text serve different purposes and should not be identical by default.
If an image cannot be included, add a clear omission note when its absence affects understanding. Do not leave a caption that implies the visual is present.
Convert tables semantically
Markdown tables can express a simple header row, but complex merged headers and row groups may require HTML. Identify column and row headers, include units, and make each cell understandable within its relationships.
Avoid extremely wide tables that require precise horizontal scrolling. Consider splitting them, providing a downloadable structured file, or rewriting them as labeled lists. Validate the result with keyboard navigation and the target renderer.
The PDF table guide explains when CSV or HTML is safer than basic Markdown.
Preserve language and text quality
Set the document language in the publishing framework. Mark language changes for quoted passages when supported. Check whether extraction replaced accented characters, ligatures, or right-to-left ordering.
Expand abbreviations on first use and explain symbols when the source relied on a legend. Join line wraps and repair hyphenation so screen readers do not pause at arbitrary page boundaries.
Avoid Unicode characters chosen solely to simulate layout. Real headings, lists, emphasis, and table semantics are more robust than decorative spacing.
Handle equations, code, and footnotes
Equations need an accessible representation appropriate to the platform, such as MathML through a supported renderer or a textual explanation. Do not publish a damaged sequence of glyphs as if it were the original formula.
Code blocks should preserve spacing and identify the language when known. Check every punctuation character and avoid line numbers mixed into the code. Provide a text explanation for what the example does.
Footnotes need stable links between reference and note. Confirm that markers are announced sensibly and that notes are not inserted mid-sentence due to page positioning.
Test the rendered destination
Keyboard through navigation and links. Inspect focus visibility. Use a heading outline and an automated accessibility checker, then perform manual checks because automation cannot decide whether reading order or alt text is meaningful.
Zoom and reflow the page. Check narrow screens for code and table overflow. If possible, sample with a screen reader and listen for heading sequence, link purpose, list counts, and table headers.
Accessibility is not a one-time property of the extracted text. It depends on Markdown, framework components, CSS, and editorial choices. The technical documentation migration guide covers the wider publishing workflow, while the cleanup checklist helps catch extraction artifacts before accessibility testing.
