The technology landscape has shifted from the time of that proposal, particularly in Web technology. There has been a shift away from domain-specific XML formats toward markup attribute-based semantics decoration of HTML and SVG, such as author-defined Dataset attributes or the Accessible Rich Internet Applications (WAI-ARIA) attributes, enhanced by script-based interaction.
Scalable Vector Graphics (SVG) has emerged as the graphics format of choice for data visualizations on the Web, and its markup metadata capabilities make it suitable as the source for other non-visual representations, including haptics and sonification. The native capabilities of the Web have also increased, introducing APIs both for haptics (the Vibration API) and sonification (the Web Audio API).
These increased capabilities, as well as pressure from regulation, have led to a recent proliferation of accessible data visualizations in several major software packages. There is rapid iteration in the commercial and open-source product side of accessibility for charts, with many different approaches. In the coming years, this may culminate in shared common practices, and even in a universal standard for interaction and the interpretation of data visualizations within a standards body like W3C.
In addition, there is activity among W3C’s participants that may lead to more detailed guidelines for data visualizations, as distinct from the generic “complex image” guidelines, within the W3C Web Content Accessibility Guidelines (WCAG), which serve as the basis for regulation and legislation such as the US Section 508 directive. This has the potential to become a virtual cycle, where innovation in the market leads to standardization, which leads to widespread legal requirements, which in turn rewards technical and user experience innovation, all benefiting not just people with disabilities, but all consumers of data visualizations.
The DIAGRAM Center has fostered this progress in accessible data visualizations in three ways: by convening leading accessible charting developers, projects, and companies in discussions toward standards; by fostering community collarboration and development in our code sprints; and by disseminating this information to educators, parents, publishers, and software professionals through our reports, code repositories, and other publications. One recent success story from our code sprints was the creation of a new open-source software project called SparkBraille, which enables the easy creation of interactive tactile line and bar charts through a common refreshable braille display, right from the Web, with no special hardware or software required; this project was started and completed from scratch in the 3 days of our 2020 code sprint, and the developers continued to refine it after the event.
It is clear that the nature of digital accessibility of charts lies in the future of Web technology, Web standards, and Web applications. While not all the details are yet obvious, the renewed emphasis on digital content being “born accessible” has shifted, and will continue to shift, the market for data visualizations.
If you’re using SVG for more than just icons, such as structured content like a chart or diagram, especially an interactive one, then you need to take a few extra steps to make it accessible. But making an SVG accessible has been a bit of a moving target over the years, usually getting better, but sometimes getting temporarily obscured, because of changes in browser and screen reader support. We’ve specced out most of this behavior, but it doesn’t mean we caught everything, or that it’s implemented consistently or correctly across all screen readers or browsers. And some methods that worked (a bit accidentally) were unintuitive or caused validation errors.
What we want for accessibility are clear, consistent methods for making SVG accessible, that are both reliable and valid across the whole toolchain, from authoring tools to validators and checkers to browsers to screen readers.
I’m happy to report that now the mechanics of SVG accessibility have never been better. It’s more predictable, more consistent, more interoperable, more standards-conformant, and easier than ever before to make SVG elements accessible to a screen reader.
For each focusable or interactive SVG element, add a tabindex attribute, a role attribute, and an accessible name (via an aria-label attribute or a <title> element).
Don’t add a tabindex attribute without an accessible name
Don’t add a tabindex attribute to the SVG root unless you need to
Avoid the title attribute (not to be confused with the <title> element)
The long version, in which we figure out some things that don’t work, some things that used to be necessary but are no longer needed, and just how strangely screen readers can act
I was helping John Gardner from ViewPlus with a new prototype for a simpler interface to load, insert, modify, and save SVG files in an HTML file, in an accessible way. As an incidental part of this, I made a few rough SVG example files that could be loaded and modified; I didn’t pay much attention to the sample SVG files, and just reused some simple SVG accessibility techniques that had mostly worked (and been necessary) at one time. I tested it in VoiceOver on my Mac and it worked fine.
By “worked”, I mean I could use the keyboard to navigate from the HTML form controls to the inline SVG (that is, an SVG file that’s been embedded directly into the HTML code), move to each of the “activatable” shape elements (the ones that had event listeners on them, along with tabindex attributes), hear the title of that element, activate one or more of them with the space or enter keys (which added a stroke to the shape), and navigate back out to the HTML controls to save the modified files. The SVG files were not the relevant part of the prototype; they were just stand-ins for the kind of files users would be loading. They wouldn’t affect the prototype, right? Wrong.
When I was demoing it with John, who uses NVDA and JAWS, he couldn’t navigate to the SVG elements. I could hear his screen reader through the phone. It kept cycling back to the last form element, a button, and repeating the name of that button. Sometimes it would get stuck, and he couldn’t navigate back to the previous form elements. He wasn’t sharing his screen, so I had no idea what was going on, and neither did he. Once in a while, he’d stumble on one of the target elements, but he couldn’t activate it.
Time to step back and debug this very odd behavior.
Kevin messaged me, and I sent him the sample app. A couple minutes later, I got a phone call. He needed to know what the expected behavior was. I walked him through it, and could hear similar problems as those John had. But with a critical difference: Kevin could see that the focus was shifting to the SVG elements, but it was still saying the accessible name from the HTML form control! And he couldn’t activate the elements! What fiendish torture was this? Had the browsers and Windows screen readers reverted to broken SVG behavior? What had 2020 done?!
For a moment, I felt despair. SVG and accessibility are two of my favorite technologies! They should work well together. They had to! I’d helped write the SVG accessiblity specs, for crying out loud! If I was struggling with this, then lots of other people had to be struggling, too. With Kevin patiently agreeing to be my remote eyes and ears and screen reader operator, I went back to basics and started testing combinations of SVG accessibility features. A furious set of permutations of tabindex, <title>, title, aria-labelledby, aria-label, and role followed, with Kevin and I both hacking the source code over a couple of hours. Herein I’ll recount our most salient findings, with 3 problems and 4 best practices.
Context: SVG elements need a tabindex attribute to receive focus
In HTML, most content is wholly or partly text. You usually don’t need to do anything special to make sure the screen reader reads that text out, though you do need judicious use of tabindex on custom controls. By contrast, most SVG content is shapes, which are not keyboard focusable by default. The only elements that are focusable by default are links. If you want a shape element to be interactive or navigable, you need a tabindex attribute with a value of "0". (Historically, SVG used to have a different boolean attribute for making an element focusable, mysteriously called focusable, but we deprecated it for integration into HTML in favor of the legacy HTML tabindex. Alas, you should not use focusable, even if it seems more logical.)
Every focusable element also needs an accessible name, which you can add with the native <title> as a child of the shape element, or with an aria-label attribute.
It’s also worth noting that the alt attribute doesn’t work with inline or standalone SVG elements, not even with the <image> element (the SVG analog to the HTML <img> element). You need to use an aria-label attribute or <title> element to add an accessible name. You can (and should) use the alt attribute for SVG files included in HTML via the <img> element, of course.
Problem 1: tabindex on the SVG root
This was a case of overengineering. Last year, I found a bug in some Windows screen reader / browser combos that you couldn’t navigate to an SVG shape element, even one with a tabindex attribute, unless you also had a tabindex="0" on its <svg> root element. It was like there was a windowless wall, and the root tabindex was the key to the door that let the screen reader inside the room. An annoying bug, but easy to work around. But it turns out, this is no longer necessary in any screen reader and browser combination we tried (VoiceOver / NVDA / JAWS and Firefox / Safari / Chrome). It just adds an unnecessary and possibly disorienting step. Don’t do this anymore, if you ever did.
This might not have been so bad in isolation, but it was devastating in combination with…
Problem 2: no accessible name on the SVG root
An “accessible name” for an element is the text the screen reader reads out when it’s presenting that element to the end user. This the text of the heading or button, or the alt-text of the image. (This is also the text label that someone using voice control uses to active a UI widget.) Without a text description, most SVG elements don’t have an accessible name.
Normally, I always add a top-level <title> element to my SVG files. I skipped it for these throwaway sample files, and I’m glad I did. Because that gave me the chance to discover that not only was the root tabindex unnecessary, but it also revealed some truly weird screen reader behavior. When NVDA or JAWS encounter an SVG element with tabindex="0" and no accessible name, they get confused. Very, very confused. They start repeating the last accessible name they remember (in this case, the HTML form control). Even when they encounter a subsequent focusable SVG shape element with an accessible name, they just can’t get over the trauma of the missing accessible name, and endlessly repeat the last good accessible name they spoke, for any SVG element afterward, whether navigating forward or backwards in DOM order.
And here’s where it gets truly odd. This actually seems to affect the navigation behavior, at least in JAWS. You can no longer reliably navigate back out of the SVG root. (Disclaimer: I didn’t see this for myself, I only heard it, and we were testing behavior fast. It might be that the navigation itself wasn’t affected, but only what was read out. Either way, tricky behavior you want to avoid.)
I’m assuming this is some sort of missing stack reference issue in the screen readers. Don’t fall prey to this one, because it will screw up all your SVG navigation. If you add a tabindex attribute to any SVG element, make sure you give it an accessible name, too.
Problem 3: missing role attribute
A little tinkering revealed the problem. I hadn’t added a role attribute to the SVG shape elements. Again, this turned out to be a happy accident (normally, I do add a role and often a aria-roledescription), since it illustrated the necessity of using it.
The role attribute is a feature of of the ARIA specification, which adds or changes the semantics of the element it’s used on. With a role, you can tell screen readers that a <div> is actually a button, for example, and that it should have the same behaviors as a button, such as being focusable and activatable.
Without a role attribute on the SVG shape element, in this case with the value “button”, JAWS would not activate the element, even though it had an event listener on it.
I will be honest: I’m not sure if this is the correct behavior per the specs or not. Either way, I personally think it’s the wrong behavior. This isn’t required for VoiceOver or for NVDA, and I think JAWS should change its behavior here. Consistency between user agents is incredibly important. But this is a pretty easy workaround, and a role is typically useful and adds semantics, so to make sure your interactive SVG elements are activatable, add a role attribute.
As an aside, Kevin pointed out that a few years ago, the way to make SVGs consistently read by screen readers was to follow Léonie’s advice from the article below, which includes using role="img" on the SVG root. Some people leveraged this by removing the role for SVG icons they wanted to be ignored. Even if a <title> were available, if role="img" were not present, the title would not be read. Recently, however, at least some screen readers have changed this behavior, so this hide-the-SVG hack no longer works. Avoid it. Either provide a meaningful accessible name to make it visible to screen readers, or leave off the accessible name to hide it.
I haven’t yet tested if you need to add specific roles (like "button") to make the element activatable, so proceed with caution.
Having solved all the major problems, we next turned to some quick best practices, to distill the minimum of what is necessary, and what is unneeded.
Best Practice 1: no aria-labelledby attribute required
In Léonie Watson’s excellent 2014 article Tips for Creating Accessible SVG, she describes a belt-and-bracers technique that was often necessary at the time. Some screen readers would not recognize the content of the the native SVG <title> element (again, not to be confused with the title attribute inherited from HTML) as the accessible name. To overcome this, Léonie wisely recommended that you use the aria-labelledby attribute to point to the child title, like so:
<path aria-labelledby="button_1" d="…">
<title id="button_1">Shiny red button</title></path>
This is effective, but frankly, tedious and verbose to maintain. And luckily, no longer necessary! We found no difference in screen reader / browser behavior between that and the simpler form:
<title>Shiny red button</title>
It won’t hurt to continue using the belt-and-bracers technique, but in 2020, it’s doesn’t seem necessary. In fact, pointing aria-labelledby at the <title> element may simply not have any effect. When Frank did some later validation testing for me (more on that below), he found a typo in one of my aria-labelledby attribute values, so it didn’t point to an existing id. It didn’t make a difference in the accessible name generation for that element.
However, it may be better not to use the <title> element at all. Like the HTML title attribute, modern browsers treat the content of the <title> element as a tooltip, popping up a little infobox after a short delay when you hover over the element. This is often not desirable, and inconsistent since it doesn’t really work on mobiles.
Best Practice 2: use aria-label attribute instead of <title> element
When do you not want the tooltip provided by the <title> element? When you’re providing more complex custom tooltips, especially ones that show immediately rather than requiring a delay. When you don’t want the title of the parent element to be shown for a child element without a <title> element. When it causes visual clutter or distraction on the “empty” space of a chart (imagine having the HTML’s <title> content pop up every time you rest your cursor on the page background).
SVG 1.0 had some great aspirational accessibility features, including text that’s actually text (not just an image of text), and the <title> the <desc> (description) elements. Having <title> as an element, rather than as an attribute, provides a number of advantages, including structured markup content and providing multiple alternative-language versions. These features, their motivations, and some speculations are documented in the W3C Accessibility Features of SVG note by Chaals McCathieNevile (@chaals) and Marja-Riitta Koivunen. But when we conflated <title> with a tooltip, which seemed logical at the time, we muddied the waters. I think this is a decision that should be revisited, and that <title> popups should be removed from browsers, possibly replaced with a hint semantic that works better with keyboards, touchscreens, and assistive technology.
In our tests of screen reader and browser behavior, the title attribute on an SVG element acted no differently than the aria-label attribute. Unlike in HTML, the title attribute in SVG doesn’t even produce a popup (while the <title> element does). The title attribute worked perfectly well in all screen readers to generate an accessible name. For better or worse, we don’t have the same complaints in SVG against the title attribute as described in Scott’s article.
However, in Frank’s validation testing, the title attribute was flagged as invalid in the W3C Validator. For the record, I don’t think that’s correct. I see this as more of an oversight in standards or a mistake in the Validator than as a problem with the SVG file. The title attribute, being a global attribute in HTML, should be allowed on any SVG element, too. That said, I still recommend against using it. If it were the only thing that worked, to be blunt, I’d use it whether it validated or not, but luckily, it’s not the only thing that works. The behavior is inconsistent with HTML, it’s unnecessary since it’s no better than using the aria-label attribute, and most importantly, it fails validation rightly or wrongly. Validation errors are a red flag that will be thrown in any accessibility testing or audit, and it will cause hassles without providing value.
In short, don’t use the title attribute in SVG (except perhaps on links which don’t have text content, and even there, you should probably use another accessible name mechanism).
Best Practice 4: validate and test
After Kevin and I wrapped up debugging the problem two or three hours later, I checked my email and saw that both Léonie and Jason had also had similar experiences and come to similar conclusions. Some simple errors in my SVG files caused utter chaos in screen readers, easily corrected but a hassle for screen reader users (and SVG authors like yours truly).
Afterwards, I had a conversation with Frank, who’s done a lot of SVG accessibility testing, too. Both while working at Visa and outside of work, Frank needs to make certain he is following all the regulations and providing an accessible experience, so he has a rigorous testing regime, including using the W3C Validator, aXe, and the Accessibility Insights extension for Chrome. Visa also has open-sourced their accessibility requirements for the community to learn from their tests, procedures, and recommended tools. I’m not specifically endorsing any of these tools; there are loads of other great accessibility tools out there, including Compliance Sheriff and Tenon to name just a couple, but find the tools that work best for your workflow, and use them.
Frank generously validated my code, both in situ (the injected inline SVG) and as the raw SVG files. He found the errors mentioned before (the typo in the aria-labelledby value and the validity errors for the title attribute on SVG elements), and wrote me a concise report via email. His testing came after we’d already solved the problem. I can’t say for certain that it would have pointed me to the solution that Kevin and I arrived at (and which Léonie and Jason verified), but it would definitely have pointed out some of my errors.
Now it’s your turn!
And that’s the kicker. We suffered so you don’t have to. I got lazy, and it caused me stress and lost time, even if I talked with and met some great people through it. If I’d tested myself in NVDA and JAWS, as well as using validation and checking tools, I may not have introduced these problems in the first place. Because I built accessibility in my code from the start (even if it wasn’t perfect), it only took me a short time to recover from the problems we’d found; it would have taken much more time to fix retroactively if I’d been further on.
Please learn from my mistakes. Follow these simple up-to-date SVG accessibility best practices, avoid the nasty problems, don’t get lazy, and test and validate with accessibility tools and real-world screen readers and browsers. SVG accessibility can be easy!
Once again, I want to profoundly thank Kevin Ackley, Léonie Watson, Jason White, and Frank Elavsky for their generosity, friendliness, and technical expertise in helping me diagnose and solve these issues. Without them, it would have been much more frustrating and much less fun.
When I tell people I make data visualizations for blind people, the response is almost inevitably a quick pause while the gears of their mind start spinning wildly, then “How does that work?”
I’m not going to tell you how I do it. (At least, not in this article.) But I will tell you how I think about it, and suggest how you can too. Many people love data visualization because it makes data and other complex information accessible. But there are many people for whom data viz doesn’t make things accessible, and it’s not because they don’t understand data.
For example, data viz has played a critical role in educating people about COVID-19. But have you wondered how blind people are getting detailed information about the pandemic, given that so much of it is in chart or infographic form? The answer, for the most part, is that people with visual impairments are simply not afforded access to that critical data. To understand how we can—and must—change that, we first need to understand assistive technology.
Assistive Technology, or AT, is pretty much what it sounds like: technology that helps people overcome a constraint in how they interact with the world. In the case of people with a visual disability, that often means using a screen reader. A screen reader is software that literally reads text from the screen, a bit like an interactive audio book where the user can change the pace, skip passages, find text, or jump to sections or links they’re interested in. It also describes the structure of the text, like headings or tables or lists. But the caveat is that it only reads text, so if there’s something on the screen that’s not text, it’s hidden from them. Some non-text things have built-in descriptions, like form fields or buttons or links, which are announced along with their text labels. So images need text descriptions, called alt text, and complex images like charts need effective text descriptions to be useful to a screen reader.
Or course, visual disabilities aren’t the only ones to consider, but for a primarily visual medium like data visualization, blindness is the obvious design constraint. Not everyone who has a visual disability uses a screen reader, and not everyone who uses a screen reader has a visual disability. And fortunately, text (which includes numbers) is a remarkably robust and transformable container for meaning, and works well with many types of AT. So providing a text equivalent is usually a great starting point.
The dirty little secret of accessibility is that there’s no single correct way to make your content accessible, and no one-size-fits-all solution … and this also applies to make your charts, graphs, and diagrams accessible. You need to consider your audience, and what you’re trying to convey, and decide how you want to convey the information to them.
The good news is that this is business as usual for someone skilled in data visualization. You don’t just take every dataset and render it as a bar chart, and call it a day. You think about the message you’re trying to send, and you pick the correct chart type, the right subset of the data, the correct framing, the clearest symbols, and the pithiest prose to craft your message. You adapt, remix, and innovate.
What I do, and what I’m asking you to do, is to bring the same craft of data design to accessibility as you do to visual representation. True accessibility means telling your data story to everyone.
When I work on making an accessible dataviz, here are some principles I focus on.
Value your reader’s time and attention
Use alt text to provide a one-sentence summary of the chart. One of the benefits of a dataviz is that it can convey a complex idea with a small investment of effort on behalf of the reader. If the fastest, best way to provide information were to use a data table, then you wouldn’t have used a chart. Please don’t make your readers walk through each cell of a table to get the gist of what you’re saying.
There’s enormous cognitive load in consuming large amounts of data. If at all possible, provide a textual summary of the chart in alt text, so the reader can decide if they want to drill in. Make it about the length of a text message, no longer. Write them a poem, not a novel.
Give all your reader access to all the data
While you don’t want to force users to slog through a data table, you don’t want to hide information from them. They may want to verify your conclusions, or might want to look at some relationship you don’t mention in your summary; for example, your article might specifically be about the COVID-19 infection rates in New York compared to other states, but they want to look at the numbers for their own state. If you’re showing it to some of your audience, don’t hide it from others.
A great way to do this is to include an alternative data table (often visually hidden but available to a screen reader) or a link to a CSV file that they can download and read in the app of their choice. As a side note, providing access to the raw data is generally a best practice so everyone can benefit from it.
Design equivalent experiences for all your readers
Even though blindness is an obvious constraint in data viz, it’s not the only disability to consider. We need to provide affordances for all of our users, on all of their devices. In general, don’t rely on only a single way to convey an idea. Add redundant representations for critical messages. Here are a few examples.
If you’re using color, think of how you can convey the same distinctions to people with colorblindness. Do you change the thickness of a line, or use patterns as well as color, or limit your palette to eliminate possible confusion? These are decisions you need to make on a case-by-case basis.
If you’re using metaphors and symbols, consider how people with cognitive disabilities will interpret your information.
If you’re using sound, such as sonification or spoken aspects, think of the deaf.
Don’t rely on a single signal for your most important message. Repetition is the key to mastery, and the easiest way to ensure that you’ve made your point.
Data Visualization IS Assistive Technology
You might be thinking that this isn’t relevant to what you do. Your talent is in representing complex ideas visually, and isn’t that incompatible with accessibility? The simple fact is that data visualization is assistive technology. It’s cognitive assistive technology. Our amped-up monkey brains aren’t good at seeing patterns in numbers, but they’re great at discerning patterns in topological space. So we map numbers to colors, location, size, and other visual symbols, and suddenly we can understand trends and relationships.
As an illustration, here’s the same data as a spreadsheet and as a line chart. Which one more clearly shows the fastest rate of population growth?
It just so happens that this visual mapping doesn’t work for people who can’t see. So, think of different mappings to make those trends and relationships explicit to people who need it, as another constraint in your user-centered design process.
If I could, I’d just hand you a set of instructions, and say, “Follow these steps, and your data visualizations will be accessible!”
But that list of instructions doesn’t exist. You are going to help write it.
There are numerous mechanical techniques that you can use, from structured markup to color-contrast checkers. And there are different media you can apply, from text to sonification to animation to tactile feedback. There are general authoring principles in the W3C’s Web Content Accessibility Guidelines (WCAG), though precious little specifically about dataviz, and there are good articles you can read on applying those standards to data visualizations. And there are legal reasons to make sure you check those boxes. These are tools, but they aren’t the solution.
You can follow all the rules, and still make data visualizations that aren’t accessible and that don’t inform your reader. As a craftsperson your goal should not be the worst content you can get away with, it should be the best experience you can build.
Don’t look at this as a requirement, an obligation, another checkbox to tick off. Look at accessibility as an opportunity to hone your skills, to move beyond the ordinary, and to provide an intentional experience for your users.
Some of the most effective, emotive, and affecting data visualizations I’ve experienced have blended two or more sensory techniques together to make a rich data representation that stays with me, that motivates me, that means something to me. That’s a high bar to aim for, but even if your experiment doesn’t reach that mark, you’ll be providing a better experience for a larger audience. Don’t be afraid to innovate.
We are at just the beginning of accessible data visualization. Join the conversation with me and others in the Data Visualization Society, and let’s aim for that high bar together.
About the author: Doug Schepers (@shepazu) is the founder and director of Fizz Studio, an accessible data visualization startup in Chapel Hill, NC, USA. Fizz Studio creates hand-crafted accessible diagrams and a next-generation accessible charting platform. Prior to founding Fizz Studio, Doug was a project manager at W3C, where he developed standards and prototypes and launched the developer relations program. He believes in positive social change through building communities and interoperable open technology.
How to create Accessible Single-Page Applications? Vue-Announcer announces useful information for screen reader users. Learn how to use this plugin to customize receive alerts and notifications as users navigate your application.
Maria Lamardo is a Front End Engineer at Pendo, who works with Vue.js and has a particular passion for web accessibility. She is a very active community organizer in the RTP area of North Carolina and beyond, serving as the founder of Devs@RTP, the Worldwide Event Manager and NC Chapter leader for Vue Vixens, and the Co-Founder of A11y Devs.
Are you curious to learn how Virtual and Augmented Reality (XR) technologies can be made accessible? This presentation will cover the findings of the recent W3C Workshop on applying Inclusive Design to the development of XR standards for the Web. The presentation will be full of examples and lessons learned from the conference.
What are XR Accessibility User Needs
Key principles of making XR experiences accessible
Lessons from existing Accessible XR products & prototypes
Conclusions from the W3C XR workshop
Thomas Logan has spent the past seventeen years assisting organizations to create technology solutions that work for people with disabilities. Over his career, Thomas has delivered projects for numerous federal, state and local government agencies as well as private sector organizations from startups to Fortune 500s. He is the owner of Equal Entry, whose mission is: “contributing to a more accessible world.” He is also co-organizer of Accessibility New York – a monthly Meetup for people interested in topics related to accessibility and people with disabilities. Thomas lives in Tokyo, Japan.
When: Thursday, January 16, 2020 at 6pm Where: Pendo, 150 Fayetteville, Raleigh
We are super excited to be hosting our annual Triangle Modern Web holiday party and to be co-hosting with Devs@RTP, Code Craftmanship Saturdays, TriangleJS, Triangle Node.js, GDG Triangle, RTP Angular.js, Triangle Serverless, Triangle Elixir, Triangle ReactJS, & Triangle Ruby for this awesome event!
Come and help us celebrate the end of the year & the holidays with a special meetup featuring a cookie exchange, white elephant and plenty of exciting lightning talks! You won’t want to miss out!
When: December 17, 2019 from 6:30PM – 9:00PM Where: Pendo (150 Fayetteville St #1400 Raleigh, NC)
Lightning talks by…
Rob Ocel Senior Software Engineer, This Dot Labs Talk: A quick introduction to state machines using XState
Wayne Hui Software Backend Engineer, Pentair Talk: Interacting with SQL Server
Lucas Spusta Student Talk: Top 5 VS code extensions
Charts, graphs, and other data visualizations are an increasingly common way to convey complex information quickly to your audience. They’re eye-catching, helpful to your users, and they generate lots of traffic to your site.
Join us for our next A11yDevs event, Monday, November 18, 2019 at 6pm in Durham!
Joel Crawford-Smith: Intro to ARIA
ARIA can be an intimidating and confusing topic. Even its name “Accessible Rich Internet Applications” is scary. But it does not need to be. There are some aspects of it that are safe for beginners, which can be beneficial to the people who rely on ARIA.
We need to rethink ARIA. ARIA is not writing code for a computer. ARIA is about improving human communication. Humans make content and interfaces for each other. The computer is just a translator. If we break ARIA down into nouns, verbs, and adjectives we can think about ARIA as short sentences. And most importantly, we will test what our sentences sound like on the other side of the screen reader.
Bio: Joel is a Duke Web Accessibility Administrator.
Maria Lamardo: Focus Management
Lets go over focus and how you can manage it in your application.
Bio: Maria Lamardo is a Front-End Engineer at Pendo
Benetech just published their Third Annual DIAGRAM Report. This is a resource aimed at providing resources on digital accessibility for educators and parents of children with disabilities, largely in the K-12 age range.
I was pleased to contribute the chapter on Accessible Data Visualizations. This was an interesting challenge for me, because I normally write for a highly technical professional web development audience, while this audience is broader and more focused on the pragmatics of education, sometimes using low-cost and low-tech solutions.
Volunteering at Benetech
I’ve volunteered with Benetech for over 7 years. I met their technical director at Open Web Camp in Open Web Camp 2013, where I demoed my early prototype of a web-based sonification system. It turned out that Benetech needed someone to help convert a desktop application for an accessible graphing calculator, originally developed by NASA, to the web, and they needed to sonify it like the original. I signed up to do the work, and in lieu of payment, I asked them to join W3C, where I thought their money would be better spent. Benetech has been a core contributor to W3C accessibility standards ever since.
Over the years, I’ve contributed to their accessibility projects in one way or another, from serving on their advisory board to chairing their accessible dataviz task force to writing accessible open-source apps and components at their code sprints (like an annotation browser extension and a reusable infobox popup).
Benetech does many things to promote social equity through technology. In 2010, they launched DIAGRAM: Digital Image and Graphic Resources for Accessible Materials. Their goal is to develop tools and best practices to reduce costs and other barriers to accessible images in educational content. It’s a worthy goal, one I’m proud to be involved with.
Benetech’s DIAGRAM Center has a mantra for digital content: “Born Accessible”. They urge everyone to think about accessibility when they’re first creating digital content, not to bolt it on as an afterthought, or worse yet, to publish inaccessible material that others have to remediate.
“Born Accessible” is a philosophy we embrace at Fizz Studio. When I first started talking about making data visualizations accessible by embedding the data in the SVG file, back in 2009, I often met with two primary objections:
File size: the data would add too much content to the chart
Proprietary data: authors would not be willing to share their data
But a decade later embedding data (part of what I call “Deep Graphics”) has emerged as a common practice for accessibility in web charts. Openness and accessibility will ultimately win the day. I’ll write more about Deep Graphics and embedding data in another post.
If you’re an educator, or the parent of a child with disabilities, or just someone who wants to learn more about making your digital content born accessible, I hope you’ll read the DIAGRAM Center’s 2019 Report and find it useful. We want to support you.