Matterhorn 09-008 · PDF/UA-1 UA1:7.2-1

Warichu tags: two-line inline notes in Japanese PDFs

WT or WP appears outside a Warichu element, or Warichu has an illegal child sequence.

What a screen reader actually does

Inline annotations are announced as body text.

What a warichu is in the file

A warichu is a short comment typeset into two smaller lines that sit inside one line of the main text, straight after the words they comment on. In the structure tree it is three types: Warichu is the wrapper, WT is the comment’s text, and WP is the punctuation around it — usually a pair of brackets.

/P
├── 会議                       the base text, full size
└── /Warichu
    ├── /WP   （
    ├── /WT   二〇二六年十月開催     the note, set in two small lines
    └── /WP   ）

ISO 32000-1 describes the content of a Warichu as the group WP, WT, WP. Unlike ruby, a warichu may wrap from one line of text to the next; the breaking rules are those of the Japanese layout standard JIS X 4051.

As with ruby (09-007), the protocol’s condition cites Table 338, where Warichu is listed among the inline types. The rules for WT and WP are in the table after it — Table 339 in the 2008 text.

What goes wrong

A WT or WP outside a Warichu. The note is now an ordinary inline element, read as part of the sentence with nothing to mark where the comment starts and stops.

Something other than WT and WP inside the Warichu. A Span, for instance. Its text belongs to neither the note nor its brackets.

The right types in the wrong arrangement. A WT before both brackets, or two WP elements and no WT at all.

Each leaves the file unable to say which text is the comment, which is the whole of what the tags are for. The note itself is still heard where it sits; what is lost is that it is a note.

Where it comes from

A document whose two-line note was tagged as a Span — with no warichu structure at all — does not fail this condition; it has the wrong type, which is a judgement covered by 01-006. This one needs the warichu types, used wrongly: a WT dragged out of its Warichu during a reading-order repair, a converter that wraps only some of the pieces, or a hand-built assembly with the brackets in the wrong place.

How to check it free

Neither Acrobat nor veraPDF checks it. Acrobat’s Accessibility Checker has no warichu rule in Adobe’s list of its rules, and veraPDF’s PDF/UA-1 profile has no rule for Warichu, WT or WP. (Adobe: Create and verify PDF accessibility; veraPDF PDF/UA-1 rules)

Read the tree in Acrobat Pro’s Tags panel (View → Show/Hide → Side Panels → Tags). For each <Warichu>: are its children only WP and WT, in the order WP, WT, WP? Then look for WT and WP elements whose parent is not a Warichu.

How to fix it free, in Acrobat Pro

Using the Tags panel steps Adobe documents for creating, moving and retyping tags (Adobe: Edit document structure with the Content and Tags panels):

1. Select the element the note sits in, choose New Tag from the Options menu and type Warichu as the type. The warichu types are not in Adobe’s list of standard tag types; the dialog accepts a typed type.
2. Select the opening bracket on the page and choose Create Tag From Selection, typing WP. Do the same for the note (WT) and the closing bracket (WP).
3. Drag the three tags into the Warichu in the order WP, WT, WP.
4. Remove anything left empty with Delete Tag.

Where Taggart differs

Taggart reports an element in the wrong place and a wrong child:

<WT> appears inside <P> but the warichu structure grammar (ISO 32000-1, Table 338) requires it to be inside <Warichu>.

<Warichu> contains a <Span> child, which the warichu structure grammar (ISO 32000-1, Table 338) does not permit (allowed: <WP>, <WT>).

It does not check the arrangement of the children. A WT placed before both brackets, and a Warichu holding two WP elements and no WT, both pass. Read the order yourself even when Taggart reports nothing.

There is no repair. Each finding is a blocker with its page and structure path.

How Taggart handles it

Taggart checks for the common form of this condition automatically and reports it as a blocker. The check does not cover every form of it; what it misses is described above.

Where this sits in the standards

Related conditions

• 09-007 A Ruby-related structure element does not conform to ISO 32000-1, Table 338RB, RT or RP appears outside a Ruby element, or Ruby has an illegal child sequence.
• 19-001 Footnotes or endnotes are not tagged as NoteFootnote text at the bottom of the page is tagged as an ordinary paragraph.
• 09-002 Structure elements are nested in a semantically inappropriate mannerNesting that is syntactically legal but semantically nonsense — a Table inside an H2, a paragraph containing a section.

Other conditions in checkpoint 09

Checkpoint 09 covers appropriate tags. These are its other failure conditions; the ones without a link are in the rule set but do not have a written page yet.

• 09-001 Tags are not in logical reading orderThe 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.
• 09-002 Structure elements are nested in a semantically inappropriate mannerNesting that is syntactically legal but semantically nonsense — a Table inside an H2, a paragraph containing a section.
• 09-003 Structure type is not semantically appropriate after role mappingOnce role mapping has been resolved, the effective type still does not describe the content.
• 09-004 A table-related structure element does not conform to ISO 32000-1, Table 337The table grammar is broken: a TD outside a TR, a TR outside Table/THead/TBody/TFoot, a Table with no rows, or rows that span different numbers of columns.
• 09-005 A list-related structure element does not conform to ISO 32000-1, Table 336The list grammar is broken: an LI outside an L, an Lbl or LBody outside an LI, a list item with no LBody.
• 09-006 A TOC-related structure element does not conform to ISO 32000-1, Table 333TOCI appears outside a TOC, or a TOC contains children other than TOC and TOCI.
• 09-007 A Ruby-related structure element does not conform to ISO 32000-1, Table 338RB, RT or RP appears outside a Ruby element, or Ruby has an illegal child sequence.

Checked with Taggart on a generated file that fails this condition on 2026-10-02. The Acrobat steps follow Adobe’s documentation and were not walked through by hand. Last updated 2026-10-02.