Bokeh Accessibility Audit Summary#
[Date of latest draft: February 2025]
Introduction#
Previously, no large-scale audits or evaluations of the accessibility of a data visualization library have been made publicly available.
Thanks to CZI Essential Open Source Software (EOSS) Cycle 6 grant “Accessible interactive data visualizations in Python with Bokeh,” we have have conducted a thorough, ecosystem-wide audit of the accessibility capabilities of the Python data visualization library, Bokeh.
We present our audit’s Findings and Suggestions in this summary document. There are a total of 76 documents that contain evidence of different accessibility barriers in Bokeh’s ecosystem.
Findings: To make sense of this volume of information, the first section of this summary (Findings) focuses on providing an overview of problems and themes present in all of the evidence we gathered from Bokeh’s plotting interface (+30 tests with evidence of failure), plot tools (+20), and annotations (+26) artifacts.
Themes: The subsections of Findings below each represent higher level themes that emerged across the evidence we have gathered. Each theme’s subsection contains an explanation of that theme, evidence of that theme (with links), and an example demonstration of what an accessibility barrier related to that theme looks like.
Evidence citations: Each of the evidence documents are cited using a prefix, A-, PI-, or PT- referring each to the abbreviations for “Annotations,” “Plotting Interface,” and “Plot Tools.” We conducted full, systematic audits for each of these subsystems within Bokeh’s ecosystem, as they are each responsible for different aspects of Bokeh’s capabilities. A given evidence document then also has a suffix, which is the number corresponding to the listed number of failures within that subsystem. So in our audit of Bokeh’s annotations subsystem, evidence “A-2” would correspond to the second test type that contained an error.
Evidence documents: Each citation to evidence links to a document of that evidence. Each evidence document contains information organized under the following headings:
Test Type Performed
Artifact Evaluated
Results Summary
Expected Behavior (Pass/Fail)
Image or Video of Failure
Steps to Reproduce
Guidelines and Standards Used
(optional) Related Evidence
Technical Details
(optional) Notes
Suggestions: The second section of this summary document (Suggestions) presents several focus areas for remediation based on the connectedness of various issues, prioritization of critical failures, and (in some cases) the ease of the fix involved. The remediation process should be negotiated and discussed broadly, broken into an actionable plan, and then enacted. Our suggestions should not serve as an end to this discussion, but just a way to get it started.
Getting involved: Bokeh is an open source community, which means that there are many opportunities to get involved. We aren’t just interested in collaborations with accessibility experts, but also believe that building up accessibility-focused skills within the Python community would be invaluable. So, if you’re new to accessibility, we would still love for you to learn more and get involved. We need more Python communities that prioritize accessibility. Check out our Github and Bokeh’s to get started.
Methodolody#
Our evaluation methodology was primarily an application of Chartability on a Bokeh dashboard.
Chartability was chosen because it is a framework designed specifically for auditing the accessibility of interactive data visualizations. The workbook for Chartability expands more on the practical method for using it, while Chartability’s research paper explains how it was designed and tested. Chartability is based primarily on applying accessibility standards to visualization and, where standards are insufficient, applying research and community practice.
We built an interactive data visualization dashboard environment that was designed to showcase a specific breadth of Bokeh’s plotting, tooling, and annotation capabilities. Charts (which include line, bar, and scatter) demonstrated tooltips, visual filtering via clicking elements, plot tools activated via icons (which included zooming, panning, and other features), as well as special marks and text added to the visual space of certain charts. A Bokeh table was provided, as well as a tab-based user interface that enabled additional interactive views of a particular dataset. Unless otherwise noted, our evidence gathered exclusively used this environment for evaluation.
Note
Some context on auditing and systematic evaluation: It is important to note that audits, when performed true to their intent, are about focusing on gathering evidence of failures, issues, gaps, or problems. While simply auditing can then establish a direct line between evidence of a failure and opening an issue on GitHub, we used auditing as an opportunity to take a step back. Our evidence serves as a basis for an analysis of systemic and interconnected issues across Bokeh’s ecosystem. What separates this kind of high-level audit from the typical atomic or incremental approach most commonly used in open source software (which is often ad hoc) is that we have a chance to evaluate and analyze an entire ecosystem and synthesize all possible related problems at once. Addressing incremental problems as they arise can have limits, especially if there are significantly interconnected issues. As an example, it is common to see an issue on an open source repo that asks for “alt text capabilities.” While this might be great to add on, sometimes a library or tool needs several larger refactors or overhauls to really reach ideals/goals and uphold principles of good design. Data visualization libraries in particular have a habit of simply implementing ARIA directly on chart elements to address a problem like “alt text” but fail to recognize that this easily sets up new and more complex accessibility barriers down the road. In order to do a more systematic evaluation (and even know what the larger issues are), having a procedure for gathering evidence, taking a step back, finding similarities, connecting the biggest gaps, and setting goalposts is vital. Consider this document as a demonstration of this process.
Credits#
Big collaborations like this involve many different kinds of labor. We use the Contributor Role Taxonomy (CRediT) Classification system to acknowledge the specific work each team member did to contribute to our success.
Frank Elavsky, CMU, @frankelavsky: writing - original draft preparation (lead), data curation (lead), formal analysis (lead), investigation (lead), methodology (lead), conceptualization (supporting), project administration (supporting), and software (supporting).
Tania Allard, Quansight, @trallard: conceptualization (lead), funding acquisition (lead), resources (lead), project administration (lead), supervision (lead), writing - review and editing (lead), software (supporting), visualization (supporting).
Pavithra Eswaramoorthy, Quansight, @pavithraes: software (lead), visualization (lead), conceptualization (supporting), funding acquisition (supporting), data curation (supporting), resources (supporting), writing - review and editing (supporting).
Gabriel Fouasnon, Quansight, @gabalafou: writing - review and editing (supporting), validation (supporting)
Mateusz Paprocki, Anaconda, @mattpap: software (supporting), visualization (supporting), conceptualization (supporting), writing - review and editing (supporting)
Overview of findings: problems and themes#
This section will break down the major themes related to problems or meta-issues as a result of our auditing evaluation.
1. Finding: Lacks foundational accessibility#
I don’t think this will come as a surprise to the Bokeh team, but it is quite clear that Bokeh has substantial gaps for basic text and interaction accessibility.
Providing alternative text will not be enough for Bokeh to become accessible, either. Textual design overall is lacking, which includes much more than alt text. And due to the complexity of interaction that Bokeh is capable of, significantly more work will need to be done to lay the groundwork for assistive technology and interactivity access.
Many, many tests failed because of this. Our 2 focus areas:
A. Has little textual accessibility#
Across our tests, this was the most consistent finding and also the type of failure that intersects with the most evidence.
Both screen reader accessibility and cognitive accessibility require good text design, which means this is fundamental to include in order to support assistive technologies. Text should be a deeply embedded part of any interface but especially one that relies heavily on visuals, data, and complex interactivity.
Note that only alt text (and aria-labels) are hidden visually. But overall, the accessibility of a textual experience that accompanies an analytical dashboard, visualization, or interface, is the cornerstone contributor to the overall accessibility of that artifact. Text accessibility is paramount.
Not only should screen readers be provided descriptions so that screen reader users can perceive what content is (at both a high level through alt but also a low level via tables and elements with aria labels), but descriptions should be provided for how to interact, why things are the way they are, and more. Making these additional textual descriptions and experiences visually available has a broad impact on who gets included, how much work an interface is asking its users to do, and ultimately how successful the usability of that interface is. Better text makes for a better experience for everyone.
Busy executives can look at an interface and make faster decisions. Scientists can share their work more clearly and succinctly with their peers. Novices can learn more quickly. And of course, people with disabilities can be included.
Text design must consider all possible text in an interface and includes: titles, subtitles, captions, alt text on a visualization, aria labels on navigation elements, aria labels on interactive elements, semantics and aria roles are provided, tables of data, descriptions and help menus, and more.
This finding is primarily about the fact that a significant amount of text that should be present in the interface (and under the hood) simply isn’t.
Evidence of this finding#
- Elements are visual only [PT-18, PI-28, A-24].
- Only one modality/input is provided [PT-13, PI-17, A-13].
- Metrics and variables are not defined [PI-16].
- Cannot be navigated according to narrative/structure [PI-18, A-14].
- Semantically invalid [PT-14, PI-20, A-15].
- No title, summary, or caption provided [PI-27].
- Axis labels are not clear or present [PI-1].
- No table [PI-23].
- Visually apparent features are not described [PT-19, PI-29, A-25].
Example#
Example taken from plotting interface [PI-28]. Below demonstrates that the lack of textual information excludes screen reader users from participation.
A web browser is shown with multiple charts. A screen reader navigates through the page and through multiple charts, but very limited information is given as they do so (fails).
2. Finding: Perceivability and understandability have barriers#
Understandability (and cognitive support) can be a difficult thing to ask a visualization library/tool to provide. It is always ultimately the responsibility of the implementer of a tool to provide end users with cognitive access. The application and use of a library (E.g. the contexts where Bokeh is used) should explain, describe, make outcomes easy, and provide robust alternative ways to reach those outcomes.
However, there are some cognitive support areas that a visualization library should be responsible for. And of course, there are many things that a visualization library can assist developer-users and designer-users with. Below we are focusing on issues that either fall under the purview of Bokeh or are things that Bokeh can do to assist their users with.
As for perceivability (perceptual accessibility), ultimately being able to find things intersects strongly with cognitive issues. If users can’t perceive elements (whether they are buried/hidden, left out, or hard to perceive), then they will have to mentally fill gaps, perform additional labor, or might even be excluded from using the interface altogether.
A. Findability and perceivability has problems#
Users need to be able to find things. Perception and discovery should be easy tasks. And unfortunately, there are some elements that are essentially invisible or hidden in our testing environment. Hard-to-see and hard-to-find elements can add difficulty or even make certain things impossible about Bokeh’s usage.
For screen reader users, semantic labels need to exist for interactive elements so that they know what a particular button or input does and its current state. And without proper labels on elements, they are virtually invisible to screen reader users.
For low vision users, high contrast is paramount. Contrast is the difference or “discriminability” between two things. High contrast means that things can easily be distinguished or discriminated from one another. In accessibility, we test the color of foreground elements against the color of adjacent elements and background elements. Color contrast must be high enough on anything that is meaningful, provide information, helps the user understand what something is, and is capable of performing some sort of interaction. In particular, contrast must be especially strong and well-designed on interactive elements. Elements that display a change of state (from off to on) need to be perceivable in the “off” state if it is still interactive. And elements with a change of state need to have a minimum contrast between the previous state and new state after interaction.
For sighted mouse users with motor and dexterity disabilities, tooltips can be helpful on chart elements but the target size of elements (such as in the line chart) are far too small. Discovering that tooltips exist on an element using pixel-perfect strategies actually creates accessibility barriers for all kinds of folks (but especially those with dexterity disabilities such as tremors or upper-body motor impairments). Being honest, I didn’t even notice that the second line chart on the dashboard had tooltips enabled until I found them by accident testing for contrast.
Evidence of this finding#
- Elements are visual only [PT-18, PI-28, A-24].
- Semantically invalid [PT-14, PI-20, A-15].
- Color contrast [PT-3, PI-3, A-2].
- Low contrast for interactive elements [PT-4, PI-4, A-3].
- Target pointer size is too small [PT-17, PI-25, A-21].
- Interaction is tedious [A-22].
- Data density [PI-25].
- Spacing [PT-15, PI-22, A-18].
- Focus indicator not perceivable [PT-11, PI-13, A-11].
- Meaningful elements can be distinguished [PI-15, A-12].
Example#
Example taken from annotations [A-2]. Below demonstrates the near-invisibility of the interactive annotation element used to toggle a line chart on and off.
A double line chart is shown. A color selection dropper is highlighting a selected ‘muted’, grayed out line. The contrast checking score of 1.27 is shown on the bottom left corner (fails).#
B. Understanding is not easy#
In general, everything should be easy to understand for folks who have never before encountered a Bokeh chart, its interactive capabilities, and its annotations.
What a chart shows should be described. Why some information has been visualized should be explained. How a user can interact should be clearly explained, including with instructions provided for more complex interactions (like lasso, etc). All text and labels should be made legible and presented at a reasonable reading level.
Bokeh’s cognitive support overall seems to be geared toward supporting software developers who are using the library while generally leaving end-user understandability up to the user’s own ability to poke around with interactivity, grok context/use, and self-interpret.
In general, Bokeh doesn’t appear to provide any assistance to developers in authoring textual descriptions, providing end-user oriented instructions/explanations, and also appears to have minimal support for automatically simplifying/formatting data-oriented numerical values (such as using too many decimal points of precision in a label).
Also, Bokeh is a library grounded on interaction with data and data visualizations. One important area of cognitive accessibility to consider is that there are many valid ways to interact with data. But by providing only one narrow path to reach a particular piece of information or outcome is a cognitive accessibility barrier as it assumes that users will always understand, remember, and correctly execute that given path of interaction.
The simplest example of a “narrow path” of interaction design is something like using a lasso filter. That’s just one kind of filter, and it requires the ability to use a pointer device (like a mouse), click and drag, as well as perception and memory of the previous and post states of the filter action. If there are no other ways to easily and richly filter data in an interactive way (like providing queries, dropdowns, text inputs, command line, voice control, downloadable data, etc), then this single lasso action actually creates exclusion for many people. The lasso itself is just one path, but interactively filtering is the analytical task. Providing multiple ways to do this, with special care for considering different disabilities and preferences that users might have, is an ideal way to design accessible experiences.
Evidence of this finding#
- No title, summary, or caption provided [PI-27].
- Axis labels are not clear or present [PI-1].
- No table [PI-23].
- Visually apparent features are not described [PT-19, PI-29, A-25].
- Explanation or purpose [PT-8, PI-9, A-6].
- No interaction cues or instructions [PT-7, PI-7, A-5].
- Not human-readable [PI-11, A-8].
- Only one modality/input is provided [PT-13, PI-17, A-13].
- Metrics and variables are not defined [PI-16].
- Cannot be navigated according to narrative/structure [PI-18, A-14].
- Single process [PI-21, A-17].
- Interactive context is not clear [PT-10, A-10].
- Complex actions have no alternatives [PT-2].
- Information complexity [PI-12].
Example#
Example taken from plotting interface [PI-12]. Below demonstrates how lack of encoding channels (using different colors) hurts discriminability and adds complexity.
A scatter plot is shown. Three categories are shown, but are hard to differentiate from one another based on their color and patterns.#
C. Interactive capabilities and system state are not clear#
Interactive data visualization comes with an additional layer of cognitive accessibility issues: keeping track of what could happen, is happening, and has happened in a system.
Initially, users will need to know what interactions are possible. Without cues that invite/demonstrate interaction or easily discoverable instructions, users will likely not even use the interactive features of a visualization.
Additionally, when change takes place in a system, it should be easy to both anticipate or know the context of what will change as well as follow the change as it happens. During interaction, users should have a clear sense of where change takes place if it isn’t in the same location where their focus currently is (this applies to sighted as well as blind users). In addition, once change takes place, it should be clear that the action has taken place and completed. Systems must provide rich, multimodal channels of feedback in response to user input.
Lastly, after change has taken place, users should be able to easily undo their actions, know their current location within an interaction process, have a sense of their interaction history, and be able to share and reproduce the current state of their interactive work. Presently, the general design pattern assumes that users will come to a visualization, interact, and then if they leave the page or wish to share their work with someone else, the work must be completely reconstructed from scratch.
Again, as mentioned previously in this audit summary: it is difficult to expect a visualization library to handle everything that would make an interactive application experience more accessible. The burden of higher-level system accessibility (such as history, sharing, reproducibility, saving, loading, etc) often falls to systems that implement interactive charts. However, the fact that Bokeh fails should be noted as an area of potential improvement. Systems and utilities could be in place to facilitate these functionalities more easily.
Evidence of this finding#
- Explanation or purpose [PT-8, PI-9, A-6].
- No interaction cues or instructions [PT-7, PI-7, A-5].
- Interactive context is not clear [PT-10, A-10].
- Changes are not easy to follow [PT-1, PI-2, A-1].
- Interactions are not forgivable [PT-9, A-9].
- State is not easy to share or reproduce [A-16].
- Location and history is not clear [PT-12, PI-14].
Example#
Example taken from annotations [A-16]. Below demonstrates how a screen reader user interacts with an input and then loses their location and focus, in addition to receiving no system feedback about their original input.
A scatter plot is shown. A screen reader is navigating through the chart's dropdown menu, but when an option is selected, the user is forced back to the top of the webpage.
3. Finding: System is fragile#
This part in an audit can be difficult because it can feel like asking a distinct tool like a hammer to be transformed into a rocket ship. This part of an audit is when the shortcomings of older, smaller, or just-emerging technologies come to light. Systems, especially ones that are tools, can often be built as a response to the needs of a specific community. Bokeh, in that sense, emerged to provide a better way to visualize data in Python for a web context. But the community that uses and consumes Bokeh is broader than the underlying system was originally designed for.
Tools and systems should not be fragile. They should be able to withstand different environments, used by different people in different ways, and allow for end-user personalization, customization, and adaptation.
Systems engineering is always held in tension: good engineering is built to do specific tasks very effectively for years and years. But at the same time, user needs and behaviors, contexts of use, and surrounding technologies all change over time. So good systems engineering does at times require revisiting, updating, and maintenance.
That being said, Bokeh has catching up to do.
A. System’s capabilities are not robust#
Sometimes a system is built using the wrong materials or with the wrong substrate, which ultimately limits how robust that system is. In this case, Bokeh uses non-standard interactive elements, such as <div>s and also does not provide adequate descriptions and attributes on elements that enable assistive technologies. This limits which devices are capable of interaction and input, as well as which ways a user is able to perceive the contents of that system.
But more than using the correct materials, sometimes systems should also be encouraged to grow in order to handle new devices, interaction patterns, and uses. And in this sense, Bokeh does not handle zoom/reflow well, which is difficult especially for mobile users. Many users who have disabilities actually use mobile or tablet devices more than desktop devices. Some screen reader users, for example, love VoiceOver on iOS much more than a desktop experience.
Bokeh should be built in a way that enables a myriad of current technologies to interact with it. In particular, what makes Bokeh awesome are the interactive capabilities that it offers end users. But care should be taken to design how different users with different assistive technologies and input devices and interaction patterns will want to accomplish similar goals. Parity in the quality of experience should be provided for all users. Sighted, mouse users shouldn’t have an easier and better time than everyone else.
Evidence of this finding#
- Elements are visual only [PT-18, PI-28, A-24].
- Only one modality/input is provided [PT-13, PI-17, A-13].
- Semantically invalid [PT-14, PI-20, A-15].
- Fragile support [PI-10, A-7].
- Interactive context is not clear [PT-10, A-10].
- Complex actions have no alternatives [PT-2].
- Interactions are not forgivable [PT-9, A-9].
- State is not easy to share or reproduce [A-16].
- Location and history is not clear [PT-12, PI-14].
- Focus indicator not perceivable [PT-11, PI-13, A-11].
- Zoom and reflow are not supported [PT-20, PI-30, A-26].
- Scrolling experiences cannot be altered [PI-19].
Example#
Example taken from plotting interface [PI-30]. Below demonstrates how a high-zoom user will have a worse experience reading Bokeh's text than someone who uses Bokeh at 100% zoom. Because Bokeh renders with canvas, text becomes rasterized and does not scale well compared to HTML or SVG elements when zoomed.
Viewport is zoomed in to 400% showing the canvas-based text from the bar chart labels being highly aliased and fuzzy, compared to the text for the Scatter plot beneath (circled in red) which is high fidelity and readable (fails).#
B. System’s presentation is not flexible#
Many users, especially those with disabilities, customize their technology experiences. This is called “fitting” in some spaces, but generally is part of “personalization” and “customization.” In order for an end user to be able to make these changes to an interface, it must be built on a relatively flexible system. Rigid systems will try to enforce their own rules for styling, animation and more. But flexible systems are built with an assumption that end users may override things.
There is a massive array of different things that end users might want to be able to do and building a system that could allow them to do whatever they wanted might be impossible. However, there are a few things that should always work as-expected out of the box, which we check for: detecting and adapting to changes in system-set high contrast mode, if textures/patterns are on can they be turned off, whether animations can be disabled, zoom/reflow support, ability to adjust scrolling experiences, whether obscure chart types have alternatives for viewing the same data, and whether text can be manipulated using css.
Foundationally, many users leverage browser extensions that automatically try to update every webpage they visit to suit their preferred minimum font size, text spacing, color choices, and more. A library’s inability to respond to simple CSS-based changes can produce pretty harsh barriers for some end users (and also can look clunky too). Responding to an end-user’s personal CSS as-expected is easily the most important first thing we check. Then we test different devices and assistive tech (mobile devices, magnifiers). After that, we work through system settings (contrast, animations, textures, etc) and lastly we check certain visualization-specific things.
Ideally, all content on the web is flexible enough to handle these variations that facilitate an end-user’s “fit.”
Evidence of this finding#
- Complex actions have no alternatives [PT-2].
- Zoom and reflow are not supported [PI-30, A-26].
- Scrolling experiences cannot be altered [PI-19].
- User's style changes are not respected [PT-16, PI-24, A-19].
- Contrast and texture cannot be adjusted [PT-5, PI-5, A-4].
- User's text adjustments are not respected [PI-26, A-23].
Example#
Example taken from plotting interface [PI-5]. Below demonstrates how an inflexible visualization is incapable of correctly responding to an operating system's *High Contrast* mode.
A scatter plot is shown. A high contrast filter has been implemented, and the web browser background is black with white font. However, the chart space retains its default color scheme - the contrast change was not applied (fails).#
Suggested directions for remediation#
The following suggestions are primarily intended as high-level goals, spelled out as imperatives. The lower-level details for how to accomplish each of these should be sorted out in our actual roadmap and eventual issues on GitHub.
Ideally, the following are written as invitations for the Bokeh community to get involved. There’s a lot to do!
Focus on text experiences: explanations, descriptions, and labels#
Charts need to be described. A designer or developer should, at the very least, have a way to easily provide descriptions for their visualizations. This should be done before anything else. Bokeh needs to give them a way to add descriptions for screen reader users. (Note: this is not the same as a caption.)
Common practice in other libraries (see Highcharts, Visa Chart Components, Vega Lite, Olli, etc) is to automatically describe parts of the chart that can be automatically parsed, like the axes, legends, data ranges, data types, etc. This should be provided to users in alt text (at minimum) or at best via an alternative document. This is typically after the designer-provided descriptions.
The final part of descriptions is that many major visualization libraries also add navigable labels for rendered elements within the chart. This can be quite a lot of work to do well, especially if interactivity (and not just screen reader navigation) is part of the equation. I break this down a little bit more below.
In addition, all of the major text elements in a chart (title, subtitle, captions, annotations, etc) need to be exposed to screen reader users somehow. Rendering text in a raster format (like <canvas>) puts pressure on the system: either you completely recreate the major text elements in HTML (but hide them visually in a way that still allows screen reader access) or you may need to move text rendering off of canvas. Coordinating either of these can be a bit of work.
More care should also be taken for describing what various things and explaining how to use and interpret the things they do (for example, the interactive annotations and all of the plot tools). New users need cues to know what is interactive, especially like the subtle examples of the tooltips and selectable legend in our line chart. I would go so far as recommending adding end-user how-to guides. I highly suggest adding documentation that is focused on helping Bokeh’s end-users get the most out of their interactive experience, especially those who are new. By now, Bokeh’s community has likely established enough interaction patterns that could be written up.
Use better building materials#
The next most important thing, after locking in text-related accessibility, is to use the correct building materials.
As already hinted, <canvas> can have some limitations for accessibility. It’s great for high-performance rendering, but that performance is directly related to a lack of markup + DOM overhead that comes with more accessible materials, like HTML (or even SVG). This problem is pervasive, especially among charting libraries (Vega-lite, Highcharts, etc) with some accessibility capabilities in <svg> that are lost if users decide to render in <canvas> for the performance benefits. Even <svg> has some limitations, due to asymmetrical adoption of ARIA standards, which is why some libraries like Visa Chart Components renders an accessibility layer using pure HTML (which has high support and standardization) with <svg> under the hood. My project Data Navigator takes this idea of separating the visual rendering layer from the accessible rendering layer, but generalizes to virtually any frontend ecosystem (while also retaining high-performance). We’ve used it in open source work with Adobe, so it is something worth considering if Bokeh intends to continue rendering in <canvas>.
As for virtually everything that is interactive, from annotations, tooltip-triggering elements, to the buttons in the plot tools, natively semantic HTML elements will be far better for accessibility than the elements that they currently are. As an example: a <div> isn’t natively semantic at all, but a <button> is. Adding on-click event listeners to a div would make it listen to mouse events, but keyboard-driven assistive technologies can’t reach those elements natively, like they do with a button. The general philosophy here in accessibility communities online is that if a native element can do what you’re trying to do, you should use that element.
Sarah Higley writes about how “a major pitfall of approaching web design as a visual medium is conflating visual patterns with functional or interaction patterns.” Her point is that thinking in terms of a visual language can sometimes bias web developers and designers into trying to solve all interactive problems using visual means. HTML has a massive array of elements with functional semantics and they should be used whenever possible. Not only will assistive technologies have a better time, but so will automatic agents when parsing a website (like crawlers for search engines and foundational models).
Plus, it is easier for someone else to interpret code that uses semantic markup. This will certainly have a downstream effect on future community contributions and new projects.
Build a flexible system#
People personalize their technology. And people also use software with a variety of different devices in different contexts. A flexible, compromising system is necessary for that software to be usable for all people in all places.
There are some existing, relatively ubiquitous UI customizations that people commonly do that Bokeh needs to “watch” for. People commonly use “high contrast” modes, increase font size/weight/spacing, turn off motion/animations, turn on redundant encodings, and zoom/magnify. Media queries and other strategies in CSS (and even JavaScript) can be used to look out for these user-determinations. But also, an API should be implemented that allows someone to programmatically override the design of a visualization on their own (in cases when it might be hard to automatically determine what the user’s needs).
On a related note: In my latest project on what I call “softerware,” I actually explored what the future of accessibility customization could look like for data visualizations. But at large, the most accessible data visualization libraries (like Highcharts) only really implement a couple of automatically-adjusting characteristics. Bokeh’s community has the opportunity to really lead (or co-lead) the development and implementation of what user personalizations every data visualization library should be flexibly designed to adapt to.
Help developers succeed#
One of the lessons that I learned while at Visa, helping to build Visa Chart Components, was that our first users were developers. And if we wanted them to actually implement the cool things we put in place, we needed to have a strategy focused on making their lives as easy as possible.
So in order for this entire accessibility project to be successful, developers need smart defaults for anything that we believe we should handle out of the box (such as supplying automatic descriptions for certain parts of a chart, making charts navigable and interactive with assistive tech, minimum font sizes, strong contrast defaults, etc).
In addition to defaults, we also should consider which guardrails to put in place, such as validation errors when alt text (or other important characteristics) aren’t supplied. We could also consider limits on how many categories can be encoded before throwing warnings in the JavaScript console (that perhaps suggest other strategies like small multiples, aggregation, or other visualization types).
After defaults and guardrails, developers will eventually want special control and modularity with accessibility too. Simple, powerful utilities are huge in the right hands. Your power-users who really know what they are doing will thank you. Defaults and guardrails are for your developers who aren’t as familiar with accessibility. But you also want to maximize the productivity of the developers who do know what they’re doing. Give them more capabilities whenever possible. One good example of this that I recognized in past work was separating our color contrast checking algorithms into modular functions. It not only helps power-users but even folks who might not be interested in the rest of the Bokeh ecosystem. Sometimes if the utilities are good enough, folks will come to Bokeh just for that.
Lastly, for developers to succeed, they also need to develop a sense of language for accessibility. If you want people to think in terms of accessibility, first they need to gain a better understanding of what people who live with disabilities experience, prefer, and need. And then those developers need to develop the right language for thinking about, describing, and designing ideal experiences for their users. Language can be important for seeing and thinking about the world in a new way. And tools can help your practitioner-users develop a design vocabulary for how their decisions impact the experiences of users with disabilities.
To build a design vocabulary among our users, first we need strong examples and documentation. But also, the functions, utilities, and architecture of Bokeh should be designed in a way that helps developers understand the outcomes of their design decisions. There should be vocabulary correspondance between the concepts we want people to envision and how the API is actually used.
An example of a bad API is aria-label versus alt as properties on elements. As much as I love ARIA (the Accessible, Rich, Internet Applications) standards, they end up introducing a whole second layer of language into web development. If someone hears the term “aria label” they might have no idea how that impacts someone with a disability. What does this do? And to make it worse, it is a parallel term to “alt text.” Confusing! So if someone sees these two phrases (aria-label and alt), they might have no idea what they mean or when to use one over the other.
But as toolmakers, we can consolidate these concepts into a new design-focused term, like accessibility-description or screen-reader-description or equivalent. Bokeh can do translation work between what actually makes an interface accessible at a low level and the design vocabulary that is ideal for Bokeh’s practitioner-users.
We have the opportunity to teach an entire community of Python data scientists, analysts, and developers how to make visualizations more accessible. To do this, we need to focus on making it as easy as possible for them to learn-through-use. Developers need smart defaults, thoughtful guardrails, powerful utilities, and a focus on a disability-centered design vocabulary.
Get involved: Check out our Github and Bokeh’s to get started.