· ReadyStack
Worked example
Real numbers from this tool, line by line.
12 findings in one EPUB package file, 9 of them errors: that is what this lint returns on the .opf a generative assistant wrote for an ebook production editor at a UK medical publisher. The block looked finished: indented, right property names, and every structural validator in the pipeline said the file was fine.
Six of those findings are values that do not exist.
Here is the metadata as it arrived:
<meta property="schema:accessMode">sight</meta> <meta property="schema:accessModeSufficient">screenReader</meta> <meta property="schema:accessibilityFeature">none</meta> <meta property="schema:accessibilityFeature">altText</meta> <meta property="schema:accessibilityFeature">screenReaderFriendly</meta> <meta property="schema:accessibilityHazard">noFlashing</meta> <meta property="schema:accessibilitySummary">This ebook is accessible.</meta> <meta property="dcterms:conformsTo">EPUB Accessibility 1.1 - WCAG 2.2 AA</meta>
Read it the way a retailer's ingest does. sight is not in the schema.org vocabulary; visual is. screenReader is not one of the four values accessModeSufficient allows: auditory, tactile, textual, visual. altText is not alternativeText, and screenReaderFriendly is not a term at all. noFlashing is not noFlashingHazard. The conformance string is missing one word, Level, and so it matches none of the strings EPUB Accessibility 1.1 defines. And none sits in the same list as three features: a record contradicting itself.
None of that is a weaker claim than the truth. Each one is no claim at all. An out-of-vocabulary value is dropped on ingest, so the title arrives in the shop looking untested while your own tooling reports that accessibility metadata is present.
The other findings are absences. There is no a11y:certifiedBy, which EPUB Accessibility 1.1 requires whenever a conformance claim is made: the claim has to name who made it. printPageNumbers has no dc:source for the print edition. One line uses the EPUB 2 name and content form an EPUB 3 reader never looks at. The summary is boilerplate at 25 characters. And the file claims textual alone is sufficient for content it also declares as visual, with no alternative-text feature anywhere: a claim that cannot be true.
Why this is a deadline and not a preference: since 28 June 2025 the European Accessibility Act, Directive (EU) 2019/882, covers e-books, and the accessibility information has to travel inside the publication's own metadata.
EPUBCheck will not catch any of the six: it validates structure, and every line above is structurally perfect. A chatbot will not catch them either, because a chatbot is where they came from. Somebody has to compare each value against a closed vocabulary, per property, per title.
So that is what the extension does. EPUB A11y: Check this .opf runs 18 rules over the open file and prints every finding on its line with the replacement to paste. Fix the eight lines above and the same file returns 0 findings. That check is free, uncapped, and it finishes the job for the title in front of you.
The paid layer is a different axis, not a bigger version of the same check: scope, and a document you keep. EPUB A11y: Sweep this folder walks every .opf in the workspace in one run and writes a dated pass/fail report per title, the thing a distributor asks for at the end of a backlist project. $29 once. An EPUB production freelancer bills $50 to $95 an hour.
The same engine runs in the browser at getreadystack.com/tools/epub-a11y-metadata-lint.
15 seconds — what it actually does
Questions people ask
What does it actually check?
It runs 18 rules over the accessibility metadata in an EPUB package file: schema:accessMode, accessModeSufficient, accessibilityFeature, accessibilityHazard, accessibilitySummary, the dcterms:conformsTo conformance string, and a11y:certifiedBy. It reports each finding on its line with the replacement line to paste. The sample file returns 12 findings.
Who is it for?
Ebook production editors and EPUB developers at publishers selling into the EU, plus freelance conversion vendors. Since 28 June 2025 the European Accessibility Act covers e-books, and retailers read the accessibility claim out of the package metadata, so the person editing the .opf is the person who carries it.
Why will a chatbot or EPUBCheck not do this?
EPUBCheck validates structure, not vocabulary: altText and sight pass it. A chatbot writes those invented values in the first place. In the sample file 6 of the 12 findings are invented or malformed values, including a conformance string missing the word Level, which no structural validator objects to.
What is free and what is paid?
Checking the file you have open is free, unlimited, with all 18 rules and every fix line: that job finishes. The paid layer is a different axis, scope and ownership: sweep every .opf in a catalogue folder in one run and keep the dated pass/fail report per title for your distributor. $29 once.
What would this cost otherwise?
An EPUB production freelancer bills $50 to $95 an hour. Metadata review is an hour or two per title before a title goes out, and a backlist sweep is a day. The extension is $29 once, and the single-file check stays free whether or not you ever hold a key.
Why not just ask ChatGPT or another AI chat?
A general AI chat answers from training data with a cutoff date, cannot read your repository and names no rule version. EPUB Accessibility Metadata Lint (EAA) checks the file you open against 18 rules from a rule set dated 2026-09-20, and points at the exact line with the fix. For a filing, an audit or a client you need that dated result on your own files.
Ask about this tool
One question, answered by the person who built it. Your email only if you want the answer sent.