Reliable and Valid SVG Accessibility

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.

4 targets: not reliable, not valid (inconsistent and wrong); reliable, not valid (consistent but wrong); valid, not reliable (inconsistent but right); reliable, valid (consistent and right)
In statistics, we talk about reliability and validity (though “valid” here is a double entendre)

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.

TL;DR:

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).

That’s it!

Secret traps:

  • 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.

I don’t have a working Windows machine right now, and I wanted the advice of native screen reader users, so I took to email and Twitter. One of the joys of working in the a11y community is that people are so helpful and friendly. My friends Léonie Watson (@LeonieWatson) of TetraLogical and Jason White of ETS immediately volunteered to help, and started testing the file. And two strangers also stepped up: Kevin Ackley (@ackleyk), an Accessibility Tech Consultant from Nationwide Insurance, and Frank Elavsky (@FrankElavsky).

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.

One we sorted this out, the navigation behavior was smooth and consistent. And Kevin could “activate” the SVG shape element (adding a stroke via JavaScript event handler)… in NVDA. But not in JAWS. If it didn’t work in JAWS, it wasn’t really ready for deployment on the web.

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:

<path d="…"> 
  <title>Shiny red button</title>
</path>

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.

Note that accessibility support for <title> is brand new in Firefox! The Firefox 79 release notes from July 28, 2020 call out new support for exposing the <title> and <desc> elements to assistive technology, resolving a bug reported at least 5 years ago and noted in the great 2016 article Accessible SVGs by Heather Migliorisi (@_hmig).

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).

But you definitely want to add an accessible name. You can use the aria-label attribute for this. It provides an accessible name for that element to the screen reader, without prompting the browser to make a popup. If you want to provide a popup on hover and focus (for consistency), it’s easy to create one using JavaScript, taking the content from the aria-label or data-* attributes.

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.

Best Practice 3: avoid title attribute

Many accessibility professionals warn against using the title attribute in HTML. Scott O’Hara has a well-researched and exhaustive article on the varied support for the title attribute that’s worth reading.

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.

Why Accessibility is at the Heart of Data Visualization

To make data viz more accessible, we first need to understand assistive technology

Originally published by invitation on Nightingale, the Journal of the Data Visualization Society, on May 21, 2020, for Global Accessibility Awareness Day.

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

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.

Blind person using a screen reader
A blind screen reader user at work (photo credit: U.S. Air Force photo/Nan Wylie)

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 visual media, consider how blind people can consume your content. That might be structuring your SVG markup to allow users to tab through each data point, or it might be providing an alternative data table. Or it might be using sonification. Sonification is the representation of data as nonverbal sounds, like a Geiger counter or EKG; you can see and hear an example of sonification on the Accessible Pandemic Data Bulletin, one of the few sources that blind users can find partial data about the spread of COVID-19.

If you’re offering only data tables as a fallback, think of how people with low vision, like fully sighted people, benefit more from clear, high-contrast, low-noise visualizations.

If you’re using animation, factor in people with epilepsy, ADHD, or cognitive disabilities, and give the user control of the animation.

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?

Spreadsheet of population numbers for 4 most populous countries, with lots of numbers
Line chart of population numbers for 4 most populous countries, with the highest point for China but steepest line for India

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.

Uncharted Territory

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.

Dataviz Fireside Chat

Later today, at 1pm ET, I’ll be joining some dataviz accessibility luminaries as a panelist on the Data Visualization Society’s fireside chat webinar, moderated by Amy Cesal. Join us for a chat about accessibility and data visualization on Global Accessibility Awareness Day

Sign up for the webinar

Panelists:
Doug Schepers – Director at Fizz Studio
Melanie Mazanec – Engineer at Bloom government digital services
Dr. John Gardner – Founder of ViewPlus
Sarah Higley – Software Developer at Microsoft

Update

The communal notes are now available.

A11yDevs Meetup: Accessible Content Loading with SPAs

When: Monday, February 10, 2020 at 6pm
Where: Pendo, 150 Fayetteville St #1400, Raleigh, NC

Register now!

Topic: Content Loading That Isn’t Broken

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.

Presenter Bio

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.

Follow us on Twitter at @A11yDevs!

A11yDevs Meetup: Accessible Virtual and Augmented Reality (XR)

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

Presenter Bio

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.

Details

When: Thursday, January 16, 2020 at 6pm
Where: Pendo, 150 Fayetteville, Raleigh

Register now!

And follow us on Twitter at @A11yDevs!

A11yDevs Meetup: Modern Web Holiday Party

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

… plus more to be announced!

Register now!

And follow us on Twitter at @A11yDevs!

Accessible Charts with ARIA

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.

And they’re inaccessible.

But they don’t have to be, if you use ARIA. Find out how on the Tenon.io blog, where I consult on accessible data visualizations and developer relations.

A11yDevs Meetup: Focus on ARIA!

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

Details

Register now!

And follow us on Twitter at @A11yDevs!

First A11y Meetup!

Join us for the first ever Triangle Accessibility event, Monday, August 26 at 6pm!

Curious about accessibility but aren’t sure where to start? Come learn the basics about web accessibility!

Sylvia Pellicore: Basic Accessibility Fundamentals

Bio: Sylvia speaks, writes, and teaches about accessibility, works as an accessibility coordinator, and also provides freelance accessibility consulting and training.

Phil Daquila: How We Talk About Accessibility

All accessibility advocates and professionals have to talk with others
about accessibility. Maybe that’s a colleague, or a boss, or an
organizational leader, or a corporate client, to get awareness,
understanding, and buy-in. You have to explain a complex social topic to
a mixed audience that wears many hats and have different levels of
understanding about technology and accessibility. This presentation will
briefly detail how to communicate many accessibility basics to a diverse
audience.

Bio: Phil Daquila, Digital Accessibility Consultant at Deque Systems. Phil spent many years in media production, before devoting himself to practicing accessibility in web development and user experience. He honed his skills at UNC-CH before taking a job with Deque, one of the most well-renowned accessibility consultancies in the world. He is interested in the tactical and strategic aspects of digital accessibility, in higher education and in corporate business.

Joel Crawford-Smith: Intro to ARIA

Joel has rescheduled… stay tuned!

Schedule

6:00 pm – Pizza / Networking
6:30 pm – Intro
6:45 pm – Basic Accessibility Fundamentals
7:15 pm – Break
7:30 pm – How We Talk About Accessibility
8:00 pm – Networking

Register now!

And follow us on Twitter at @A11yDevs!

New Accessibility Meetup for RTP NC: A11yDevs

Fizz Studio is based in Chapel Hill, NC, in what we call the Triangle (RTP), and this area is lucky enough to have a good number of accessibility professionals. So, we’ve started a new accessibility meetup, A11yDevs! Triangle

Our goal with this meeting is to foster more local community among those professionals, as well as spread the word and teach others about best practices with inclusion.

We have some great local speakers planned, and we’re talking to hosts and sponsors. We’re also looking for more speakers.

If you’re interested in digital accessibility, and you live in the RTP area (or like to travel here!), please join A11yDevs, and follow us on Twitter at A11yDevs!

Update: new name!

To broaden our reach, reflect our pragmatic a11y solution focus, and sound a bit less like a company, we’ve changed the name of the meetup group from Triangle Accessibility / TriangleA11y to A11yDevs. All the names and links in our blog posts have been updated to avoid confusion.