How to build an accessible digital magazine article

What to take away

This method follows one feature from manuscript to web or EPUB edition. A tagged PDF can reuse the same editorial decisions, though its production tools and tests differ. The article has to stay understandable when presentation changes.

Photo and credit

The photograph shows one form of reading output. It does not imply that all braille users work this way, or that the device tested this article.

Build the content map first

List the parts of the piece in reading order: title, dek, byline, key points. Then list main sections, figures and captions, tables, notes. Then list pull quotes, audio and download controls, and end matter. Do that before anyone opens a layout tool.

The map is the commissioning document. A designer who receives it can set a grid without guessing which block carries the argument. A subeditor can see where a sidebar belongs.

Use one heading hierarchy, chosen for meaning rather than visual size. Keep a sidebar next to the section it explains. Decide whether a pull quote adds information or just repeats a line the reader has already passed.

Read the unstyled document

Read the plain document start to finish. The order should make sense without columns, floating cards, drop caps, or coordinates on a page.

Place each caption with its figure. Introduce a complex table or graphic in the prose before it appears. Do not duplicate visible text in hidden fields, because a screen reader announces it twice and the reader loses their place.

The W3C page structure tutorial covers how headings, regions and labels support navigation for screen-reader, keyboard, low-vision and mobile users. Reach for native elements before adding ARIA roles to imitate them.

Text, links and emphasis

Set the document language and mark any language change inside the text. Expand an unfamiliar abbreviation on first use.

Write link text that names the destination or the action. A link read out of context as a list should still tell the reader where it goes. "Click here" tells them nothing.

Do not carry meaning in bold, italics, colour, position or typography alone. If a warning is red, give it a label or symbol with words. If an instruction says "use the button on the right," name the button too.

Classify every image

Each image gets one treatment, decided by its job in the article.

Write the alternative in the context of the article. A portrait caption may already name the person and the event, so the alternative can carry visible detail the caption leaves out. Do not open every description with "image of."

Tables and data components

Use tables for data relationships, never for page layout. Mark up the caption, the headers, the data cells and the associations between them. Simplify split, nested or multi-level grids where the material allows.

Offer the same data as a download only as an addition. It does not replace a table the reader can follow in the flow of the article.

For a chart, state the main finding in prose and give the underlying values or a full description. Test with enlarged text and a narrow viewport so labels do not collide or vanish.

Audio, video and controls

Edit captions for accuracy, timing, speaker identification and meaningful sounds. Provide a transcript for audio, and description for visual information the soundtrack does not carry.

The W3C page on transcripts separates two kinds. A basic transcript is the speech and the non-speech audio needed to follow it. A descriptive transcript adds the visual information needed to follow it, which makes the piece available to people who are both deaf and blind.

Decide which kind a package needs before you commission the media. The descriptive version depends on notes taken while the material is being made.

Controls need visible focus, keyboard operation, accessible names, state changes and predictable behaviour. Do not autoplay sound. Give animation a pause or stop control where required, and respect a reader's motion preference.

Publication metadata

Every edition needs a unique title, an author, a language and a description. Add the publication date, the modification date, a stable identifier and the reading order.

For EPUB, add the navigation and accessibility metadata the chosen specification requires. For web delivery, check the page title, the main region, the article label and any structured data against the visible facts on the page.

Test and release

Validate the code or package structure, then run a manual pass. Work through the keyboard path from the address bar to the final control, checking visible focus and looking for traps.

Listen to the headings and regions in announced order, then zoom and reflow at a narrow width. Read the article with a screen reader and check control names. Confirm images announce an alternative or stay correctly silent, and that table headers and cell navigation work.

Check captions, transcripts and media controls. Finally, walk the subscription, sign-in, consent and download paths.

Record the tool versions and devices you used. Log each finding, the fix, the retest and any known limit, then the release approval. Preserve the exact build identifier you tested, so a later query can be answered against the same file.

Common questions

Can visual order differ from reading order?

It can, but large differences create risk. Keep the logical source order clear and make sure it does not contradict the visual sequence.

Should a pull quote be announced twice?

Usually not, when it repeats nearby text. Treat the display version as decorative, or remove the duplicate from the accessibility tree according to the format.

Is automated alt text acceptable?

It may help with drafting. An editor still has to judge purpose, accuracy, context, privacy and unnecessary detail.

What should be archived?

Keep the structured source, the media alternatives, the tested output, and the validation reports.
Also keep the manual findings, the approvals, and the accessibility metadata.