Standard
IS 5568 (תקן ישראלי 5568) and PDF documents
The Israeli accessibility standard, what it means for documents in practice, and why Hebrew PDFs fail it in a way no other market has to worry about.
מכון התקנים הישראלי — Standards Institution of Israel · technical standard: Based on WCAG 2.0 Level AA, with Israeli additions
Why this page is short on legal detail
IS 5568 sits inside Israeli accessibility regulations, and how it applies to a particular document set depends on the entity, the service and the obligation. That is a determination for a licensed מורשה נגישות, and a software vendor asserting otherwise would be doing you harm.
So this page covers the part we can speak to: what actually goes wrong in Hebrew PDFs, and what fixing it involves.
The Hebrew failure nobody else checks
A PDF content stream paints glyphs at coordinates. It has no notion of direction. That leaves two ways to lay out a right-to-left line.
A correct producer stores the characters in logical order and paints them right to left — each successive text-showing operation moving to a smaller x coordinate.
A visual-order producer reverses the characters first and paints them left to right, like Latin text. The glyphs land in identical positions. The page is indistinguishable. But the stored text is the sentence backwards.
logical הנגשת מסמכים דיגיטליים היא חובה חוקית בישראל
visual לארשיב תיקוח הבוח איה םיילטיגיד םיכמסמ תשגנהExtract the text and you get the second line. A screen reader applies the bidi algorithm to it and reverses it again. The result is unreadable.
This file passes PAC. It passes veraPDF. It passes Acrobat’s checker. All three ask whether the text has a Unicode mapping, not whether the characters are in the order a human wrote them.
The full technical explanation →
The three Hebrew-specific problems
Visual-order storage. Above. The one that makes documents unusable.
Wrong document language. Producers default to en-US. Nobody changes it. An English synthesiser reading Hebrew has no phonemes for it — the reader hears letter names or silence, not accented Hebrew. Why →
Left-to-right column order. Auto-tagging tools sweep the page left to right regardless of script. In a Hebrew two-column layout the correct order is right column first, so the document is tagged as two interleaved halves. Why →
All three are common in documents from Israeli government portals, court systems and older DTP workflows. All three are invisible to a sighted reviewer, because the page looks perfect.
What Taggart does about it
Visual-order detection is structural rather than statistical: Taggart compares the order glyphs are painted in against their positions on the page. A right-to-left line whose paint order moves left to right was stored visually. That is a fact about the file, not a guess about the words.
It corroborates with Hebrew morphology — the five final letters ך ם ן ף ץ occur only at the end of a word, so reversed text puts them at the start — and reports a confidence with the reasoning attached.
The repair attaches logical-order /ActualText to the structure element and leaves the content stream completely untouched, so the rendered page is pixel-identical to the original. Per-run /Lang is set at the same time.
IS 5568 is a selectable profile in the product, covering the WCAG-mapped conditions plus the right-to-left extensions, on the practical grounds that a Hebrew document cannot satisfy the standard while reading backwards.
Frequently asked questions
Does IS 5568 apply to PDF documents?
The standard governs the accessibility of internet services, and documents published as part of a service are generally treated as within scope. The exact application to any particular document set is a legal question. Confirm it for your obligation with a licensed מורשה נגישות (accessibility consultant) — Taggart makes no legal determination and this page is not advice.
Is IS 5568 the same as WCAG?
It is based on WCAG 2.0 Level AA with Israeli-specific additions, including requirements around Hebrew and the accessibility statement. Meeting WCAG 2.1 AA gets you most of the way; it does not automatically satisfy the additions.
Why do Hebrew PDFs fail in ways English ones do not?
Because of how right-to-left text is stored. Many Hebrew PDFs — particularly from older government and legal systems — store characters pre-reversed, so the page renders correctly and the extracted text is mirrored. Every checker passes the file. A screen reader reads it backwards. No mainstream tool detects this.
Does Taggart support Hebrew properly, or is it translated?
Hebrew is a first-class locale. The interface is Hebrew with a right-to-left layout, the reading-order editor understands that a two-column Hebrew page reads right column first, the engine detects and repairs visual-order storage, and IS 5568 is a selectable validation profile alongside PDF/UA-1 and WCAG 2.1 AA.
Related failure conditions
- TG-RTL-001 Right-to-left text is stored in visual order Older Israeli government, legal and DTP systems lay out Hebrew by reversing the character order and then rendering left-to-right. The page looks correct, but the stored text is backwards. Extracting it gives you the sentence mirrored, and the bidi algorithm then reverses it a second time.
- TG-RTL-002 A right-to-left run has no language declaration The document declares en-US at the catalog and never overrides it, so Hebrew paragraphs inherit English.
- TG-RTL-004 Reading order is not right-to-left aware Auto-tagging tools order blocks left-to-right, top-to-bottom. In a Hebrew two-column layout the correct order is right column first.
- 11-007 Natural language is not appropriate A language is declared but it is the wrong one — a Hebrew document declared en-US, or an English abstract inside a Hebrew paper inheriting he-IL.
- 09-001 Tags are not in logical reading order The order of elements in the structure tree does not match the order a human would read the page. This is the single most common substantive defect in tagged PDFs and the one Acrobat's own tooling handles worst.
Check your own file. Taggart's validator is free and unlimited — no page cap, no watermark, no account.
Last updated .