The Sliding Info Box

The main component we tackled during the code convening was a sliding info box—a tooltip alternative inspired by Google Maps’ sliding panel element.

This design pattern offers a few significant improvements compared to a standard tooltip—particularly for keyboard accessibility and mobile. By providing a fixed area to display selected information, the user always knows where to look, and it helps to prevent the user’s fingers from getting in the way of the selected information. The fixed area also negates the need for hover events, which traditionally work poorly on mobile devices and are inaccessible via keyboard.

Plus, the sliding section provides a slick way to display additional details related to the selection. When the user selects a section on the map, the info box initially displays only the highest-level piece of data (in this example, the county name). If the user interacts with the head of the info box, it slides up to reveal additional information about the county. There are a couple good things about this. By not immediately displaying all the data related to a selection, you avoid overwhelming the user, and you also provide context for the interface because the map is still in view. It allows the user to choose to see additional info without forcing it upon them. This is great for assistive technologies (AT), too, because the AT won’t immediately start reading off every bit of data associated with a selection—but it can still access the data if the user requests it via the “return” key. Additionally, the sliding animation provides some visual continuity within the interface, so the user maintains a sense of how the element came to take up the screen and how to navigate the associated information.

How We Did It

We had two main goals for our sliding info box: The element should be responsive and work well on touch devices. All the data in the visualization should be accessible via keyboard and screen reader.

To ensure the info box was responsive, we used media queries and percentage-based widths to define the structural elements in the CSS. We also added some touch-specific features, which we managed by testing for mobile user agent strings and adding a corresponding “touch-device” class to the containing element. This way we could target specific types of devices for specific event listeners in the JavaScript.

/* Add touch class to container for mobile */
var touch;
if (/Android|webOS|iPhone|iPad|iPod|BlackBerry/ i.test(navigator.userAgent)) {
 touch = true;
 var wrapper = document.getElementById('interactive-wrapper');
 wrapper.className += ' touch-device';
}

To account for keyboard accessibility, we ensured each county in the SVG map had a tabindex assigned to it, which allows the user to select the county by tabbing through the interface.

/* Add tabindexes to paths so the keyboard can access them */
$('.cir-county').attr('tabindex', 0);

After that, we added event listeners for focus, blur, and keydown events in order to have more control over the keyboard selections and the data they exposed.

/* Display the top-level information for the selection on focus */
$('.cir-county').focus(function(){
  deselectPath(); 
  var $this = $(this);
  var county = $this.attr('data-name') + ' County';
  $this.attr('title', county);
  displayName(this);
  lastFocused = this;
});

/* Expand (slide up) the panel with the 'enter' key on a selected path */
$('.cir-county').keydown(function(e){ 
 var code = e.which;
 // 13 = Return
 if (code === 13) {
   var panel = $('.panel-hed');
   expandPanel(panel);
  }
});

/* Remove focus from the expanded panel to return focus to the previous path selection */
$('.panel-expanded').blur();

The resulting interactive is deceptively simple, but it’s a step in the right direction to meeting the accessibility benchmarks we set out to achieve. We hope to improve it further by adding gesture detection for “swipe up” and “swipe down” events on touch devices, and by removing the jQuery dependency and giving it a more on-brand look. The current implementation of the sliding info box is pretty heavily entwined with the specific map we were using to build it, so we definitely need to abstract the functionality to make it more repeatable. There are still plenty of improvements to make!

I should note that keyboard focus for SVG elements is currently supported in Webkit and Chrome, but the feature is an open issue with Firefox.

The Next Steps

The full “Data Viz for All” documentation is a living document and a work in progress—so if anyone has ideas to contribute, please do so! Many of us are tackling the same problems (especially on the mobile-friendly side) and this documentation can serve as a hub to gather all of our collective R&D in one place. With everyone’s input, we can help our news applications better serve a more inclusive audience.