Building accessible visual software

A diagram editor, chart or map can carry meaning through position, colour and movement. Making it accessible means preserving the important information and tasks when someone uses a different input method or cannot rely on the visual arrangement.

Labels help, but they do not provide a complete route through an interactive product. A person may need to find an object, inspect its relationships, change a value and confirm that the change was saved.

Start by describing those tasks independently of the canvas. Then design the data and interaction model that lets people complete them.

Keep meaning outside the renderer

The pixels should be one presentation of structured application state. Keep objects, relationships, properties, selection and validation in a model that several interfaces can use.

A visual graph might share that state with a searchable list and a property inspector. Selecting an object in either view selects the same object. Editing its label applies the same validation and creates the same undo entry.

As a constructed example, consider a dependency graph. Someone should be able to find a node by name, read its incoming and outgoing relationships, follow one of those relationships, and edit a permitted property without dragging around the canvas.

The list does not need to reproduce every coordinate. It needs to expose the structure and actions that matter. If position itself represents time or responsibility, preserve those values in the alternative view.

This separation also makes software easier to test. Domain rules remain accessible without reproducing every pointer gesture, and a change of renderer need not change what the product means.

Design a complete keyboard route

Decide how focus enters the workspace, moves between useful regions and leaves again. Provide a way to find relevant objects without tabbing through thousands of marks.

Search, filters and an inspector can be more useful than a single enormous focus sequence. For a graph, navigation by relationship may help more than navigation by screen position. Explain the active order and make shortcuts discoverable.

Use native HTML controls where they fit. Buttons, fields, lists and tables carry useful semantics. A custom tree or graph widget requires its own interaction behaviour; assigning an ARIA role does not implement that behaviour. Follow a suitable WAI-ARIA Authoring Practices pattern and test it in the product's context.

Keep focus predictable after an edit, deletion or dialog. The next action should apply where the user expects. Provide an exit from custom keyboard handling, and avoid capturing keys that people need for ordinary browser or assistive-technology use.

Offer alternatives to dragging

Keyboard access and pointer alternatives address different needs. Someone using touch or a specialised pointer may be unable to drag but also unable to use keyboard shortcuts.

Provide controls that can be clicked or tapped without dragging. Moving an item could use a destination selector or move buttons. Connecting nodes could use a “Connect to” action. A slider can be paired with an editable value.

WCAG 2.2's dragging criterion distinguishes this single-pointer route from keyboard equivalence and specifies exceptions. Test both routes where the requirement applies; keyboard support alone does not establish that dragging has an adequate alternative.

The same principle helps with zoom and pan. Give users ways to search, fit the current selection and reach a useful scale without depending on a particular gesture.

Distinguish focus, selection and state

Focus indicates where keyboard input goes. Selection identifies what an action affects. Hover is temporary pointer context. These can coincide, but the interface should not assume they always do.

Make each relevant state visible and expose it through suitable semantics. Avoid colour as the only distinction. An outline, label or shape can preserve meaning when colours are difficult to distinguish.

Dynamic changes need a deliberate announcement strategy. Saved work, failed validation and a completed background task may warrant an announcement. Every pointer movement does not. Excessive live output can obscure the information someone needs.

Report errors in text and preserve the work where possible. A failed save should explain what remains unsaved and how to recover. If another user changes the same object, make that conflict understandable in both the visual and alternative views.

Explain what a visual shows

A chart needs a clear question, units and context. Give the reader the important pattern in text, then provide values when they need to inspect the evidence.

The W3C complex-image guidance describes short identification and a longer account of essential information. For an interactive chart, that account may combine a summary, accessible controls and a data table reflecting the current filters.

A table alone may make a trend laborious to discover. A summary alone may prevent someone checking an exact value. Choose the combination that supports the task, including uncertainty, missing values and transformed scales.

SVG can carry semantics, but a complex interactive SVG is not automatically accessible. Canvas usually needs a separate semantic interaction layer. Choose rendering technology for its visual and performance requirements, then test how that layer stays synchronised with the rest of the product.

Test the same task in different conditions

Exercise complete tasks with keyboard input, supported screen readers, touch, enlarged text and narrow layouts. Include long labels, dense data, empty states and failures. Check focus visibility, contrast and the effect of reduced motion.

On a small screen, make the useful task available rather than shrinking the desktop canvas. A list or inspector may become the primary view. Preserve selection and draft state when panels move or collapse.

Automated tools can find useful defects, but they cannot establish that the interaction is understandable or efficient. Include disabled users in research and evaluation, and record the environment and task actually tested.

Treat conformance claims separately from implementation effort. Adding labels or passing an automated scan does not establish WCAG conformance for a deployed product.

A sound accessibility design leaves people with the information, controls and recovery paths needed to complete the work. Test those paths as part of the product, using the same application state and rules as the visual interface.