Navigated to episode Data Verbalization.

Data Verbalization

by Doug Schepers

recorded on September 04, 2019

Transcript

[Intro Music] >> MICHAEL BECK: Welcome to technica11y! The webinar series dedicated to the technical challenges of making the web accessible. This month, our presenter is SVG and data visualization expert Doug Schepers.

>> MICHAEL BECK: Hello, everyone, and welcome to this September edition of technica11y. I'm Michael Beck, your host and moderator, and this month we have Doug Schepers with us, SVG expert and CEO of Fizz Studio.

>> DOUG SCHEPERS: Pretty much everything at Fizz Studio. (Chuckles).

>> MICHAEL BECK: Everything at Fizz Studio. So yeah, he'll be discussing data verbalization today, making images and data visualizations accessible to everyone, which is something we haven't touched on quite that deep yet, so Doug, is going to take his deep dive today and over to you, Doug!

>> DOUG SCHEPERS: Great. Thanks, Michael!

Okay. So, I want to start off with a little intro. Who am I? My name is Doug Schepers, obviously and I've been coding SVG and JavaScript since around 2000. I was doing other kind of programming before that, so I've been a programmer for a while. I worked at W3C for ten years and I was on the SVG working group WebApps. I started the Web Audio Working Group if you know what that is. I'm not technically an accessibility expert by training. I have the same sort of imposter syndrome that many of you probably feel when dealing with accessibility.

I am sort of a niche accessibility expert. I'm an expert in accessible data visualization. So, that's a very tiny niche within a niche. I'm also the founder of Fizz Studio. We're an accessible dataviz startup and I recently started a job at UNC, University of North Carolina at Chapel Hill, as a digital accessibility consultant. That's sort of my side gig. So, thank you for having me here!

Let's jump into accessible data visualization!

So, the first thing I want to talk about is colors. You may have heard of "web safe" or "colorblind safe" color palettes. There's one that I'm particularly fond of and that is the Brewer Palette. This is done by someone named, oh, I can't remember her name, but it is not Judy Brewer, if you know the W3C WCAG person. But, it is Dr. Brewer from, I think, Pennsylvania, and she came up with this set of colors for maps. And there's three ways to think about these colors.

There's discrete colors. Discrete colors are for categories. They are for individual items that are distinct from one another.

Then, there's sequential. You would use this, for example, when you are trying to show that some things are related in some way, that there's a series of things.

And, then, you have diverging. Diverging is sort of something where it's going from one category to another category.

And, so, discrete means it's quantitative. There's no perceived order. Sequential means that these are perceived order, uniform steps.

And diverging means that these are two sequential colors.

Why am I talking about these kinds of things? One, the Brewer Palette has a lot of really great colorblind safe accessible options. And the second reason I'm talking about when you use these kinds of colors is because accessibility is not just about accessibility for blind people. It's also accessibility for everyone, of course, but specifically people with cognitive disabilities. For example, by setting things up in a way that makes sense to people, that feels natural to people, you are setting yourself up for thinking about how to approach data visualization in the right way. In other words, how do you think about how people think about what you're showing on the screen?

So, the rest of this talk is going to be about colors and which colors to use...no. Colors are an important part of data visualization but they are not the most important part, nor, in fact, do I think it's the most interesting thing to talk about in data visualization. When you look at most products, unfortunately, when they say that their data visualizations are accessible, what they mean is you can choose colors that are good for people with colorblindness. Not to dismiss people with colorblindness, but, there are a lot of other issues that you need to think about when dealing with accessibility. So this is pretty much one of the few times I'll be talking about color in this talk.

I want to talk a little bit about complexity. So, this is a beautiful example of data visualization.

It happens to be about the Internet. This is a map of the Internet. But,and I look at it, and it's beautiful, but I really can't extract any information from it. I can appreciate the aesthetics of it, but, I cannot really understand what's going on here. So, you might have complexity like this. You might have a lot of complexity in your data.

This is another example of complexity. We have what is, frankly, not a very attractive, beautiful image to look at. And I also can't get much out of this.

I'm not saying that people can't learn to read graphs like this. They can. But, I am saying that for most people most of the time, whether you're trying to explore data or whether you're trying to explain data, you don't want to introduce this kind of complexity in your charts because you are excluding the vast majority of people from being able to understand what they are looking at.

So, my big takeaway here is complexity is the enemy of clarity in terms of data visualization.

The big thing that you need to take away is think about your data visualizations as a poem, not as a novel. Make the most discrete, the smallest possible thing you can make in order to convey the idea that you are trying to convey.

That is going to serve everyone. It also happens that it will serve, for example, people who use a screen reader.

The first thing you need to think about when you're thinking about making a data visualization accessible is what is the absolute minimum I need to convey to this person so that I don't waste their time and waste their mental energy, waste their cognitive load. So, you really need to think about when you are making a data visualization accessible, what's the first thing, what's the most salient thing, that you can take away from that?

And, in general, that is, give them before you do anything else, give them sort of `alt` text, give them an introduction that is, for example, "North Carolina was the top state in this or that figure," or, "This is a stock market chart, the trend is upward from this value from you know 50,000 to 100,000," whatever it is.

Give them a one-sentence takeaway that they can approach to understand it from a cognitive perspective, from a screen reader perspective, and from there, they can decide if they want to drill down into the table of data or however else you're presenting that data.

So, that's the big takeaway there: reduce complexity whenever you can.

So, here is an example of an accessible chart. How is it accessible? Well, for one, it's done in SVG, which is Scalable Vector Graphics, in case you don't know SVG. You see it used a lot for things like icons or very simple images and you do see it used a lot in data visualization.

I don't think that people really understand that SVG is like HTML in that you can completely control the document format, you can completely control aspects of the document to make it navigable in the same way that an HTML document is navigable. What do I mean by that? Well, for one thing, we could say, BOOM, right off the top, "There's an accessible SVG chart." Now, we don't need to tell them how many elements there are in it, but you tell them immediately when a screen reader hits this SVG, it says, "Accessible SVG chart." Then it points out there's a x-axis; we are setting context. It says, "Here is the x-axis, the kinds of things we will be talking about, this is the independent axis."

Then we have the y-axis. I'm going in order, starting at the top I'm saying, "This is a bar chart. This is the x-axis," then I'm saying, "the y-axis," and then, I let them walk through the individual data points: Saturday, 8 hours; Sunday, 6 hours; Monday, 4 hours; Tuesday, 12 hours. By using SVG, I'm actually able to let them drill into and tab through and get at all of the data in the same way they would be able to get at it through a table.

I want to talk about how do we exactly do we achieve this.

Partly, it is just through using tabindex, things like that. But, partly, we have these new standards coming out about ARIA. So, ARIA is about categorizing different kinds of controls. At Benetech, there's an Accessible Data Visualization Task Force. That's not actually part of ARIA, but there is a Task Force working on helping to inform the next generation of ARIA standards. There are some new ARIA roles within SVG: the Graphics Accessibility API Mappings in the ARIA graphics module. They have things like `graphics-document`, `graphics-object`, `graphics-symbol` and you can use these in your SVGs in order to make the screen reader understand what exactly the person is supposed to be looking at.

I want to talk a little bit about screen readers; not about screen readers themselves, but, about how the information gets from the browser into the screen reader. So you start off with a document, say, an HTML document. If you know about the DOM, the DOM is the Document Object Model. That's what the browser sees in a document. And then it presents that directly to the user. And that's a pretty straight-forward transformation. Document gets turned into a DOM, Document Object Model. And that's presented into the browser. It's a little bit more circuitous to use for a screen reader. For them, the DOM is converted into an Accessibility Tree; this is a subset of everything else that's in the document.

So, going back to this image here, there's a lot of things that we don't talk about in this image. I don't talk about the individual lines at the back that show sort of the tick mark lines that help a user visually track going from "8" over across the screen. We don't mention those in ARIA because they aren't useful to a screen reader. There's a lot of elements here that we simply don't have to mention. We don't have to mention that there's sort of a 3-D effect in this bar chart because that's not information that's adding to what the screen reader sees.

So, going back over here. We've got the document. We've got the DOM. And the Accessibility Tree is subset of the DOM that's presented to the screen reader. After it goes into the accessibility tree, it goes into the operating system's accessibility API, and then it goes to the screen reader, and, through the screen reader, it's presented to the user.

So once you understand the flow of how the information gets there and understand how you can filter out pieces of information that are extraneous to the screen reader user, it's a little bit -- an analogy might be when you have an image that's meaningful, you use `alt` text. When you have an image that's not, meaning it's just decorative, you can just say `alt=""`. It's sort of like that. You highlight the things that need to be highlighted and you sort of hide away the things that are already extraneous.

Let's step back and look at what is data visualization in the first place.

So, this is a fancy word for -- or I say data visualization, I also say dataviz a lot -- it's jargon, a fancy word for charts and graphs and diagrams and maps. And a common metaphor in dataviz circles is, "Data visualizations are a story about data." I don't dispute that; it's certainly true. It's a story you're telling people about the data you're looking at, but I have a more functional metaphor and that's, "Data visualizations are a user interface for data."

And my goal in this talk is to get you to rethink what a data visualization is.

So, many people say that data visualizations -- and I've heard this for years --that data visualizations aren't accessible and can't be accessible but in fact data visualization is accessibility technology.

I've popped up on the screen here a spreadsheet, an image of a spreadsheet, that shows the raw numbers for population for the four biggest countries in the world, Brazil, China, India, and the United States, or the most populous countries, rather. And I show that the years from 2000 to 2016. So, at this point, if any of you are able to see this image, I could ask you a question: "Which country of Brazil, China, India, and the United States, which of them has the highest rate, not the highest number of population, the highest rate of growth in population?"

And I could sit here and solicit answers and the fact is most of you would not be able to tell me right away. But, if I show you a line chart that shows the rates of population, you can see that China has the highest population. But, you can also see that India has a higher rate of growth because the angle of the line is steeper. And it's very interesting: when I showed this presentation to a person with low vision, they couldn't make heads or tails out of the table of data. But when I showed the line chart, they were able to immediately tell me that India had the fastest rate of growth. Now this was a mathematical person who knows how to read charts well.

But, the point is, instantaneously, you were able to take the data that, from a table view, is not very accessible and in a dataviz role, in a line chart, is actually much more accessible. It's much easier to notice and think about patterns certain kinds of cognitive disabilities and low vision. And it helps really reduce effort and it helps you to catch attention in a data-flooded world. What it's doing is it's creating a functional model of the data in the minds of the audience and there's nothing inherently visual about that.

So, Ben Shneiderman is a pioneer in what was called HCI at the time; we would probably now call it UX. Human-computer Interaction has sort of become User Experience and he's also a dataviz pioneer.

And he said, "The purpose of visualization is insight, not pictures."

That's really where we're going here: the purpose of visualization is not pictures.

So, the immediate question might be, "Why is it visual then, why do we do things visually?" Well, because the visual channel is very broad. It's very fast: ten million bits per second. Thirty to sixty percent of the brain is dedicated to visual processing. This corresponds to our fight or flight reflex. If you see something moving quickly towards you, you immediately have a reaction. It's the difference of between, "Seeing dinner or being dinner," is the expression.

In comparison touch and hearing have a much lower bandwidth than visual information does.

Vision is also multichannel. I won't go into all of the details here, but there's something called saccade where your eye is moving around; you're constantly pulling in multiple pieces of information and correlating them in your mind. This helps us detect, match, and make sense of patterns and we use these capabilities, these visual capabilities, to convey things in a way that's faster than we could do through serial access. So. it's parallel processing with vision and serial access when we're, for example, listening to numbers in a table.

There's also something called the Pictorial Superiority Effect.

And again, the breakdown of the senses : I've got a little pie chart made out of a brain with allocations of the senses. The allocations are not exact because we don't really know how exactly the brain processes different sensory information, but, generally, between a half and three-quarters of the brain of our cognitive capacity is dedicated to visual processing.

The Pictorial Superiority Effect affects memory retention. So, if I showed you this whole slide deck with just text, no images, you would retain about ten percent of that information after three days. However, if I add images that sort of help you frame the ideas in your mind, you will retain after, three days, sixty percent, or sixty-five percent, actually, of that information.

So the curious thing is this effect increases with age. You think little kids: "Oh, little kids are very visual. They see pictures and things." Actually, once we reach a certain threshold, the older we get, I'm a 50-year-old, visuals become more and more important to me and more and more effective on me. And this increases with age. If you're interested in reading more about that there's a book called, "Brain Rules" by John Medina, that talks about that a little bit more.

So, I mentioned cognitive load earlier. What is cognitive load? Actually cognitive load can be broken down into a few different categories. There are different types of cognitive load. Intrinsic cognitive load is the bare minimum you need in order to understand an idea. And then there's a bunch of extraneous cognitive load. These are all the things surrounding the idea that are actually distractions from you understanding the core idea. This extraneous cognitive load, it's basically clutter. And there is some redundancy, though. Redundancy is actually helpful. Saying things twice in different ways, or multiple times in different ways, can actually reinforce the main point so redundancy actually has a function.

When you combine the intrinsic and the necessary parts of the extraneous clutter, we get what's called Germane Cognitive Load. This is stuff that people feel is relevant. It sets context. It helps people establish what they are trying to understand. Germane cognitive load is the brain looking for patterns within the clutter to develop context.

Serial tasks, that is, say, tasks where you're doing one thing at a time as opposed to doing multiple things at the same time, cost more cognitive load than parallel tasks. And this is why, for cognitive accessibility, visualizations are actually often very effective. It does introduce some challenges, though, and we're going to explore that.

I'm going to be talking a little bit more about the brain and how it works, so, I hope you'll bear with me, because I think it's germane to you understanding how to think about accessible data visualizations. There's something called the Preattentive Attributes. The Preattentive Attributes, these are features that are processed automatically by our visual memory or iconic memory. These include color, form, position, and movement. And I'll show you some examples of each of these.

Color: it's pretty obvious. There's things called hue, saturation and lightness; HSL for the designers among you. And each of these sets one color apart from other things in the same set.

Another feature is called Texture. When we see something has a different texture than other things, our eye immediately jumps on that.

Then there's things that comprise form, like orientation, alignment, co-linearity, length, shape, size, curvature, width, added marks, intersections, spatial grouping or numerosity, that being our inherent ability to see roughly how many of a thing there are that usually tops off around four or five, is when numerosity starts dropping off but up until that point, BOOM! Our brain is actually counting those things immediately.

So, then under Position we have things like 2-D position, stereoscopic depth, concavity, or convexity, and under Movement we have size change, direction and velocity, rotation, and flickering. I'll take these animations off because the movement ones are so distracting to me as somebody with ADHD, I can't have them on the screen when I'm trying to concentrate and do a presentation, and I think it would also distract some of you.

So several of these Preattentive Attributes, these automatic attributes, are ideal for quantitative mapping and others are good for qualitative mapping. In other words, some of them are really great for showing numbers and others are great for showing categories. The ones that are great for numerical or quantitative mapping are length and you can see three little lines and one is taller than the other. Immediately, you realize, "Oh! That's how we use a bar chart." The 2D position (this is like a scatter plot) and size.

These are the three that are really great for quantitative mapping and the rest of these you should consider as things for showing categories.

To go along with these Preattentive Attributes, there's something called the Gestalt principles. And this is one level up. It's a higher level pattern recognition that organizes all of those different little things that our eyes and brains immediately grab and it organizes these discrete elements into a unified whole. So, some of these are Proximity: when things are close to one another , you assume that they are a group and I have three examples. Two examples where you see Proximity, you see things as a group and then another one where there's no clear grouping. That things are a little more scattered.

Then there's something called Enclosure : when we see things that are wrapped in another element, wrapped in another thing, we tend to think they are somehow groups.

Connection: if there's a line drawn between things, we think that somehow those things are connected. Our brains immediately think that.

Similarity: if I have here some red boxes and some blue boxes, they are not clustered together, but you think, "The blue ones are similar to one another and red ones are similar, they are distinct from one another." Maybe so, maybe not, but our brains definitely see those connections. As I'm showing you these, I invite you to try to look at these things and think that these items I'm showing you are in fact not connected to one another and it's actually difficult for you to do. It's difficult for me to do!

Closure: this is an interesting one. I'm showing you a series of lines that seems to show the outline of a box. There are several breaks in it, but, our brains fill it in and it looks to us like a rectangle. It's not a rectangle, it's a series of three different angled lines, but they look like a rectangle.

And Continuity. Continuity is interesting. I have two bars here. One bar in front of the other. A dark blue bar and a light blue bar in front of it, but when I mouse over it, I can show you that in fact it's not two bars. In fact, it's three bars. It's just that because one of the bars is crossing over, it makes the one look in the back look like it is a continuous bar and even when you see that it's an illusion, when I dispel the illusion, you still see it when I go back to it.

And then, finally, there's Common Fate. Common fate is one things seem to be moving together, you assume that they are somehow connected.

These are processed after your sense memory but they are still preconscious and they are processed in parallel with one another. Like Preattentive Attributes, there's little to no increase in the cognitive load.

This is a really key concept here: the Fast and Slow Mind. The Fast Mind is called System 1. It's fast, it's automatic, it's frequent, it's emotional, stereotypic, it's unconscious. This is where immediate reactions -- this is where racism comes from. This is where very positive -- our reactions to attractive people come from. These are immediate reactions that we don't have much control over. Preattentive Attributes and Gestalt principles fall under this.

Then there's the System 2, the slow, effortful, infrequent, logical, calculating, conscious part of the mind. This is when we're looking at dataviz, the first thing that happens is we've got this preattentive automatic assumption about relationships. But then after that, we can start thinking about meaning. So, with dataviz the first thing we do is convey the properties of the data. And the second thing we do, that takes more effort, is we explore and we think about that data. But, when we only give somebody serial access to something, in other words we substitute a table for a data visualization, what are we doing? We are taking that serial access and we're forcing them to use it for both conveying the properties of the data and to explore and think about the data. We're increasing their cognitive load. So it's cognitively expensive, it's mentally taxing and it slows task performance.

We really want to try to avoid that in our data visualizations. This is why I keep saying, "Give them the gist." Give them the ability to quickly assess how deeply they want to dig into something. This also applies to a table of data. Provide a summary for the table of data that gives the key takeaway. This is going to help everybody. So what we need to do is we need to reduce the speed and effort needed to accomplish tasks in a non-visual way. In other words, when we're making a data visualization, we also need to think about how it's handled otherwise. So, in other words, in a non-visual way.

We have different kinds of sensory memory. And when we see a data visualization, it goes into our -- sort of our visual -- our sensory memory. Then it goes into our working memory, then our short-term memory, and then to our long-term memory. And at every point, some information is being filtered out. The benefits of a data visualization, that it effectively acts as part of our brain, it acts as an external memory register. We can immediately access that information very quickly going back and forth between what our brain is able to hold in at any one time and what we can see. And so what we really want to try to do is we want to try to emulate that kind of fast control with non-visual means, as well.

There's something called Affordance. Affordance is how you expose information or expose some functionality and also immediately show how to use that thing. So, "Affordance and Equivalence," is not just a long-lost Jane Austen novel; this is an idea where we need to take each feature of the chart that includes an affordance and a set of tasks that that affordance is geared towards and we need to make an equivalent experience for someone who has a different way of accessing that information.

One way we can think about doing this is to consider a data visualization as a document. So we have a title. We have where it came from. We have an introduction. We have a body. The introduction in the case of a bar chart, for example, are: the axes, the x-axis, the y-axis, I showed this before; we have the body, which is sort of the data itself; and then the conclusion. And the conclusion in a document is a paragraph. But the conclusion in data visualization is the actual insight that the reader has gained and the decisions that they have been able to make based on that data.

You want to think about document order when you're making a data visualization. You want to think about what order the person is navigating in order to get to different parts of your document using, for example, `tabindex`.

This idea of adding information into your data visualizations, not just thinking about them visually, is something I call, "deep graphics," and deep graphics is basically when the graphic has more metadata to it that adds context and adds for example links to data sources and other things.

I think the final thing I want to talk about around this compositional view of data visualization is exposing each landmark in a sequence to provide context. So here we have the title of a document, of a data visualization. In this case it's "Snowfall by Decade in Columbia, Missouri from 1971 to 2010." And then we have the x-axis which is the range of years. So 1971 to 1980, '81 to '90, '91 to 2000, 2000 to 2010. Then, snowfall in inches on the y-axis. So, we're setting context at each point. And then we're showing the data. So we have three bars. You can see that these bars are decreasing. And the key here is we mark all of those up in a way that a screen reader can actually understand. We have labels on them. And we provide access to each individual data item, the values. But, then we also say things like, "We can pull out the high. We can pull out the low. We can pull out the range. Give them the total.

Tell them maybe the mean."

Here is a real key point, the trend line. You can tell them (I told you as I was showing you the individual bars), "These go down, this is a downward trend." And telling them right off the top of the bat saves them from having to try to deduct that themselves. So by preprocessing what your point is, by presenting your point at the beginning, you actually set them up to understand how they can drill through the data and derive what they need.

Finally I'm just going to say that my functional metaphor, I hope I've shown you what I mean by this: data visualizations are an interface for data. Different types of data visualizations are optimized for different tasks like comparison to whole comparison to other data points, trends over time, breakdowns of categories, connections between items, navigation of focus and I just want you to understand that when you think about data visualization you should be thinking about all of these things.

So, the mission I have at Fizz Studio is to make implicit interactions into explicit actions that will give the power to question and to answer to everybody.

So, there are a number of libraries and tools that you can use to make data visualizations accessible. You're going to be using a tool to make your data visualizations. You're probably not going to draw them by hand. Just make sure to choose a library that actually supplies the data in a way that's actually accessible.

And a final thing I want to mention: there are various levels of data visualization accessibility. The first level is just generic `alt` text. Well, actually, the first level is not having any kind of accessibility at all. So that's base level; let's go beyond that.

You can provide generic `alt` text. The next level up, provide detailed summary in `alt` text. So, show market trends, the highest value, et cetera.

Then, the next step up, provide hidden content that is a table with the same information. And the next step up from that is actually to embed that information directly in the chart so that it travels with the chart and they are in the same context. And the last bit is basically: think about it from a task-oriented perspective where you're giving them context for each choice that they are being meant to make.

And I think I'm going to end it there. If you want to get in touch, we have our alpha release of our software that is accessible. And I think I'm going to stop there in order to make space for some questions.

>> MICHAEL BECK: All right, you actually answered someone right before you went into the `alt` text, David Annen had asked, "How should a caption look like on a typical dataviz?" and right on cue, you went into discussing the data accessibility specifics. So, if you want to go into that more, that would be great.

>> DOUG SCHEPERS: Sure. The unacceptable level is not telling them that there's a database on the page at all. Right? Using `alt=""`.

The next level up is telling them that there is a bar chart. But telling somebody that there's a bar chart on the page is sort of like telling somebody a joke and not telling them the punchline. Most pages that have a chart on them, many of them, that's the main thing.

The main point of that page is to convey that information. And if you made it inaccessible, just tell them, "There's a chart here," you're basically providing them nothing. So don't do that.

What you should do is, for example, say things in the `alt` text like, "Line chart showing market trends with a downward trend over the last year," or, "Bar chart of costs with 12 bars. The highest value is 1500."

Then, you might actually have a chart where you cannot make an accessible version of that chart. Somebody else gave you this jpg or PNG or whatever of a chart and your task is to make that clear to somebody. Well that's how you do it. You do it through `alt` text.

However, if you are able to get access to the data, you can do other things like provide a table to them with the same information. But this doesn't mean that you shouldn't have the `alt` text. This doesn't mean that you shouldn't have the summary. You should. But if I'm looking at a chart and the highest value is 1500 and it's for North Carolina. That's great that North Carolina is the highest value, but, I might want to find out, because I'm from Missouri originally, I might want to find out what the number is for Missouri. So, if they have that information available to a sighted user, you should provide that information to a screen reader, as well. In other words, one way you can do that is by having say a hidden table. A better way because tables and dataviz can often get out of sync especially when one thing is hidden, I think we all know that problem of the accessibility ghetto where there's one page over on the side or some piece of information that's hidden that's only updated infrequently, it's really much better to have the data embedded into the image itself, into the SVG for example itself.

So, let them drill into that. And what my software does is it let's them really drill into relationships and things like that. But, at the bare minimum, I would say give them very good `alt` text. Then that really says what is the point of this chart, not just, "This is a bar chart."

And then go up in exposing more data to them as you can. Does that make sense?

>> MICHAEL BECK: Yeah, that makes complete sense. I hope that little deeper dive was good for David. We have an anonymous attendee that says, "When you use SVG how do you make them accessible?" and I believe you answered that. That's just part of creating an SVG itself, you can do that.

>> DOUG SCHEPERS: Yeah, so each pie slice in a pie, each individual pie slice, is its own element just like each individual paragraph in an essay is its own `<p>` tag. So each of those individual pie slices is a path and you can add the metadata in there using a `title` element in SVG. You can also use ARIA, `ARIA labeledby` for the same purpose. And you can basically add the text version of that directly into the chart. You can say, "Pie slice 1; value 30," in the title. "Thirty. The next one is 25." Whatever. So, you can add the data directly in there. And just make sure you have it in the correct order so that as they are tabbing through, they are seeing it in the same order that everyone else is seeing.

>> MICHAEL BECK: Okay. Any thoughts or considerations on animated or time-based data visualizations?

>> DOUG SCHEPERS: Oh, that's something I've thought actually a lot about. One of the things -- immediately -- I try to think of things in terms of the challenges and opportunities. The challenge for animation is that you might be excluding some people from understanding some things. The opportunity is that animation is actually a really effective way of drawing somebody's attention to a particular piece. So, with animation, what I try to do is I use animation in order to draw someone's focus to a particular thing. But if I'm drawing someone's attention to one bar, for example, well obviously things like flashing, flickering, et cetera, you need to be mindful of frame rates, animation should be slow and discrete. They should not be constant. They should be time limited because if they are constant, it's going to be distracting to someone. If they are very frequent, if they are very fast, you risk giving somebody seizures; that's not a good risk to take. But if you use a pleasant, I'll say, animation, when you're doing that pleasant animation, maybe use `ARIA-live` to say, "I'm drawing your attention to this thing." So, don't just use one medium. Don't just use animation. Also say `ARIA-live` and then draw, maybe say, highlighting, "New York 3.5 billion" or whatever it is. Does that make sense?

>> MICHAEL BECK: Uh-huh. It definitely makes sense to me. Let's see, what else do we have? How would you approach data visualization of say a geographical map?

>> DOUG SCHEPERS: Oh, right, that's actually something I've thought a lot about. Maps are interesting because we think of a map as sort of a single thing but, in fact, there are lots of different kinds of maps and this gets back to my point about it being a UI for data. What is the function that you're trying to use this map for? Is this a navigation map where you're trying to help somebody navigate a particular path? Is it something that's trying to show the relationship between different items? Or is it something like a choropleth?

A choropleth literally means "many places." It's a terrible name for a data visualization that was coined in the 19th Century. But we are familiar with these things. I mean, the "red-blue" map or "red-blue-purple" map that you might see in election results. I call them theme maps or color maps. So the function of one of those is not about navigation it's not about showing necessarily the relationship, the physical distance between one area or another. In fact it's just a list of individual items that are categorized in a certain way. You know, did they vote mostly Democratic or did they vote mostly Republican or were the votes very mixed? In that case, you can actually effectively have a map in which each of those different items is available. A person can tab through or they can jump to an individual state, for example, and find out the answer for that. Effectively, just think of it as a list that also has a visual component.

So, again, with the list, it's a long list of things and doesn't give the overall context so what I would do is I would provide a summary in text that says, "The number of states that voted blue, the number of states that voted red, the number of states that voted purple." You don't usually see the purple, but I try to point it out, but you get the point. Tell them multiple ways. That's that redundancy I talked about, give them multiple ways to consume the information, either discrete elements or as an overall summary.

>> MICHAEL BECK: Okay. You answered Isabella's question perfectly. She found it really helpful.

>> DOUG SCHEPERS: Oh, well that's okay.

>> MICHAEL BECK: Excellent. (Chuckles).

All right. Well, that concludes this webisode of technica11y and that also concludes Season 1 of technica11y!

>> DOUG SCHEPERS: You didn't tell me I was the season closer.

>> MICHAEL BECK: Yeah, you're the closer, man. (Chuckles).

>> DOUG SCHEPERS: I would have put a cliffhanger in there.

>> MICHAEL BECK: Well, people are clamoring for a Part 2.

>> DOUG SCHEPERS: Okay.

>> MICHAEL BECK: So you can go even deeper. (Chuckles).

>> MICHAEL BECK: But we'll have to keep that in mind for next year. Yeah, so thank you to everyone who has joined us over the past year, especially those who were here for every webisode; there are a few of you!

And speaking of next season, we'll be kicking that off with Knowbility's Eric Eggert. The title of his presentation is "ARIA Serious? The good and Mostly Bad of ARIA" or, "a-REE-ah" or however you pronounce it. Great title and great topic. We haven't really touched on that yet. And so, thanks again to Doug for that fascinating -- that was, whew, that gave me a lot to think about and some of the stuff I'm working on myself outside of this and Tenon. And thank you to Clare from ACS for the captions. And of course to all of you for attending. Have a great day. And we will see you all next month!

Back to the main page