At Elastic, building software with care for the people who rely on it means making accessibility a core part of product quality, it's not a side project for us. Over the last several months, our focus has been threefold: thoroughly auditing real user journeys, implementing fixes in sustainable ways, and making automated accessibility checks easier to adopt and impossible to ignore.
A Quick Reality Check: Disability is Common
It helps to ground this work in the facts: disability is not niche.
-
Globally: Approximately 1.3 billion people, or 1 in 6, experience significant disability.
-
United States: 28.7% of adults have some type of disability (more than 1 in 4).
-
Canada: 27% of Canadians aged 15+, about 8.0 million people, have one or more disabilities that limit daily activities.
When we talk about accessibility, we are talking about a meaningful portion of our users, our colleagues, and our community.
Why This Work Matters to Our Users
Our users rely on Elastic products to perform essential work. When accessibility breaks, real work is stopped:
-
If the UI breaks at 400% zoom, a critical task can't be completed.
-
If important updates aren’t announced, vital information is missed.
-
If keyboard focus gets lost, complex workflows become frustrating or impossible.
-
If contrast is low, content is hard to read or effectively invisible.
Beyond the user experience, regulations matter. Compliance with standards like Section 508 (U.S.) and the European Accessibility Act is a legal requirement for doing business in those markets. The bigger trend is clear: accessibility laws are tightening globally, and the bar for compliance is steadily rising.
What 'Accessible' Means to Us
In plain terms, it means our products empower people to:
-
Perceive the content: Using text alternatives, proper contrast, and meaningful structure.
-
Operate the interface: Relying on full keyboard support and predictable focus.
-
Understand what’s happening: Through clear labels, visible errors, and meaningful announcements.
-
Use it reliably: Across different settings like high zoom, content reflow, and motion preferences.
Our Approach: Building Guardrails, Not Relying on Heroics
We aim for accessibility to be consistent and scalable. This means catching issues early, leveraging shared patterns, and reducing regressions over time. As outlined in the Kibana accessibility statement, we invest in an accessible component library, staff training, and ongoing audits with fixes prioritized in a reasonable timeframe.
Key Focus Areas and Progress
We've focused on seven areas to embed accessibility deeply into our development lifecycle:
1) Structured Auditing and Lifecycle Integration
We've completed full WCAG A and AA audits for major product areas. We map screens and flows, test with keyboard and screen readers, validate at high zoom and with reflow, and document clear reproduction steps. Accessibility is now integrated into design reviews, pre-release quality checks, and quarterly post-release audits.
2) Improving Conformance Reporting
After each cycle, we update our Accessibility Conformance Reports (ACRs/VPATs). Crucially, every issue we raise is mapped directly to the relevant WCAG success criteria, making the 'why' behind each fix explicit.
3) Driving Fixes with Real Follow-Through
We partner closely with teams to break down large problems, unblock progress, and verify fixes in context, ensuring issues are resolved and verified.
4) Making Automated Checks Stricter
We are moving away from "best effort" checks. Violations now fail tests, which creates a necessary feedback loop and encourages fixing root causes. Our testing intentionally blends manual and automated methods.
5) Stabilizing Test Coverage
We’ve brought inactive test suites back online, dug into flakiness (often caused by loading states, overlays, or timing quirks), and tightened up setup and stability so teams can actually trust the signal when tests fail. In parallel, we’ve made sure any new test infrastructure the broader engineering org adopts includes first-class support for adding accessibility-focused functional tests.
6) Transparency on Current State
We aim for WCAG 2.2 Level AA conformance. We are transparent that Kibana currently partially conforms (some success criteria are still being addressed). We also publicly acknowledge known limitations and work in progress areas, such as complex charts, maps, and some table semantics, tracking progress publicly here. Here is our chart showing how many accessibility issues are currently open:
7) Measuring Progress
This is an iterative process: assess, prioritize, fix, verify, report, and prevent regressions. Since 2024, we've identified over 2,500 accessibility issues and have triaged and resolved more than 1,800, following a phased approach (Level A baseline, then Level AA). Here is our chart showing how many issues closed since last year:
We are excited about the future of accessibility at Elastic. We welcome your feedback. Please write to us at accessibility@elastic.co.