Web Accessibility
When was the last time you visited a website and got frustrated because you had trouble using it? Maybe the site was using WebGL technology that your browser didn’t support, you couldn’t read its text due to it being so small. If you think back to these annoying experiences where you functionally could not navigate a site, chances are you’ve experienced inaccessibility in one form or another.
This is not to say that all frustrating experiences are inaccessible, but there are definitely overlaps between bad UX and inaccessibility.
Specifically, it focuses on people who have disabilities that impede their vision, hearing, and movement. Web accessibility means that websites, tools, and technologies are designed and developed so that people with disabilities can use them. More specifically, people can perceive, understand, navigate, and interact with the web.
-
Perceivable: Can users consume content on your site in different ways? For example, providing closed captions for a video.
-
Operable: Can the site function without confusion and without the use of a mouse or complex interactions?
-
Understandable: Can a user understand how the user interface of the site functions and the information on the site?
-
Robust: Can different assistive devices (screen readers, for example) understand the website?
Each of these different principles have a success rating of either A, AA, or AAA. An A rating is the minimum requirement for having an accessible site and AAA is the gold standard of accessibility.
Goals of Accessibility in Kibana
The goals for our accessibility efforts go beyond compliance. We want all humans to feel empowered to understand and affect the world when they use Elastic products. You can find our statement under Accessibility in the Kibana docs. Kibana aims to meet WCAG 2.1 level AA compliance. Currently, we can only claim to partially conform, meaning we do not fully meet all of the success criteria. However, we do try to take a broader view of accessibility, and go above and beyond the legal and regulatory standards to provide a good experience for all of our users.
We continue to look into ways to improve our products’ accessibility, including more comprehensive tools for testing during development and to catch regressions.
Assessment approach
Elastic assesses the accessibility of Kibana with the following approaches:
- Self-evaluation: Our employees are familiar with accessibility standards and review new designs and implemented features to confirm that they are accessible.
- External evaluation: We engage external contractors to help us conduct an independent assessment and generate a formal VPAT. Please email accessibility@elastic.co if you’d like a copy.
- Automated evaluation: We are starting to run axe on every page. See our current progress in the automated testing GitHub issue.
Manual testing largely focuses on screen reader support and is done on:
- VoiceOver on MacOS with Safari, Chrome and Edge
- NVDA on Windows with Chrome and Firefox
EUI, or Elastic UI, is the component library that’s behind all of the UI that we create at Elastic. An accessibility focus at this foundational layer of our work ensures solid building blocks supporting every piece of UI we create. By consolidating all of our most used patterns in one area, we’re able to provide consistent experiences and handle lots of accessibility concerns before the scores of implementing developers — from Kibana, to Elastic Cloud, to every other UI team, internal and external — even get to work.
Some examples of small EUI accessibility bug fixes which went into the 7.16.0 release.
- [EuiPopover] Allow content to be accessible during opening animation by thompsongl · Pull Request #5249 · elastic/eui · GitHub
- https://github.com/elastic/eui/pull/5241
Example of Accessibility (often abbreviated to A11y) testing :
- Documentation for a11y testing in Kibana can be found here.
- Meta issue for accessibility testing in Kibana can be found here.
- An example of kibana a11y functional test can be found in this file that contains a11y tests for the ILM plugin.
Despite our best efforts to ensure accessibility in Kibana, there might be some limitations. Please open an issue on GitHub if you observe an issue not listed.
Known limitations are in the following areas:
- Charts: We have a clear plan for the first steps of making charts accessible. We’ve opened this Charts accessibility ticket on GitHub for tracking our progress.
- Maps: Maps might pose difficulties to users with vision disabilities. We welcome your input on making our maps accessible. Go to the Maps accessibility ticket on GitHub to join the discussion and view our plans.
- Tables: Although generally accessible and marked-up as standard HTML tables with column headers, tables rarely make use of row headers and have poor captions. You will see incremental improvements as various applications in Kibana adopt a new accessible component.
- Color contrast: Modern Kibana interfaces generally do not have color contrast issues. However, older code might fall below the recommended contrast levels. As we continue to update our code, this issue will phase out naturally. We have recently added textures in addition to colors to enhance readability and accessibility of charts.