Accessible dashboards: colour, labels, and focus

Colour is an efficient encoding but a fragile one. Colour vision deficiency is common, and many more people view dashboards on poor screens, in bright light, or with reduced contrast settings. If a red and green pair is the only distinction between two series, part of the audience cannot read the chart.

Use redundant encoding: colour plus a direct label, a dashed line, a marker shape, or separate small multiples. A legend helps only if the viewer can match the swatches, so direct labels are stronger. Check a greyscale screenshot; if the chart collapses into one tone, the encoding is not accessible.

Use colour deliberately: a single hue for one series, a sequential ramp for magnitude, a diverging ramp only when values sit either side of a meaningful midpoint, and a small categorical palette for groups. Too many categorical colours become hard to distinguish, especially in charts with thin lines.

Check contrast between adjacent colours and between marks and background. Do not rely on red and green to signal good and bad; pair the colour with an icon, a label, or a position. In dark mode, test again: a palette that works on white often loses contrast on a dark surface, and vice versa.

Titles should state the question or the finding, not the data source. A subtitle can carry the period, filters, and units. Axis labels need units, and values need consistent precision. An acronym the team understands may be opaque to a new viewer.

Label series directly at the end of lines where space allows, and order the legend to match the visual order. Provide a short text summary of the chart's main point for viewers who cannot see it, and make sure the same information is available in a table or export. Text alternatives should describe the takeaway, not list every number.

Every interactive element needs a visible focus indicator and a logical tab order. Filters, drill controls, and export buttons should be reachable without a mouse. When a filter applies, keep focus in a predictable place rather than resetting to the top of the page.

Tooltips that appear only on hover are unavailable to keyboard and touch users. Make the same values available on focus, in a data table, or in a persistent label. Avoid keyboard traps in embedded frames and custom dropdowns, and check that the focus ring is visible against both themes.

Charts are images unless the tool exposes structured data. Give each visual an accessible name and a summary, and keep a table alternative for the numbers. Mark up table headers properly so a screen reader can associate cells with columns.

Test at 200 per cent zoom and with increased system text size. Layouts that use fixed heights clip labels; charts that rely on precise pixel positions overlap. Content should reflow into a single column without horizontal scrolling. Truncation is an accessibility failure, not a cosmetic one.

Accessibility checks are cheaper when they are part of the build, not a separate audit at the end. Add them to the dashboard acceptance checklist alongside reconciliation, and fix issues before the page is published.

The checks below are deliberately manual. Automated tools catch some contrast and markup problems, but they cannot tell you whether the chart still makes sense without colour or whether the focus order matches the reading order.