A Tableau Accessibility Journey - Part IV - Keyboard Accessibility
/This post is a continuation of A Tableau Accessibility Journey - Part III - Color Contrast, earlier posts in the series outline the scope of the work we are covering as part of this effort. Part I of this series also includes a number of accessibility issues that were identified in our case study visualization, one of which was the inability to navigate and interact with our case study visualization without a mouse.
Keyboard Accessible
Let’s check WCAG 2.1 again to look into what we need to be thinking about from a keyboard accessibility perspective. I have references to each detailed section below, the summaries are from WCAG’s main requirement documentation.
2.1.1 - Keyboard: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.
Techniques to help with 2.1.1:
G202 - Ensuring keyboard control for all functionality. The objective of this technique is to provide keyboard operation for all the functionality of the page. When all functionality of content can be operated through a keyboard or keyboard interface, it can be operated by those with no vision as well as by those who must use alternate keyboards or input devices that act as keyboard emulators like speech input software or on-screen keyboards.
G90 - Providing keyboard-triggered event handlers: The objective of this technique is to permit individuals who rely on a keyboard or keyboard interface to access the functionality of the content. To do this, make sure that all event handlers triggered by non-keyboard UI events are also associated with a keyboard-based event, or provide redundant keyboard-based mechanisms to accomplish the functionality provided by other device-specific functions.
Use Case Failures Related to Color Contrast (from Part I)
Charts are interactive only through one means - Fail (If a user cannot use a mouse, they cannot interact with my charts)
No instructions provided for interaction - Fail (I do not provide any guidance to the user on how to interact with my chart, but left Tableau default interactivity in play)
Let me also refer you to Tableau’s Accessibility FAQ which includes their most recent Voluntary Product Accessibility Template (VPAT) reports for a ton of additional details on the reviews that Tableau has had done on their product. Also here is some documentation Tableau has on Keyboard Accessibility for Tableau on the Web.
Keyboard Navigation is Really Important
I have always found Tableau to be a very mouse heavy application. This is good in the sense that some users can “drag and drop” their way through their analysis, but I now also realize that this likely results in making it extremely difficult and/or impossible for users who cannot use a mouse to build OR consume Tableau visualizations. This applies to EVERYONE, people with permanent, temporal and/or situational disabilities, and yes, that includes YOU.
Our accessibility review found that the case study visualization had additional functionality for mouse users which keyboard only users cannot access and/or take advantage of. The other thing I need to consider here is the differences between keyboard only users and screen reader users. Léonie Watson has a wonderful write up on this topic. This ultimately leads to different levels of information access I am providing to consumers of the visualization. Now that I realize this more clearly, I am not feeling all that great about it, or the ~58 other visualizations I have on my Tableau Public Page.
Everything I have tried thus far I consider a “hack” and not really any type of solution that would be usable at any company. This is also part of the reason why it took me so long to get this post out. I have created an “idea” on the Tableau Ideas Forum to try and bolster support for improved keyboard interaction in published Tableau visualizations. The best thing you could do when reading this blog is to take two minutes, click that link and upvote that idea. Please, PLEASE go upvote this idea, it is one way that we can show Tableau the importance of this issue to it’s user base/community. This isn’t really something we should do, it is something we have to do.
Failed Attempts
I tried to think of several ways to tackle this which would be usable to the wider community. One of my initial, failed attempts was an Extension, I iterated a few versions of that and ultimately came to the conclusion that my Tableau Keyboard Navigation extension was a failure and was not ready to see the light of day. I decided to scale back a bit. I had bit off more than I could chew trying to solve too many use cases from the start. I decided to do the exact opposite. What would it take to enable one instance of a Tableau visualization, with a very specific use case and visual to have some sort of keyboard navigation. I decided to see if I could enable a similar experience for a keyboard only user and mouse user to answer one simple question. Did Dad or Daughter’s coin flips result in more heads results in game 5? I will admit that there is a bit of strategy in this question, I am purposefully including a comparison between Dad and Daughter because I think this could be a difficult task to address in Tableau’s out of the box keyboard navigable table that is provided for keyboard only users.
So… I ditched the Extensions API and went back to my old trusty friend the JavaScript API (sometimes referred to as the Embedding API now). I spun up a basic Create React App, instantiated a Tableau visualization and then tried to combine that with the Accessibility Controller open sourced as part of Visa Chart Components. (VCC). I had visions of doing a more pure integration… but opted to leverage some DOM trickery to speed up my process. So the proof of concept implementation leverages hidden d3 elements, built from the Tableau visualization, via the getData() API. These d3 elements are then integrated with VCC’s Accessibility Controller. This makes my life much easier as I can take advantage of VCC’s many accessibility features including the controller, aria label generator, built in keyboard navigation, accessibility descriptions and more. While this is a quick a dirty app strictly for testing, I did make the proof of concept repo open source and it can be found on my GitHub.
Did it work?
My thought here is “kind of”. There are definitely still issues, but let’s get back to focusing on my target question above. Did Dad or Daughter’s coin flips result in more heads results in game 5?
Using Tableau’s Table
As you can see in the video above, it took me approximately 75 keyboard navigation actions to get to the table of data, another 25+ actions to get to the record for Dad in game 5 and yet another 30+ actions to get to the record for Daughter in game 5. This also shows that I had over 30 actions where I had to remember what Dad’s count was myself so I could later do the math to compare the two numbers in my head.
In total: Over 130 keyboard actions were required to try and answer this question via the accompanying data table provided out of the box by Tableau. It also took me over two and half minutes to perform these actions, though I do admit to being a novice VoiceOver user.
Using VCC’s Accessibility Controller with Tableau
As you can see in the video, it took me approximately 30 navigation actions to get to the visualization, 2 actions to drill into the bars, 5 right arrow clicks to get to game 5 and then 1 more down arrow click to move down to the daughter bars thanks to VCC’s “cousin” navigation feature.
In total: less than 40 actions were needed to enter, navigate the chart and answer my use case question. However it did still take me over two and a half minutes because I navigated through the keyboard instructions in detail, which accounted for more than half the time and keyboard actions which were required. You can click here to go explore this proof of concept on your own, and you can jump the above video to 1:30 in if you want to skip past the instructions related content.
Conclusion:
This exercise was by no means perfect, but I hope that it will demonstrate a few things:
This scenario showed that it can be very intense to try and navigate the data table to answer the questions we have of our data. While the table does provide access to the visualization’s data, if enabled, it can present the user with a different data structure, have fields which are not really meant for user consumption (e.g., labeling and styling calculations) and also does not include any of the interactivity features which can make Tableau so dynamic and wonderful to work with.
You may have also noticed that all of my ideas centered around using Tableau’s APIs, so the question remains if you can’t use extensions or embed your visualization, what do you do? As of this blog, I don’t think we have an answer for this other than Tableau’s current data table.
We also showed that VCC’s Accessibility Controller and other accessibility capabilities can be abstracted beyond VCC itself, though this was an admittedly crude attempt at achieving this, more thought and effort are needed on this front.
And finally, in game 5, Dad flipped heads 4 times and Daughter flipped heads 7 times. Thus Daughter flipped heads 3 more times than Dad in this specific game.
So, in closing, please go upvote the idea for enhanced keyboard interactivity in Tableau. We, as a community, should aim to make it the highest voted issue on the Ideas Forum to demonstrate how important it is to this community to be more inclusive of people with disabilities. We can do better. We have to do better.
Here are the additional posts created as part of this series:
