Writing & accessibility
Review what a link or button promises
Use a reusable wording worksheet to compare a control’s visible label, accessible name, context, and actual result.
A label makes a small promise. “View schedule” suggests a destination; “Save draft” suggests an action. Reviewing that promise takes more than replacing every short label with a longer one. Choose a single link or button, establish what it actually does, and examine the wording in the places people encounter it.
Download the link and button label worksheet to keep the before-and-after record. It contains blank fields and a fictional example. This is a focused content review, separate from the broader tasks in your first accessibility review.
Write the result before the label
On a page you maintain, identify the control and describe its outcome in ordinary language. Does it open a resource, submit information, expand a section, or change a setting? Record what happens immediately and what remains pending. “Sends a request to prepare a report” is different from “downloads the completed report.” Review the behavior in an appropriate test environment before presenting it as established.
Then check that its role matches its job. WAI-ARIA describes a button as an action control and a link as a reference to a resource. A control’s visual shape does not settle the choice. A developer should resolve a mismatch in semantics or behavior; editing the label alone cannot repair it. Prefer native link behavior for navigation rather than assuming an ARIA role supplies it.
Sources: W3C WAI: Button Pattern, W3C WAI: Link Pattern
Read a link with the context it really has
For a link, record the destination and surrounding sentence or list item. Ask whether someone can determine its purpose from its text or from context that software can associate with it. A heading merely drawn near a card is not proof of that association. Check the content structure when the wording depends on nearby text.
WCAG’s Link Purpose criterion permits relevant programmatic context; it does not ban every “Read more” link. A descriptive label that works alone can still make navigation easier. Compare repeated labels on the page: do several identical phrases lead to meaningfully different resources? Rewrite where the distinction helps a person choose, and preserve concise labels when their purpose is already clear.
Sources: W3C WAI: Link Purpose (In Context)
Compare the visible words with the accessible name
The accessible name is the control’s programmatic name, which assistive technology can present or use. It may come from the control’s text or associated markup. Record the computed name with help from a developer or accessibility reviewer, rather than treating one attribute in isolation as the complete answer. Keep its description in a separate field; extra instructions are not necessarily part of its name.
For controls with visible text labels, WCAG’s Label in Name criterion requires that visible text be included in the accessible name. This helps someone activate a control by speaking the words they see. A visible “Save draft” paired with an accessible name of “Store document” is a fictional mismatch worth correcting. Matching wording supports consistency; it does not by itself prove that the action works.
Sources: W3C WAI: Providing Accessible Names and Descriptions, W3C WAI: Label in Name
Use seven fields to make the review repeatable
1. Record: page, component, state, version, date, and the task someone is trying to complete. 2. Promise: destination or action, including whether it completes now or starts later work.
3. Visible wording: exact text, icon meaning, and any surrounding explanation. 4. Programmatic wording: role, computed accessible name, description, and how these were checked. Mark them “not checked” when you cannot verify them.
5. Context and alternatives: associated sentence, list item, or other established context; nearby controls and repeated labels. 6. Proposed change: exact replacement, reason, and any required behavior or markup repair. 7. Verification: observed result, remaining questions, and the person responsible for the next review.
The worksheet keeps these fields together. Retain the old wording so that a later reviewer can understand why the change was made. Use actual observations for a real page and distinguish a suggested replacement from a verified improvement.
Work through one fictional label
Imagine a fictional schedule page with two buttons: “Save” and “Send.” The first stores a draft; the second sends it to the sample team. The initial accessible name for “Save” is “Store schedule.” The worksheet identifies two questions: whether the visible wording distinguishes the draft action clearly, and whether the programmatic name includes the visible words.
The proposed replacement is visible text “Save draft,” with an accessible name of “Save draft.” The proposed “Send schedule” label remains a separate action. The record still says “Not checked” for saving, sending, and any assistive-technology behavior. No test has occurred in this example, so the proposal is not described as a measured usability improvement.
Check the replacement in the complete interaction
Put the draft wording back into the page, then repeat the original task. Read the action before activating it and compare the result with its promise. Inspect the updated accessible name, the surrounding explanation, and related controls. Include another state if the label changes after an action. Record the browser and any assistive technology actually used instead of implying wider coverage.
Look for cramped or clipped text after the edit, including at increased zoom. Keep words that distinguish the action; do not add length for its own sake. W3C’s Headings and Labels guidance emphasizes descriptive purpose and allows short wording where it supplies an appropriate cue. If the review reveals a problem with control behavior, give that issue its own follow-up rather than treating a clearer label as its resolution.
For the next question, use the Resource Atlas to find primary guidance on forms, content structure, and accessibility. Carry the completed wording record into the broader page review so that its limits and unfinished checks stay visible.
Sources: W3C WAI: Headings and Labels