8.6: Accessibility, Interactivity, and Performance Considerations

Accessibility, Interactivity, and Performance Considerations

When creating visualizations (regardless of tool), it’s crucial to consider accessibility, the level of interactivity needed, and performance implications. These factors ensure that the visualizations are usable and effective for all intended audiences and use cases.

• Accessibility: This refers to making visual content usable by people with disabilities – for instance, those with color vision deficiencies (color blindness), low vision, or other impairments. A key aspect is color choices. Many tools now provide color palettes or styles that are colorblind-friendly. For example, Tableau includes built-in “color blind” palettes that avoid problematic red-green contrasts, and Matplotlib changed its default colormap to viridis (a blue-green-yellow palette) specifically because viridis is perceptually uniform and colorblind-friendly. Seaborn and Altair also emphasize sensible defaults (Seaborn has a colorblind palette option). As a creator, you should use these features – e.g., choose Tableau’s Tableau Colorblind 10 palette or Matplotlib’s plt.style.use('tableau-colorblind10'), which yields distinguishable lines for colorblind readers. Additionally, avoid relying solely on color to convey information. Good practices include using different marker shapes or line styles in addition to color (so that even if someone cannot distinguish the hues, they can tell series apart by dash patterns or point shapes). Most code libraries allow this (Matplotlib can use different line styles for each series, for instance). In Tableau or Power BI, you can use shape or size encodings alongside color for differentiation.

Another aspect is ensuring high contrast between text and background. This is more under the designer’s control: check that chart text (axis labels, titles) have sufficient contrast (generally dark text on light background or vice versa) – tools typically handle this well by default (black text on white charts), but custom color backgrounds or images can ruin contrast, so be mindful if customizing.

Screen reader compatibility is a challenge with data visualizations, especially interactive ones. A static chart in a report can be accompanied by a descriptive caption or alt text. In fact, adding descriptive text is a best practice: e.g., in an HTML context, an <img> of a chart should have an alt attribute describing the key message of the chart. Tableau, Power BI, and Looker Studio allow adding alt text to charts when publishing to web. For interactive canvas-based charts, support is still evolving – authors may need to provide data tables or summaries as an alternative view for screen reader users. Tableau has been working on improving dashboard accessibility, including keyboard navigation and screen reader support for simple charts, though complex dashboards can still be challenging.

Color blindness simulations and testing: It’s recommended to test your visuals through simulators or use tools that show how your chart looks to someone with protanopia or deuteranopia, etc. There are online simulators and some tools (Plotly’s Chart Studio, for instance) that have built-in accessibility checks. By catching problematic color combinations (like red/green adjacent segments), you can adjust before publishing. Also, providing redundant encoding – such as direct data labels on bars (so one doesn’t need to rely on interpreting the axis), or patterns/textures for filled areas – can help a broader audience.

In sum, accessible design is part tool capability and part user discipline. Fortunately, many tools now support accessible design choices: e.g., Power BI has an Accessibility Checker and allows adding tab order to visuals, etc., and Looker Studio being HTML-based can incorporate ARIA tags for screen readers in embedded contexts. It’s the responsibility of the analyst to leverage these and ensure their visualization can be interpreted by everyone. Ethical and often legal considerations (in government or education, accessibility compliance is required) mean we should not overlook this aspect.

Figure \(\PageIndex{1}\): Accessibility Best Practices for Data Visualization. An infographic summarizing key accessibility considerations including colorblind-safe palettes, redundant encoding, alt text, contrast, and screen reader compatibility. (CC BY 4.0; Felix Amoruwa) Access to a detailed description of Figure \(\PageIndex{1}\)

 

• Interactivity: We touched on interactivity in tool choice, but let’s consider what level of interactivity is appropriate. Interactivity can range from basic (tooltips on hover, ability to select or filter) to complex (dragging sliders to change parameters, click-and-drag to zoom specific areas, etc.). With great interactivity comes great responsibility – interactive visuals can confuse users if not designed carefully. A guiding principle is that interactivity should add value by allowing users to explore different facets of the data without losing the core message. For example, a dashboard might allow filtering to a specific region, but the overall comparison structure remains, so the user can answer a focused question like “How is Region A doing compared to others?” by selecting it. Overloading a visualization with too many interactive controls, however, can overwhelm the audience (often known as the “dashboard junkyard” problem).

From a technical standpoint, more interactivity can impact performance. Web-based interactive charts (like Plotly, which uses JavaScript in the browser) have to manage potentially lots of data points dynamically – which is why Plotly suggests keeping point counts relatively low for smooth interaction. Tools like Tableau and Power BI handle interactivity by querying data as needed – e.g., clicking a filter might send a query to the data source to update the view – which might introduce delays if the query is heavy. Thus, a highly interactive dashboard might need pre-aggregated data or careful optimization to remain responsive.

Another consideration is cross-platform interactivity. If you publish an interactive visualization (say a Plotly chart) on a website, ensure it works on mobile devices as well (Plotly and others usually do, but complex dashboards might not be mobile-optimized unless explicitly designed). Tableau and Power BI offer responsive layouts or specific phone layouts for dashboards – an important step because interactivity on a small touchscreen is very different than on a widescreen monitor.

When to prefer static vs. interactive: If your audience just needs a quick insight and is not expected to slice and dice data themselves, a clear static visualization (in a PDF or slide) may be more effective and less prone to misinterpretation. For instance, if delivering a printed report to a client, interactive is not even an option – static, well-annotated charts are needed. If your audience is exploratory (like a data-savvy manager who wants to answer new questions on the fly), an interactive dashboard is invaluable – they can self-serve some analysis by clicking around. There’s also a middle ground: providing both. For example, a static summary plus a link to an interactive version for those who want to delve deeper.

Figure \(\PageIndex{2}\): Static vs. Interactive Visualization Decision Spectrum. A conceptual illustration showing the trade-offs between static and interactive visualizations, mapping audience type, delivery medium, and complexity along a continuum. (CC BY 4.0; Felix Amoruwa) Access to a detailed description of Figure \(\PageIndex{2}\)

• Performance: Creating visualizations with large data volumes or in resource-constrained environments requires performance tuning. A few tips aligned with tool capabilities:
• Aggregate or sample data for visualization: Rarely should you plot every raw data point if there are extremely many. The human eye can’t discern millions of points on a screen (it will just look like clutter or solid color). Aggregation (grouping data into categories or bins) or sampling (taking a representative subset) can convey patterns more clearly and lighten the load. Some libraries and tools help with this (e.g., Bokeh has datashader integration for big data visualization, and Plotly has the plotly-resampler add-on for automatic downsampling. In Tableau/Power BI, using aggregated queries or extracts (which maybe pre-aggregate) improves performance.
• Optimize data format: For code libraries, using efficient data structures (NumPy arrays instead of Python lists for Matplotlib, or cuDF for GPU acceleration in some cases) can speed up plotting. In Tableau, the use of extracts (columns compressed and indexed) often yields faster interaction than a live connection to a slow database.
• Asynchronous loading: In web contexts, you might want charts to load asynchronously so one slow chart doesn’t stall the whole page. Many JS libraries allow rendering a placeholder then filling in the chart when data arrives. In Power BI and Tableau server, dashboards load incrementally chart by chart, which is good. For custom web apps, consider splitting heavy charts into separate routes or using caching.
• Hardware acceleration: Some tools can leverage GPUs or vectorized operations. For example, WebGL in Plotly can accelerate scatter plot rendering for a larger number of points (Plotly will automatically use WebGL for scatter plots over a certain size). Tableau can push computations to a database (taking advantage of DB optimizations), and Power BI’s Vertipaq engine is highly optimized in-memory. If using Matplotlib for very large images (like 10k x 10k pixel high-resolution figures), rendering can be slow; sometimes switching to a lower-level library or compiled extension might be needed (or simply wait longer and be mindful of not doing that repeatedly).
• Mobile and browser compatibility: On low-power devices, interactive visualizations might lag. Testing on various devices and perhaps providing a simplified view for mobile (e.g., fewer data points or simpler charts) is wise. Many BI tools automatically allow a mobile layout with maybe fewer charts or differently arranged charts to avoid overload.

In summary, the key is to tailor the visualization’s complexity to the user’s needs and the environment’s capability. Always ask: Will making this interactive or including more data improve understanding, and can it be done without harming the user experience? If not, simplify. There is a well-known saying that “Every interaction is an opportunity for the user to get lost” – so provide clear cues (like titles that update to indicate filter context, consistent use of color, etc.) to guide them. Meanwhile, ensure performance by not attempting to brute-force show everything; good visualization often involves highlighting the relevant data, not dumping all data.