A digital download has exactly one job: arrive in a form the buyer can actually use. When it does not — the PDF is a scanned picture of text, the video has no captions, the ebook's headings are just big bold lines a navigation pane cannot see — the buyer rarely writes in asking for an accessible version. They refund. Sometimes they charge back. Occasionally they leave the one-star review that says "couldn't even open it," which every future buyer reads as a verdict on your whole catalogue.
Accessibility work for downloads is mostly unglamorous file hygiene: structure, text that is really text, descriptions where pictures carry information, and delivery pages and emails a keyboard or a screen reader can get through. None of it requires a compliance department, and most of it is cheaper at creation time than as a retrofit after the third support email.
1. Why this is a sales and support issue, not just compliance
Start with the money, because that is where inaccessible files bite. A buyer who cannot read your workbook cannot get the result they paid for, and a customer who got no value is a refund request with a timestamp. Refunds on digital goods are worse than on physical ones: the file is already delivered, so you lose the sale and keep the support thread. Chargebacks are worse again — fees on top of the lost sale.
Then there is the quieter cost: the support tail. "It won't open on my tablet." "The text is blurry when I zoom." "I can't find chapter 4." Each is often an accessibility defect wearing a support costume — a scanned page that cannot reflow, images of text that pixelate, a document with no real headings. You can answer these one at a time, at midnight, forever — or fix the file once.
And the audience is bigger than the stereotype. Yes, blind and low-vision buyers using screen readers and magnification. Also: the buyer reading on a phone on a train, the one navigating by keyboard, the older buyer who zooms everything to 200%, the non-native speaker running your document through a translator that needs selectable text, the parent watching your tutorial with the sound off. Accessible files are simply more robust files.
2. PDFs: structure is the product
The PDF is where download accessibility is won or lost, because it is the format sellers most often produce by accident — exported from a design tool, flattened, and shipped unchecked.
Tagged structure. A tagged PDF carries a hidden reading tree: this is a heading, this is a paragraph, this is a list. Screen readers navigate by that tree, not by what the page looks like. When you export, use the option that preserves tags and structure — every major tool has one. An untagged PDF reads as a wall of unrelated lines, in whatever order the file stored them.
Reading order. Visual layout and reading order are different things. A two-column worksheet or a sidebar tip box: the eye sorts them instantly; a screen reader follows the file's stored order, which may read the sidebar mid-sentence. After exporting, check the order once in a tags view. If the tip box lands mid-paragraph, fix the export settings, not the buyer's patience.
Real headings. A heading is a structural element, not large bold text. Use actual heading styles in your source document (Heading 1, Heading 2) and they export as navigable landmarks: a screen-reader user can list them and jump straight to the section they need.
Alt text for instructional images. If an image carries information — a screenshot showing which button to click, a diagram of a stitch pattern — write a short text alternative that carries the same information. Purely decorative images should be marked decorative so they are skipped. The test: if the image vanished, what would the reader miss? That sentence is your alt text.
Selectable text, not scanned pictures. The most damaging PDF habit: pages that are photographs or scans of text. Nothing can select, search, zoom cleanly, translate, or read them aloud. If your source is a scan, run optical character recognition and check the result; if you typed the content, export it as text, never as an image of text.
3. Ebooks and documents: let the text flow
For anything longer than a few pages, format choice is an accessibility decision. A fixed-layout file freezes your layout onto every screen; a reflowable format — EPUB, a properly styled DOCX, HTML — lets the buyer change font, size, spacing, and colours, and lets text rearrange itself on a phone instead of forcing pinch-and-pan.
- Build navigation from headings. A table of contents generated from real heading styles is both a convenience feature and the primary way many readers move through a long document.
- Write link text that works out of context. Screen readers can list all links in a document. "Click here" and a bare URL both fail that list. Name the destination: "the sizing chart," "the publisher's returns page."
- Do not convey meaning by formatting alone. "The items in red are required" fails anyone who cannot see red — and anyone printing in black and white. Say "required" in words.
- Keep tables honest. Data tables need a header row marked as a header row, so assistive technology can announce which column a cell belongs to. A table built from tabs and spaces is a puzzle, not a table.
- Mind legibility basics. Adequate contrast for any text baked into graphics, a readable base size, line spacing that does not crush lines together.
4. Audio and video downloads: the file is not the only version
Downloadable media has a text-shaped shadow, and buyers expect it to exist. Captions and transcripts are also what makes media findable, quotable, and usable in sound-off environments.
Captions for video. Provide captions as a separate track (SRT or VTT) that can be switched on, searched, and translated — not text baked into the image, which can only be watched. Auto-generated captions are a starting draft: correct the technical terms, names, and numbers, because those are exactly the words the generator gets wrong and the buyer needs.
Transcripts for audio and video. A plain-text transcript with speaker labels and meaningful sound cues in brackets serves deaf buyers, screen-reader users, skimmers, and translators. Ship it in the same download as the media, in an ordinary format.
Chapter markers and summaries. Long media needs internal navigation: chapter markers with real titles ("Fixing the tension setting," not "Part 3") let a buyer return to the one segment they need. Add a short plain-language summary: what this covers, in what order, and what the buyer will be able to do afterwards.
5. The delivery moment: the page and email around the file
A perfectly accessible file delivered through an inaccessible moment is still a failed delivery. The buy and delivery flow is where your own pages and emails do the work — and the part most often assembled from defaults nobody inspected.
- Contrast and focus on the buy page. Text a buyer cannot read cannot sell to them: check that body text and buttons have real contrast, including over images. Then Tab through the whole page by keyboard alone. Every interactive element should be reachable, in a sensible order, with a focus indicator you can actually see.
- Descriptive download link text. The delivery email lives or dies on one link. "Download your workbook (PDF, 12 MB)" tells a buyer — and a screen reader listing links — exactly what they get. A link labelled "click here," or a button rendered as an image with no text alternative, can be invisible to assistive technology.
- No image-only instructions. Never put essential instructions solely inside an image. Instructions go in plain text in the email body; images may illustrate, never carry, the message.
-
Clear file names.
workbook-final-v2.pdfis a shrug. A descriptive name —sourdough-starter-workbook.pdf— survives the downloads folder and makes sense read aloud. State format and size in the email too. - Plain-text instructions, start to finish. The delivery email should work as pure text: what was bought, which link downloads it, how long the link lasts, and what to do if it expires.
6. Cheap testing: an afternoon, not an audit
You do not need a consultancy to catch most defects. One pass with free tools, before launch, is enough.
- Run a free checker. PDF accessibility checkers (including the one built into common PDF editors) flag untagged documents, missing alt text, and reading-order problems in minutes. They miss nuance; they catch the structural disasters that generate refunds.
- Do one screen-reader pass. Free screen readers exist for every platform. Open your flagship file, navigate by headings, and listen to the first pages and the delivery email. If you cannot find chapter 2 or the download link, neither can your buyer.
- Do the zoom and reflow checks. Zoom the PDF to 200%: does text stay sharp and selectable, or pixelate as an image? Open the ebook on a phone at a large font size: does it reflow, or are you panning across a frozen page?
- Tab through your own buy page and complete a test purchase by keyboard alone.
- Ask buyers. Add one line to your delivery email: if the file does not work with your setup, tell me and I will fix it or refund you. Buyers using assistive technology are the best testers of your files, and most sellers never hear from them only because they never ask.
7. The support tail, and a pre-launch checklist
Accessibility debt compounds like every other kind. A reported problem usually means one file with one defect — fix that file and every future buyer benefits. Keep a saved reply that acknowledges, offers the fixed file or a refund immediately, and asks one question (what setup they use) so the next fix is targeted. Track reports by format: three PDF complaints in a month is a pattern in your export settings, not three unlucky buyers. Before any new download goes on sale, run this pre-launch checklist:
- Export with tags and structure preserved; confirm the PDF is tagged, not flattened.
- Check reading order once, especially sidebars and callouts.
- Confirm headings are real heading styles and the contents list is generated from them.
- Alt text for every image that carries information; mark decorative images decorative.
- Confirm all text is selectable — no scanned or baked-in pages of words.
- Ship checked captions and a plain-text transcript with every audio or video file; add titled chapter markers to anything long.
- Give files descriptive names; state format and size wherever they are linked.
- Delivery instructions in plain text in the email — no image-only steps, and a download link whose text says what it downloads.
- Do the cheap tests: checker pass, screen-reader pass, 200% zoom, phone reflow, keyboard-only test purchase.
None of this requires your buyers to ask, disclose anything, or wait for a special version. It is one version, built properly, sold to everyone who might want it — which is rather the point of selling files.
Closing note on tooling: accessibility lives in your files and in the pages and emails you control, so judge any delivery tool on the delivery moment it creates — a readable buy page and delivery email, a personal download link that arrives reliably, per-buyer PDF stamping on first download, and a licence key per paid order where enabled, with refunds revoking access automatically. The tool behind this article, FileFreight, is one such delivery option: payment runs through your own Stripe account, a free plan at 5% per sale, or Pro at $19/month with 0% per-sale fees, on files up to 500 MB. The honest caveats: it is new and small, which is itself a risk to weigh; it is not a merchant of record and does not handle sales tax or VAT (that stays with you); it has no automatic importer (the first 20 sellers get a free white-glove migration instead); it is not a Shopify app; and it is delivery-only — no marketplace, no buyer library. It makes no accessibility claim of its own — the practices above are yours to apply, whatever delivers your files.
Top comments (0)