It passes the check, but does it work? What the SVAR review in doclarity looks at
veraPDF tells you whether a PDF meets the machine-checkable rules of PDF/UA. SVAR asks whether it works for people. Twelve areas, what is checked, and where the limits are.
A PDF can pass every automated check and still be hard to use with a screen reader. An image has alt text, but it reads "Image1.png". The headings are nested correctly, but one subheading was tagged as an ordinary paragraph. The validator reports: no errors.
That is why doclarity runs two reviews side by side. This post explains the second one.
Two reviews, two questions
veraPDF is the established open-source validator for PDF/UA. It checks the rules a machine can decide: is the document tagged, is a language set, does every image have alt text at all, are the fonts embedded. doclarity checks every finished document with veraPDF and shows the result, including any deviations.
SVAR (Semantic & Visual Accessibility Review) asks the question veraPDF cannot: does the document work for the people reading it? To answer it, SVAR reads the finished, tagged PDF in its two layers:
- what a screen reader gets: the structure tree with headings, paragraphs, tables, alt text, language and links
- what the page visibly shows: the rendered page image
Wherever the two do not match, SVAR records a finding.
How SVAR works
SVAR runs on request, right on the result page. It has two parts.
Rule checks, no AI. Everything that can be decided with certainty is checked with fixed rules. Examples: the first heading is not an H1, a heading level is skipped, a table has no header cells, a link has no target, the document language is missing, a form field has no name.
One AI reviewer for what only the page image shows. Whether alt text says what the image means at this point, or whether a bold line is really a heading, can only be judged in context. For this, an AI model receives the rendered page images and the screen-reader view of the document. It deliberately does not get the PDF text itself, because that text would carry the same errors the review is looking for.
The model's answers are checked before they are shown. Findings that name elements the document does not contain are dropped, and doclarity computes the position of every finding on the page itself.
SVAR changes nothing in the file. It only shows what a person should look at.
The twelve areas
The result appears as twelve tiles. Green: no finding. Yellow: at least one point to check. Grey: the document has nothing of that kind, for example no forms.
| Area | What is checked |
|---|---|
| Figures | Is alt text missing, is it only a file name or a number, does it say what the image means here? |
| Reading order | Does the order a screen reader follows depart from the visual order? Shown as a numbered overlay on the page. |
| Headings | Skipped levels, empty headings, lines that look like headings but are not tagged as one, and the reverse |
| Table of contents | Do entries lead to the right page, is the TOC tagged as one? |
| Tables | Header cells present and assigned correctly, layout grids wrongly tagged as tables? |
| Lists and text | Lists tagged as lists, paragraphs neither split nor merged, captions attached |
| Text fidelity | Do the letters in the tags match the letters on the page? A typical case: "Straße" becomes "StraBe". |
| Artifacts | Is every visible piece of content read out, and is page decoration such as running headers skipped? |
| Links and language | Links with meaningful text and a target, visible URLs that are real links, passages in other languages marked |
| Forms | Real fields with a name a screen reader can announce |
| Footnotes | Connected to their marker and read where they belong |
| Appearance | Does the tagged PDF look exactly like the original, pixel for pixel? |
Each finding shows a crop of the spot, one sentence on what is wrong, one sentence on what to check, and a link into the editor, to the element or the page concerned. The spot can be corrected there, and the review run again.
Why the appearance tile matters
Making a document accessible must not change how it looks. SVAR renders the original and the tagged file and compares them pixel by pixel. There is no threshold for how much may change: any unexplained change is reported. The only exceptions are changes chosen on purpose, such as a requested contrast adjustment or an accepted substitute font.
What SVAR is not
We word the result carefully. SVAR never says "accessible". The result page shows either the number of points to check or "No concerns found", with a note that this review can miss things too.
Many findings are judgement calls. Each one can therefore be marked "Not a problem". The decision stays with the person responsible for the document.
SVAR also does not replace testing with people who use screen readers every day. That is why we work with blind and visually impaired users to develop doclarity further.
In short
- veraPDF checks the machine-checkable rules of PDF/UA. doclarity shows that result for every document.
- SVAR also checks whether structure and page match: twelve areas, rules plus one AI reviewer.
- Every finding leads to the spot in the editor.
- A person always makes the final call.
SVAR is available in the hosted version of doclarity. Try it at doclarity.eu
Sources
- veraPDF, open-source validator for PDF/A and PDF/UA: https://verapdf.org
- ISO 14289-1 (PDF/UA-1), PDF Association: https://pdfa.org/resource/iso-14289-pdfua/
- The Matterhorn Protocol (which PDF/UA checkpoints can be tested by machine and which cannot): https://pdfa.org/resource/the-matterhorn-protocol/