Accessible content

Write instructions that remain usable when someone enlarges text, listens to it, uses a keyboard, or cannot distinguish the colors in a screenshot.

Structure carries meaning

Give a page a descriptive title and organize it with real headings. Do not simulate headings with bold paragraphs. Keep the hierarchy meaningful, and use lists or tables when they express real relationships.

Link text should identify its destination or purpose. Prefer “Export format requirements” to “Click here.” When a link downloads a document, identify the document and useful format information. Avoid using only color or position to distinguish a control.

Images and demonstrations

Describe an informative image’s purpose in its context. A screenshot caption can identify the changed setting; an alternative description should convey the information a reader needs without seeing it. Decorative images should not create repetitive speech. For a complex diagram, provide a nearby explanation or data table instead of forcing the whole explanation into a short label.

Do not make a screenshot the only source of a command, error, or exact value. Put copyable text in the article. A video demonstration needs captions for meaningful audio and descriptions of essential visuals. A separate transcript helps readers follow or look up the content; it does not replace synchronized captions. See spoken instructions and video for the different formats.

Controls, forms, and errors

Use a persistent label for a field; placeholder text disappears as someone types. State required input and format constraints before the error occurs. When an error does occur, name the field or operation and give a supported recovery action. Do not blame the reader or promise that work is safe unless the product guarantees it.

Keep the recognizable words of a visible label in its accessible name. Distinguish a control's name, current value, and state; avoid repeating a control type that assistive technology already announces. An icon-only control needs an action name, not just a description of the icon.

Write the action, then name a specific gesture only when that gesture matters. “Choose Export” can work across input methods; “drag the handle” is appropriate when the task specifically teaches dragging. Document a supported keyboard alternative where the task requires one, without inventing a shortcut.

Review in use

Read the page without images. Navigate its headings and links. Enlarge the text and check wrapping. Listen to an important procedure or inspect it with assistive technology. Test labels and error text in the actual product. Plain language helps, but readable prose alone does not prove WCAG conformance.

Write about people accurately

Use a person’s stated name and pronouns. For an unspecified person, singular they is natural in English; choose a grammatical equivalent in the target language. Avoid requesting a title or gender when the task does not need it.

Mention disability when it matters to the subject. Follow the person’s or community’s preference for identity-first or person-first wording. Neither order is a universal rule. Describe the relevant access need or support without presenting disability as a personal tragedy or an achievement to overcome.

Use examples that fit the task without assigning stereotyped roles or assuming one family structure, income, nationality, or way of using a computer. Describe the actual technical relationship instead of using an exclusionary metaphor. Preserve unavoidable identifiers and exact quotations; a blind replacement inside code can change its meaning.

Ordinary phrases such as “See the next section” need no automatic substitution. The test is whether the instruction requires a particular sense: “Choose Export” names a control, while “choose the blue button on the right” depends on sight, color, and layout.