If you need to get cloud data in front of someone who can't practically use a cloud provider's console, a LightPane pane is a far better starting point than the console. That is a large part of what we're for, and it shapes how we build.
What we commit to
Every pane is built to these, and they are enforced in our build rather than left to good intentions:
- Full keyboard navigation. Every pane is operable without a mouse — filters, disclosures, tabs and the refresh control are all reachable and usable from the keyboard.
- Colour is never the only signal. Status is always carried in text or shape as well as colour, so meaning never depends on colour perception alone.
- Configurable, tokenised colours. Status colours come from design tokens rather than hardcoded values, so palettes can be themed — including for contrast needs — without breaking meaning.
- Contrast checked in the build. Our pane linter checks every pane for AA-level colour contrast as part of the gate suite that runs on every change. It is enforced, not aspirational.
What we don't claim
We would rather be honest about the edges than over-promise:
- We don't claim WCAG conformance. We have automated contrast linting, not a tested conformance audit across the whole standard — and we won't make a conformance claim without a test that backs it.
- Screen-reader support for data tables is not solved. Making rich, interactive data tables work well with screen readers is genuinely hard, and the published approaches do not work well. We are not going to imply we have solved it when we have not.
Our rule going forward
No conformance claim without a test that backs it. If we later want to claim a standard, the work is the audit — not the sentence. Until then, the commitments above are things you can verify, and the linter that enforces the contrast one runs on every build.