Accessible Graphic Controls and Text Equivalents

Working case

An inspection map shows 47 marks, including region 29 with a high-severity seal split. The companion region list states each mark’s location, severity, and note. Reviewer 47 can select region 29 through the SVG or the list, then use the same edit form. A color change signals severity visually, while a text label and shape cue convey it without color. At 200 percent zoom, the list remains readable even when the graphic requires panning. When a live reading changes, a bounded status announces the meaningful update rather than every pixel redraw.

Implementation boundary

function regionLabel(region) {
  return `Region ${region.id}: ${region.severity} severity, ${region.note}`;
}
console.log(regionLabel({ id: 29, severity: "high", note: "seal split" }));
// Output: Region 29: high severity, seal split

Define the information task before writing alternative text: identify a defect, compare severity, or edit a mark. Use a short graphic name and a richer structured list when many regions matter. Ensure interactive elements have stable names and visible focus, and provide keyboard equivalents for pointing and dragging. Use one selection reducer for graphic and list inputs. Avoid making every decorative path separately focusable. For a Canvas, supply ordinary buttons and descriptive content outside or within fallback markup, then verify actual assistive-technology behavior on supported browsers.

Cost and boundaries

A text list adds DOM nodes proportional to meaningful records, but it can replace expensive custom keyboard handling and exposes content for search and printing. Announcing every sensor frame would overwhelm assistive technology, so summarize only state changes that matter. A large SVG accessibility tree can also become slow if hundreds of incidental paths are exposed. Group decorative shapes and keep actionable regions bounded. Measure task completion with keyboard and screen reader, not only graphics frame rate.

Failure trace

A reviewer can see a red region but its list item still says “low severity” after an update. Another implementation makes the entire Canvas one unnamed button; there is no way to select region 29 without a pointer. Test record addition, deletion, overlapping marks, severity change, zoom, high contrast, keyboard-only input, and screen reader reading order. Compare selected IDs and descriptions across paths after each mutation; do not rely on an image title as the only explanation.

Verification

• Graphic and list use the same record ID and severity.
• Every action has a keyboard path.
• A meaningful text representation survives graphic failure.

Practice drill

Build a 47-item scene and companion list from the same records. Select region 29 from the map, then from the list; inspect focus and selected ID. Change severity and verify both views and the status text. Disable color and try the task using labels and outlines. Then disable the graphic entirely and ask a reviewer to find and edit the seal split using only the text representation.

Decision note

Model graphic meaning as records and controls that remain usable when pixels are unavailable.

Common Mistakes

• Using color as the only severity signal.
• Making every decorative path focusable.
• Treating one generic image label as equivalent to 47 marks.

Connected lessons

Build Project: accessible inspection map and export and review Web Development: graphics and editor decisions quiz; follow Interactive Graphics and Canvas Boundaries; SVG, Canvas, Scene Model, and Hit Testing; Canvas Pixel Ratio and Pointer Coordinates; Canvas Origin-Clean Export and Private Assets; Chart and Diagram Text Equivalents; Pointer Gesture, Touch Action, and Alternate Control.