axe-con Day Two

After an exciting first day of axe-con, day two brought another great round of speakers and topics. I chose to dive into a variety of talks along the different conference tracks to gain practical and organizational insights into accessibility.

Accessible SVGs: Inclusiveness Beyond Patterns

Speaker: Carie Fisher, Senior Accessibility Instructor, Deque Systems

SVGs have been around for awhile, and unlike other elements and trends over time, has stuck around due to its scalability, small footprint, and benefits for presentation and performance. This talk centered around various ways we can use SVGs in our websites while keeping them accessible. Here are a some things to consider when using SVGs:

• Color Contrast: SVGs have strokes and fills that can targeted using CSS, which means we have a lightweight way to change their appearance. If SVGs carry unique or essential content, they need to adhere to color contrast guidelines. This should also be evaluated if your website uses different modes. If you have a light and dark mode for your site, not only should you check to make sure your SVG colors work with any updated background colors, but also that they're not too bright, since there are people who use dark mode for valid accessibility reasons and not just for aesthetic.
• Animations: SVG animations are increasing in popularity because they're small, scalable files that can add a lot of excitement and visual interest to your website. However, non-essential graphics that autoplay for more than 5 seconds need to have a mechanism to pause or hide the animation. What can we do to be accommodating? We have some tips in our article about animated content, but overall we want to make sure the static version of our content, including SVG animations, still clearly communicates our intent. If content or understandability is lost when animations are stopped, we need to think through a reasonable, equitable alternative.

Be The Villain

Speaker: Eric Bailey, Designer, Thoughtbot (Original content source: 24 Ways "Be The Villain" article)

This ended up being one of my favorite talks of the day, not the least because it did a great job capturing a common practice of mine. I've been known to be great at poking holes in our products during user testing, much to the chagrin of some of my fellow RDG teammates. However, this is a practice we all try to do with each other to make the best, most sustainable end-product possible. The angle of this talk took that idea one step further. Not only should we be thinking about ways that our products can break by accident, we should think about how malicious people and programs can subvert our product's design for negative purposes. Only considering what the speaker calls "happy paths" means we miss out on thinking through all the different ways we should be supporting user experience. The example the speaker brought up was a chat widget. If we don't provide methods to protect from or address malicious intent, both a support worker and a customer could potentially abuse the widget to harass each other or even use information stalk the other. By adding protections such as the ability to export conversations, report a person to the organization, or even to block someone, we can help address the malicious ways a widget meant for good can be subverted.

In order to "be the villain," something we can try is to turn design principles on their head and address each principle from its opposite angle. These are from both Eric's article and his talk on the subject:

• Provide an equitable experience becomes forcing a single path.
• Considering situation becomes ignoring circumstance.
• Being consistent becomes acting capriciously.
• Giving control becomes removing autonomy.
• Offering choice becomes limiting options.
• Prioritizing content becomes obfuscating purpose.
• Adding value becomes filling with gibberish.

My takeaway from this talk? I've found a new way to poke holes in what we design and build. Not only should we look at the "happy paths," or the paths we expect users to take, but we should look at how to prevent subversion and malicious intent, off-boarding, you name it, the experience of users with what we build should be positive, or equip them with the tools they need to address the negative.

Accessibility at Scale

Speakers: Bryan Osterkamp, Technical Architect Principal, USAA and Tom Sikora, Director of Accessibility, Workday

This talk centered around scaling up accessibility within large companies and teams, specifically with their companies USAA and Workday. While each company had different approaches to work accessibility into their workflows, they did find overlaps around these central concepts:

• Empower your community: in a nutshell, accessibility should be something everyone on your team can do. By giving your team the tools they need to do testing and accessibility checks, everything gets collectively better, and introducing new accessibility improvements to your products and workflow goes more smoothly.
• View at enterprise scale: this concept takes a little bit of interpretation to apply to an agency situation vs. a large enterprise organization, but what we can do is audit for accessibility issues across different projects and websites. In this way, we can identify common accessibility issues and identify solutions that will have a large impact, both on individual sites and across the entire agency portfolio.
• Catch regressions: Identifying accessibility issues late in QA testing and going back to remediate isn't efficient, especially with products that are iteratively updated. What we should work on is not only incorporate best practices and knowledge earlier in the process, but determine manual and automated checks that can be done throughout to help prevent accessibility barriers from shipping or making it to market.

Axe-linter: Test in Your Editor

Speakers: Wilco Fiers, Senior Accessibility Engineer, and Michael Siek, Back-End Developer, Deque Systems

After hearing the announcement of the imminent launch of axe-linter for VS Code, I knew this talk was one I couldn't miss. Rapid strives to adhere to good code standards, and has a dedicated list of extensions that we use within VS Code to help make sure we're all on the same page. When the VS Code extension version of this linter comes out within the next month (I hope), I fully intend to evaluate it and see if it's a potential candidate to add to Rapid's extension family. With multi-language support and measures in place to help prevent false positives, this could help us as a team to build quality code and prevent the publishing of accessibility barriers being introduced to live sites. Look for a potential follow up article on this when the time comes!

Accessible Data Visualizations 101

Speaker: Sarah Fossheim, Developer and Designer

Everyone knows that visuals can help clearly and quickly communicate data, along with making content less dry. Visuals also have benefits for dyslexic users, who can process visual data better than text. This talk explored different ways to make complex dynamic data accessible in a useful way. Here are some insights I gained:

• Data differentiation: A common issue with visual data such as bar or pie charts is using only color to distinguish between different categories of data. As we know with accessibility, we need additional indications of differences in order to not cause issues with color-blindness and low vision users. Not only do we need more than color to distinguish between the visual data, we need to make sure that labels if they aren't visible by default, are both screen reader accessible and visible on hover and focus.
• Keyboard navigation: Many online charts have different things that you can reveal or change simply by moving or clicking your mouse. However, we need to make sure these same items are tabbable so that keyboard users can access the same content.
• Screen reader experience: Similar (and directly tied) to keyboard navigation is the screen reader experience of data. Not only should everything be accessible via keyboard, it should be in a logical order. If everything is out of order for a screen reader, the data becomes convoluted and won't make sense to your audience.
• Be able to drill down into the data: If you present everything all at once to someone who's relying on a keyboard and/or screen reader, it can take them ages to get to relevant data. Think of visual data like you would a megamenu. A good, accessible one will give you a high-level view of what's within, giving users the option to either skip or view more information.

Visual data? Still a real bear to think through. But if you keep some principles and practices in mind and, above all, have a clear idea of what the data is supposed to be communicating (aka. what's the point you're trying to make?), visual data can still be an excellent tool of communication online, no matter the audience.

How Color Contrast Got Their Attention

Speakers: Patrick Sturdivant, Digital Accessibility Evangelist & Lead Test Engineer, and Debbie Shulz, Senior Graphic Designer and Employee Accessibility Advocate, USAA

This was an interesting talk about how accessibility initiatives started and grew within the USAA organization. It was cool to hear the story of how they got started and gained momentum, including buy-in from top-level people within the organization to help continue driving the initiatives. There were a few morals of the story that I think have a lot of applicability not only within our organization but with clients as well. One, start with smaller things that have a big impact and also have easy to explain benefits. In their case, it was color contrast of PDF documents, which they were then able to spread throughout their other internal and external media. Another is to not position improvements as all or nothing. With accessibility being redefined and improved all the time, it's impossible to achieve anyway, and much easier to gain buy-in from the right people if you can propose iterative changes over time.

Accidental Advocacy: When You Don’t Realize You’re Steering the Ship

Speaker: Andrew Hayward, Lead Accessibility Engineer, Twitter

This talk was reminiscent of my own start in accessibility. At RDG we started with clients requesting audits and remediation of accessibility issues, and if we hadn't taken extra initiative, that's where it may have ended, and where it ends for some other organizations I'm sure. For me and another coworker, it was a jumping-off point that we used to take a deep dive into not only understanding accessibility but advocating for it, and working to incorporate it into our team's processes. Sometimes being an advocate is difficult, though. Luckily, Andrew had some tips for being a good advocate:

• Work on ourselves: try to be thoughtful when you speak and work, and decenter yourself from your cause
• Psychological safety: allow both yourself and those around you to be able to take risk without being punished or penalized, 
• Be aware of solution aversion: this is a trap that many fall into if we don't frame things correctly. Often, the way we propose a solution to an accessibility barrier is make or break depending on the priorities of the audience. Taking a step back and reframing your solution around how people are affected by it can be a way to gain buy-in.
• Put guidelines in their place: Guidelines like WCAG are a great starting point, but if you follow them to the letter and fail to see how they apply to the whole experience, you will definitely miss the mark.
• Remember change can be hard and slow: Not only are you learning about accessibility and advocating, but your organization and clients are learning along with you. Be patient but persistent and you'll get there eventually!

Day Two Conclusions

After the second day I was tired but grateful to have had the opportunity to attend all these talks, and flag ones I want to view later! I intend to incorporate some of the practical elements I learned into our front-end development work and continue to push accessibility to be incorporated both earlier and later in our processes. Can't wait for the next one!