Appearance
Make digital editions accessible by targeting WCAG 2.1 AA and fixing the four failures editions cause most: missing text alternatives for facsimiles, hover-only notes that exclude keyboard and touch users, colour-only apparatus signals, and untagged language switches. Drive most of it from your TEI — language, structure and note relationships encoded once become accessible HTML automatically — and verify with an automated checker plus a keyboard and screen-reader pass. Accessibility is not a bolt-on; it is the same separation of content and presentation that already underpins good editions.
What standard should you aim for?
Target WCAG 2.1 Level AA (2.2 if you can). It is what most institutional and public-sector accessibility policies mandate, and it maps cleanly onto where editions fail. You do not need to memorise the spec — focus on the success criteria that bite: contrast, keyboard operability, text alternatives, and programmatically determinable structure.
How do you make a facsimile and its transcription accessible?
The transcription is the text alternative for the page image — exploit that. Present them side by side, and make sure:
- The IIIF viewer (Mirador, OpenSeadragon) is operable by keyboard, not mouse-only.
- The image has concise alt text describing what it is ("Folio 3r of MS Add. 4022").
- No content lives only in the image that a screen-reader user cannot reach in the transcription.
Link the two in TEI so the relationship is explicit and the front-end can render both:
xml
<surface>
<graphic url="ms_add4022_003r.jpg"/>
</surface>
<div type="page" facs="#f3r"> ... transcription ... </div>Why are pop-up notes an accessibility trap?
Hover-only tooltips are one of the commonest edition failures. They are invisible to keyboard users, awkward on touch, and often vanish before they can be read. WCAG requires content shown on hover or focus to be dismissible, hoverable and persistent. The robust fix is to render notes that are reachable by keyboard and, ideally, also available inline or at the end of the text:
html
<a href="#note12" aria-describedby="note12">council</a>
<aside id="note12" role="note">The provincial council of 1591.</aside>How do you handle multiple languages and scripts?
Encode language at source and let it flow to HTML. A screen reader only pronounces Latin, Greek or Arabic correctly if the markup tells it the language; right-to-left scripts only lay out correctly with the right direction.
xml
<quote xml:lang="la">ad fontes</quote>
<quote xml:lang="ar">إلى المصادر</quote>Rendered, these become lang="la" and lang="ar" dir="rtl", and assistive technology adapts automatically.
Does a colour-coded apparatus exclude readers?
Yes, if colour is the only signal. Red for emendations and blue for editorial additions means nothing to a colour-blind reader and nothing at all to a screen reader. Pair every colour with a second cue:
| Editorial signal | Colour-only (bad) | Accessible pairing |
|---|---|---|
| Emendation | red text | red + label "emended" + underline |
| Supplied text | grey | grey + square brackets + aria-label |
| Uncertain reading | orange | orange + "?" marker in text |
How do you test without commissioning a full audit?
A three-step pass catches most issues:
text
1. Automated: run axe DevTools or WAVE on key page types
2. Keyboard: unplug the mouse, Tab through a text, viewer and notes
3. Screen reader: skim one page with NVDA (Windows) or VoiceOver (Mac)Automated tools catch contrast and missing attributes; the manual passes catch the keyboard traps and unreadable notes that automation misses. Run the automated step in CI so regressions get caught on every build.
What is the accessible-editions workflow end to end?
Encode language, structure and note relationships in TEI; transform to semantic HTML with real headings, landmarks and lang attributes; choose accessible components (keyboard-operable viewer, dismissible notes); pair every visual cue with a textual one; then test with the three-step pass. Because it all derives from the source, accessibility scales across the whole corpus instead of being hand-patched page by page.
Key Takeaways
- Target WCAG 2.1 AA; it matches both policy requirements and where editions fail.
- The transcription is the text alternative for the facsimile — present both, keyboard-operable.
- Replace hover-only tooltips with notes that are keyboard-reachable and persistent.
- Encode
xml:lang(and direction) at source so screen readers pronounce text correctly. - Never signal apparatus with colour alone; pair it with a label, icon or bracket.
- Test with automated tools plus a keyboard pass and a screen-reader pass.
- Drive accessibility from TEI so it scales across the whole edition.
Frequently Asked Questions
Which accessibility standard should a digital edition target?
Aim for WCAG 2.1 (or 2.2) Level AA. It is the level most institutional and public-sector policies require, and it covers the issues editions most often fail: colour contrast, keyboard navigation, alt text, and meaningful structure.
How do I make a facsimile image accessible?
Pair the image with the transcription, which is itself the text alternative. Give the IIIF viewer keyboard controls, describe what the image shows in concise alt text, and never rely on the image alone to convey content a screen-reader user needs.
Are tooltips and pop-ups for notes accessible?
Often not. Hover-only tooltips fail keyboard and touch users. Make notes reachable by keyboard, dismissible, and persistent enough to read; better still, offer an inline or end-of-text rendering as an alternative to the pop-up.
How do I handle multiple scripts and right-to-left text?
Set the correct lang attribute on every passage and use dir="rtl" where needed so screen readers switch pronunciation and the browser lays text out correctly. Encode the language in your TEI so the front-end can emit it automatically.
Does colour-coded apparatus break accessibility?
If colour is the only signal, yes — it fails users with colour blindness and screen-reader users entirely. Pair every colour with a second cue such as an icon, label or underline, and expose the meaning in text.
How do I test edition accessibility without a full audit?
Run an automated checker (axe DevTools or WAVE) to catch contrast and markup issues, then do a keyboard-only pass and a quick screen-reader pass with NVDA or VoiceOver. That combination finds the large majority of real problems.