Mara Averick & Maya Gans | Data Visualization Accessibility

Transcript#

This transcript was generated automatically and may contain errors.

Hi, everyone. Thank you so much for joining us today. Welcome to the RStudio Enterprise Community Meetup. I'm Rachel calling in from Boston. Well, really Dorchester today. Today, we're going to learn more and chat with each other about a crucially important topic, accessibility. So ultimately, making sure that our data products can be used by all users.

If you've just joined now, feel free to introduce yourselves through the chat window. Say hello, maybe where you're calling in from. I do also want to make note that if you want to turn on live transcription during the meetup, you can do so in the zoom bar below where it says more.

To go through a brief agenda, we'll have some short introductions and welcome everyone to the meetup. We'll have a presentation by Maya, A11y in R or ally in R, we were just talking about how you say that. Followed by a presentation by Mara on the high charts accessibility module.

And then a lot of time for Q&A and open discussion to share resources with each other as well.

So after the presentation, we'll have lots of time for Q&A, but can also ask a few right after each of the presentations too. Just a reminder that this meetup will be recorded and shared to the RStudio YouTube. So if you do ask questions in the zoom chat, you'll be part of that recording.

If you want to ask questions anonymously, you can do so as well. We have a Slido link for that, and I'll put that in the chat window here in just a moment.

But for anybody who's joining for the first time, a special welcome to you all. This is a friendly and open meetup environment for teams to share the work that they're doing within their organizations, teach lessons, learn, network with each other, really just to allow us all to learn from each other. So thank you all so much for making this a welcoming community too.

We really want this to be a space where everybody can participate and we can hear from everyone. I always like to reiterate this, that we love to hear from everyone, no matter your level of experience in the field too. I'll share a few other links in the chat window too. If you do ever have suggestions or want to speak at one of these in the future, love to hear from you.

But with that, that's enough from me. Thank you all again for joining us. I'd love to turn it over to our first speaker, Maya Gans. Maya is a data visualization engineer at Atoras Research, where she develops custom applications using R and JavaScript.

Hey, everyone. I am so excited to talk about this topic today. But a couple caveats first. One, this is a topic that I am super passionate about as of recent. I am not an expert in this, but I think that it is imperative that we all make considerations for accessibility.

The second thing is that I personally, when creating this talk or creating websites, visualizations, whatever it is, I have my own data visualization blind spots and so, yeah. That's just how I'm I just wanted to caveat that. That said, this is a really cool topic and I think we all need to be considering it. As Rachel mentioned, the talk is called A11T or Ally or Accessibility in R. There are 11 letters between A and Y in accessibility and that is long and that is why it is abbreviated as such.

And again, I am not an expert, but Sarah Alfosheim is and their blog posts are incredible, amazing resources. I will be sharing these slides and all the links are clickable therein. And Sarah, their blog post goes over has a blog post where they go over 10 do's and don'ts in data visualization. I figured I could adapt those into the R ecosystem.

Their blog post begins saying accessibility should always be a focus when designing products and the same goes with working with data visualizations and graphs. So, the main tenet of the internet is that everyone should have access to it. And likewise, we should be thinking about data visualizations in the same way. Thinking about our audience, who is consuming them, and they should be consumable by all.

Don't just put, this is a bar graph. I didn't get anything from that, right? So, what is awesome about the internet is that it uses HTML, which is a hierarchical markdown language.

So, what is awesome about the internet is that it uses HTML, which is a hierarchical markdown language, and also learning HTML is a little bit beyond the scope of this, but I just want to show how this library, because it's not a png, elements are clickable, and here what I did is I clicked, or you can hit tab to focus on the whole plot.

When you hit enter, so HTML is hierarchical, so hitting tab will find sibling elements. Hitting enter, you'll go into the tree, so here I've hit enter to go into the plot itself, and then I can hit enter again, and the screen readers will read to me that this bar segment is of count four, category, current status, and it's about the topics covered, and because this four is a sibling element to the four, I can now hit my left and right arrow keys to navigate to the 41.

This experience of using the keyboard and not using a mouse at all, I urge everyone to do this, so I am very much a mac user, but just going over to a blank slate google page here, if I hit command f5, welcome to voiceover, voiceover speaks descriptions of items on the screen, and can be used to control the computer using only your keyboard.

I am a super voiceover novice. I couldn't even tab from zoom, which is what I'm using into this actual google window, and that is why I urge people to play with this and navigate through using only a keyboard, and at the very least, if you are a shiny app developer, if you can take from this talk to tab through your application and see what that user workflow looks like, that would be a huge win on my end.

So again, I urge people to explore using a screen reader and how that's a new way to experience using a computer for you, as it is for me. It can be incredibly, it's, you want to consider the things that people are going to be tabbing through, maybe leveraging shortcuts in order to make tabbing easier for them, and thinking about keyboard shortcuts and all that kind of stuff is actually really fun. As a side example, if you use a screen reader on twitter, the first thing it reads to you is an element that a sighted user is never going to interact with. It reads out all the keyboard shortcuts to use when navigating through the website, so that you can leverage all the things that someone who's using a mouse could do.

Providing context and explaining your visualization

Number nine is providing context and explaining your visualization, and I, the way that I did this is using the annotate function, which is your best friend here, to add labels. I realize this text is super small, but at the bottom of the plot, I added all time low, and at the highest point in the plot, I added record high. This gives the user some broader context for if this, if you have a graph of some snapshot in time, but this is a record high temperature in the past decade or whatever, like it's, it leveraged text to really highlight those important narratives.

Another example here is I've created a bar plot, and you immediately are going to go to the maroon segment here, because I've leveraged both color and some text, which I very creatively wrote, some event worth highlighting, because that's where your eye is just going to immediately go there. So again, providing context, explaining the visualization, thinking about your audience, what they know, what they don't know, and really trying to communicate that story.

Focus on accessibility during user interviews

And then my last, by my, I mean Sarah's, last tenet here is to focus on accessibility during user interviews. So this applies more to creating dashboards and shiny apps than it does to a single static data visualization, but you still can, all, you should always be applying this first part in the preparation of creating anything.

You should give user personas disabilities. So first of all, what is a user persona? When creating a website or visualization or whatever that you want people that are not yourself to consume, it is really helpful to create detailed narratives of people who are going to be using this application. Sarah, who's the head of HR, blah, blah, blah, blah, she's going to be navigating through the application to do this, and Bob, who's this, is going to be doing that, right? So flushing out those stories will help you to live outside of your subjective biases when creating these applications.

The next step after preparing is recruiting. When getting people to participate in any of your user studies, you want to make sure you set one-on-one time. You might want to consider a ride share or something like that. You don't know what people's transportation needs are. And then finally, you want to inquire about the assistive technology used, which kind of goes into my last one here when you're conducting the interview. If I were to take a poll for all the people in this room, just the different mechanical keyboards that people use, we all have vastly different setups and preferences, and everyone in programming is opinionated, so people are going to have different hardware, so if you create an application with one kind of accessibility hardware in mind, and then someone brings in a joystick, you need to account for that.

And then lastly, you want to just consider that when scheduling these kind of interviews and people work using your application, that these might take longer, because as you saw with the screen reader, there's a lot that goes on there. So again, I'll give out these slides. There's links abound. I hope that I was able to impart some wisdom here, and I hope that if you are new to employing Ally techniques into your data visualization, that you share with us kind of what you learn, and yeah, I'm excited to be here and talk with you all.

Q&A after Maya's talk

Thank you so much, Maya. I always like to say we're all clapping, even though you can't hear us right now. We can use little Zoom reactions, though. Thank you so much for all of that. I see there's a lot of questions that have started to come in through both the chat as well as Slido, so I'm going to do my best to navigate those, but one of the anonymous questions was the principle of contrast checker is also applicable for spatial data map visualizations. Is that true?

Contrast checkers are for like the ratio of contrast for text as opposed to color blindness checkers, which look at what people with different vision situations see. So they're a little bit different, but there are checkers for both, and there are ones that are specifically for maps.

And thinking about outside of your subjective biases, like if there is a gradient that you're using, a default gradient, and you don't know how to create a custom gradient, then leverage all text. Leverage descriptions. You know what I mean? So it's okay if you're not up to the highest standards in WCAG, but then use the other tools if you can. You know what I mean?

That's a great point, Maya. Let me go over to a question from the chat over here on Zoom. I see Nils had asked, are you using a custom shareagen theme?

I live for customizing my shareagen slides, and yes, I am. I use a combination of Canva, creating background images, and importing them into the slides. Talk about extra.

I see Francisco, you just asked a question in the chat if you'd want to unmute yourself and ask live too.

The question was, I wonder if Maya could quickly talk about her process of creating a visualization and adding accessibility layers. Do you follow the principles and order? That's an awesome question. Again, harkening back to my caveat of this being a very new world for me, but I find this incredibly fun and important. In the slide deck, there's a link to a checklist. So, that is what I've recently been considering. And then I use a combination. I always use Lighthouse checks when I'm creating shiny apps to make sure that all my HTML elements are passing everything.

Mara's talk: Adventures with {highcharter} and the Highcharts accessibility module

Hi. Can you hear me? Awesome. Great. So, I am using Quarto , which you'll learn about in future times, or you have already learned about. Anyway, this is my first time doing this with Quarto. And I will say, writing this very brief talk took me way longer than probably any other talk I've ever written. And really not for lack of materials, I did write a five-part series of blog posts covering this topic. But in part because I've fallen down the accessibility rabbit hole, right? There's so much to learn and it's really interesting.

Accessibility is not one size fits all at all. And I ended up, talk about stealing from experts. I'm using Noto Sans, which is what they use on the Ally project and the World Wide Web Consortium on Web Accessibility Initiative for their slides and presentations. If it was good enough for them, it's good enough for me.

Rachel kind of covered this about me. My name is Mara, developer advocate at RStudio. I live in Missoula where it is a balmy 14 degrees right now. Things I did not create. Hi, Charter. That's good old Joshua who is an R package developer. Hi, Charts. That's done by HiSoft.

So, HiCharts, it is a JavaScript charting library based on SVG that makes it easy for developers to create interactive and accessible charts. The SVG part comes in quite a lot. But so, I want to disambiguate what the two things are. And HiCharter is an R wrapper for the HiCharts JavaScript library and its modules.

And how did I fall into this? So, Sylvia wrote a great post on resources for data vis accessibility. And they are these general and R specific resources on how and why to make accessible data visualizations. And at the time of its first writing, the HiCharts accessibility module didn't seem to be working with the HiCharter package. And I used HiCharter before. And I kind of remembered. I was like, you know what? I'm not a JavaScript developer. But if you can make it work in HiCharts, you can usually make it work in HiCharter. So, I decided to see if I could do it.

So, my motivate there were a couple of GitHub issues people had filed. And this was my great motivating example was somebody filed an issue saying that keyboard navigation wasn't working.

And you know what's really fun, by the way? Using keyboard navigation when you're trying to present a slide deck that uses keyboard navigation. But trust me, I am using my keyboard right now. You can see. Look, I did make it work. And look, I can even use my keyboard to do something like view it as a data table. Which turns out people want that. And then I could go back and hide the data. Now I'm using my own mouse. I could export the data. I could export it as SVG. Hooray. I made it work. And this was not the end of the story.

So, if we take my journey of the starting point, reading Sylvia's fantastic post, the end point, reading a five part series on how to do these things with increasingly complex visualizations. The posts have these accessible examples with High Charter and all this R code which is pretty long. But in the middle here is me learning a bunch of useful things. Non-coder framework specific. A lot of great things from High Charter but also things that apply in general. And this talk will be covering that middle point.

Highcharts accessibility features

A little bit of background on High Charts and accessibility. So, one thing which is this is not to say that it's perfect. But High Charts is not free for commercial use. And it's like a key selling point for them. Tons of companies have to comply with accessibility like 508 or regulations in the U.S. And it's a key part of their business model.

So, some of their features very much this is like not at all exhaustive is keyboard navigation, screen reader optimization, low vision features, sonification, voice input, tactile export. So, as you can already probably tell there, that actually accommodates a lot of different types of accessibility needs. So, for example, voice input for people who have trouble using the keyboard. Which is another population. It turns out people who use screen readers have really different preferences.

So, the background on this is that High Charter sorry High Charts did a collaboration with Elsevier. And Ted Gees is from Elsevier. And both of whom they're members of the Data Vis Accessibility Advocacy and Advisory Group. But they kind of got together to Elsevier was actually already using High Charts. And Ted had a lot of background in user testing. And they embarked on this journey of kind of developing this product together through iterative both accessibility expert testing and user testing. And that's really key.

So, this is just one quotation from an article about the project that they did from Lucy Greco who's a web accessibility evangelist. She's one of their test users. And she's been blind since birth. She said, you know, kind of, this innovation allows me to interact with the chart and understand the relationships of all the components of the chart to all the other components rather than just getting a description of the chart.

This innovation allows me to interact with the chart and understand the relationships of all the components of the chart to all the other components rather than just getting a description of the chart.

And that is enabled by the fact that these are SVG. And I full disclosure, like, don't know a ton about SVG. They've made it work. And you can drill down in it. I would never be able to come up with that. I'm not an expert. And I also don't have user testing. So, this is one of those cases where sometimes using the right tool teaches you a lot. And again, accessibility is hard. So, I like using this tool.

So, more background, if you're curious. They did the two of them have presented at the CSUN assistive technology conference is one of the biggest assistive technology conferences they've presented several times. And I really highly recommend this video interview.

There are a lot of links in here that I hope that you take a look at that. But that video interview is one of them. It's short and it really tells you a lot. Other collaborations that HighCharts has done with the Georgia Text Notification Lab, they made a completely open source HighCharts Notification Studio.

So, keyboard navigation. Users are able to navigate and interact with several components, right? So, the data points, the chart menu, and other chart controls using the keyboard only. So, this kind of goes beyond just being able to get to the chart or around the webpage on the whole. This means that they can interact with individual elements.

And one of the things that they found in their research was that for some users, they preferred using a data table when the data was relatively simple. So, you're able to view data table, which doesn't work out that well on a slide. I have to use my mouse. I apologize. And you can export the data if that's what you want. Again, accessibility is not a one size fits all type of situation.

Sonification. I did not create this one. But here is a cool demo of it. That allows somebody who otherwise wouldn't be able to kind of take in that information for themselves to hear patterns without it being described to them. Which was a feature that people wanted. And I know we had a low vision user accessibility expert who showed his experience in what it was like to get patterns from sonification. And that was incredibly meaningful to him.

I also wanted to show you an example of voice input. I had to embed this so that I can have my closed captions on for you. So, this video demonstrates using Dragon version 15 to navigate interactive features of high charts by announcing the accessible name of buttons and controls. Click JAWS. Click JAWS. Click voiceover. Click voiceover.

All right. So, I'm going to end it there. But that is using voice input to click and drill down on data series. Which is pretty neat.

Screen reader accessibility. Now, this is one part of it. This is for screen reader accessibility for individual points. So, one of the things that they found, again, with user studies was that rather than having these really long descriptions, a lot of users preferred that they get the information only when they need it.

And I apologize if that was more video situation. So, this allows a user who can use their keyboard to hear what is happening at each point. One. December 2010, 34.8%. NVDA. One. December 2010, 20.2%. Voiceover. Two. May 2012, 30.7%. Voiceover. Three. January 2014.

Cool. And oh, by the way, you might note here, and this will come up more later, is that this is actually these are the most common desktop screen readers. And they as you'll find out as I continue, they do not all they all have platform specific and sometimes browser specific accessibility APIs. So, when you're testing something, it's not as easy as being like, use a screen reader. They actually all work a little bit differently. So, testing is pretty extensive.

Why is it so impressive? Well, this gets at what I was talking about before. So, assistive technology and the accessibility tree. So, this is an example with an application. So, an application is broken down into something called an accessibility tree. And those nodes can be grouping nodes that are hierarchical or they can be individual elements that you can interact with in different ways. So, it could be something that you could click, that could have a state, that could have a role. And again, this is a platform specific accessibility API that creates that accessibility tree. And then that goes from the assistive technology to the user.