Japanese Ruby Text: Keep Furigana Readable and Selectable

Use HTML ruby annotations when Japanese text needs a reading attached to a word or character group. Keep the base text and its reading as real text. A font that displays a clever visual annotation is not automatically a substitute for meaningful document structure.

The HTML ruby element documentation describes the base-and-annotation relationship and the associated rt and rp elements. The practical work is deciding what a reader needs and checking that the result remains usable across reading, selection, and small-screen layouts.

Decide what deserves an annotation

Annotate for the intended audience, not simply every available character. A beginner-oriented learning page may need more readings than a technical article for fluent readers. Too many annotations can make a narrow mobile column visually dense and interrupt scanning.

Choose the unit carefully. Some readings belong to a whole compound rather than an independently pronounced character. Splitting a compound only to make the markup uniform can teach the wrong reading. Have a competent language reviewer confirm names, specialist terms, and context-dependent pronunciation.

Keep the editorial policy explicit: which vocabulary gets a reading, how repeated terms are handled, and whether the annotation is pronunciation or another kind of explanation. That policy prevents two writers from producing visually similar markup with different meanings.

Start with semantic markup

For a small illustrative example, write:

<p lang="ja">
  <ruby>東京<rp>(</rp><rt>とうきょう</rt><rp>)</rp></ruby>
</p>

The base word remains in the document, and the annotation remains text rather than an image. Parentheses supply a fallback presentation where appropriate. This is an example of structure, not a promise of identical pronunciation behavior in every assistive technology combination.

Do not build the reading from absolutely positioned fragments that only happen to align at one font size. If spacing depends on a particular viewport or font file, zoom and fallback fonts can separate the annotation from its word. Start with native layout before adding decorative adjustments.

Review wrapping at realistic widths

Test a short sentence, a long compound, punctuation beside an annotation, and adjacent annotated words. Check both a comfortable desktop column and the narrowest supported mobile width. A single isolated word in a component preview will not reveal every line-breaking problem.

Increase text size and browser zoom. The base text must remain readable, and the annotation must not collide with the preceding line. If you set a fixed line height, examine whether it leaves enough room when the user's preferred font differs from yours.

Avoid solving every collision by shrinking the reading until it is difficult to see. Instead, review the column width, spacing, annotation density, and typography together. A language-learning interface that requires perfect eyesight has defeated part of its purpose.

Check copy, search, and selection

Select the complete sentence and paste it into a plain-text editor. Then select just the annotated word. Observe what your supported browsers copy instead of assuming a universal clipboard representation. Decide whether the application needs a separate plain-text copy action for study notes or exports.

Test browser find with both the base word and its reading. If the site has its own search index, decide whether readings should be indexed as alternate search terms. Do not silently replace the canonical written form with a phonetic spelling and expect every downstream consumer to infer the original.

For automated checks, retain both strings in test fixtures. Our Text Diff can help compare redacted exported text during a migration. It cannot judge Japanese pronunciation or whether an annotation is linguistically appropriate.

Test assistive technology without guessing

Use a small documented matrix of browser, operating system, screen reader, and language settings. Ask what is actually announced and whether the reader can understand the sentence without an unexplained repetition. Record the observed result rather than labeling a component accessible solely because it uses a semantic element.

Include keyboard navigation if annotations reveal additional information interactively. A reading that appears only on hover is difficult to discover on touch devices and can be unavailable to keyboard users. The basic pronunciation should not require a precise pointer gesture.

If the design offers a furigana toggle, preserve the reader's choice without removing the underlying base text. Test both states after reload and during client-side navigation. Explain the control in ordinary language so it is usable by the audience that most needs it.

Keep fonts and content responsibilities separate

A special font can be useful for a particular visual treatment, but it also needs a fallback plan. Check missing glyphs, loading failure, and licensing before making it essential to comprehension. A reading stored only in a font cannot be edited, searched, or reviewed like ordinary content.

When importing content, preserve the base word and annotation as distinct fields or supported markup. Round-trip a few difficult examples through the CMS. A sanitizer or Markdown conversion that strips rt can leave a page that looks plausible in the editor but loses its readings on publication.

Conclusion

Good furigana is a language and interaction decision, not just a font effect. Use semantic ruby, review the readings, and test wrapping, selection, search, and assistive output with real sentences before publishing.