axe-con 2024: Day Two (Ashley)

Here we are at day two! My day one conference fatigue wasn't too bad. The shorter day is definitely nicer than in past years. But definitely harder to sneak lunch/bathroom/walking breaks into 10 minute intervals. Compromise and give 30-40 minutes for lunch instead of over an hour like past years? Anyway, here's my thoughts on day two of axe-con!

The Folly of Chasing Demographics (You don't know your users, and you never will)

Speaker: Heydon Pickering, Freelance Inclusive Design Consultant

This talk started out in a bit of a dry humorous way about how the speaker, Heydon, gets his race/nationality mistaken due to how he looks. Not only that, but some people continue to insist he is from a country in the Middle East when he's UK born and bred. The point? You don't really know your users, and you shouldn't make assumptions based on the misguided idea that you do.

He shared a great example of alt text on a stock image. As a sighted person, it's easy to think that you can have an empty alt attribute because, if it's being ignored by sighted users, then blind users don't need the distraction of having to have the contents of the image announced via screen reader, right? But there could be people with partial or blurred vision, who see an image there but aren't quite sure of its contents. Alt text could come in handy for those people.

His point? Design for the tools, not what you think you know about the users.

It can be easy to fall into traps that cause us to narrow our designs or unintentionally come up with solutions that don't serve the greater population. Decisions based on a single article or opinion, for example, or basing designs purely off of taste. You also shouldn't base your design decisions purely on testing with small samples of disabled users, for the same reasons of only getting insight into a narrow set of opinions.

He also points out the disparity of experience among screen reader users. Not everyone has learned to interact with the web via assistive technology from the get-go, and some are just less familiar with technology altogether. There have been tests and studies that show that many screen reader users struggle to understand/navigate things like ARIA widgets (think tabs), or get confused by things like live regions. His advice? Avoid complex solutions if simpler semantic alternative are available. And, what's more, we don't need to dig into where our users are from or what their preferences are to arrive at these conclusions.

If we do look at demographics and come up with personas and a primary audience, all we're doing is supporting misconceptions and purposely narrowing our designs when we should just be designing for all.

Heydon left us with the final words, "succeed at non-exclusion where you would fail at inclusion." I know that there may be many a UX research that will struggle with his point of view in this talk, but I for one appreciated this fresher perspective. I'll be digging more into this at Heydon's website for sure.

Neuroinclusive Content Design

Speaker: Laurie Cameron-Back, Hilton, Lead Content Designer

Laurie gave some interesting insights into content design (which I previously didn't really know much about the details of their responsibilities). They actually have many similar roles as what a visual UX or graphic designer does, and do far more than write copy to fit existing design. But they do write copy, for everything from microcopy in user experience to information architecture of a site.

Neurodiversity deals with a number of different diagnoses, such as ADHD, anxiety, autism, dyslexia, dyspraxia, epilepsy, OCD, Tourette syndrome, and many many others. It is the largest and broadest category of disability, and least addressed in official guidelines like WCAG. There are a variety of affects these different conditions can have, such as hyper focus, issues with detail processing, concentration, memory, cognitive control, etc.

So how do you design content for such a broad user group? Luckily, there is a lot of overlap with designing content to be neuroinclusive, and just creating quality content in general. Things like reducing complexity, breaking things up into reasonable pieces with headings, not using jargon, etc. can go a long way to make content easier to digest and retain. Layout and flow should also be clear and consistent to reduce confusion and cognitive load. Handling errors should also take care not to blame users, but explain the problem and provide a solution. Errors should be solvable, not blocking.

I've heard many of the concepts in this talk before, both in school and over the course of my career, but it was interesting to see it from a more pure content designer perspective. And I learned that even for titles, avoiding title case in favor of sentence case can help decrease cognitive load. So as familiar as many of the points in this presentation were, you still learn something new every day!

Advocating for Change

Speaker: Jonah Berger, International Bestselling Author, Wharton School Marketing Professor

For a more in depth insights on this talk, check out Haley's axe-con day two article. Muffled audio issues in the beginning aside, it was definitely an interesting talk that took a step back from accessibility and looked at how to drive change by identifying and uniquely addressing barriers to change instead of just pushing for it.

Establishing a Scalable A11y Education Ecosystem

Speakers: Alexis Lucio, Senior Accessibility Designer, Catharine McNally, Sr. Program Manager, Accessibility, Lindsey Wild, Senior Software Engineer, Accessibility, all from GitHub

First off, I just love that these accessibility leaders in GitHub were from all walks of life. Huzzah for giving the white male programmer stereotype the boot! I'm also jealous of what they were able to create at GitHub with regards to accessibility education. In a much smaller agency situation, it's difficult to envision a similar model at RDG, but a girl can dream!

What they came up with was a way to learn both collaboratively as well as at their own pace with an Accessibility Design Bootcamp and different tracks to create Accessibility Champions. It was interesting to see how they developed their Bootcamp and tweaked it to cater to their specific needs and feedback received. Since it's still a relatively new concept (roughly a year old), I'm curious how it will continue to grow and change to keep up with the industry.

Their Champions program is something I wish we could do at RDG. It would allow our developers to go through the training as they have time and, in an ideal world, be catered to back-end, front-end, or UX/design. Either way, it's awesome to see how they didn't just create a static education course, but listened to people that have been through their programs and are actively working to make improvements so colleagues are more engaged and active.

In the end, a hybrid of their Bootcamp and Champions program might be a great way to expand education for an agency...if only there were time to come up with the content! Or beg Github to make their materials available for the masses. Here's to hoping!

Accessible Component Libraries: The Foundation of Accessibility at Scale

Speaker: Rachael Yomtoob, Developer Advocate, Deque Systems

Revisiting Rachael  after hearing her talk about WCAG 2.2 and how it applies to native mobile apps yesterday, but I didn't mind, because she's a good speaker! for day two, she was back to discuss accessible component libraries.

Drupal may not consist of component libraries in the traditional sense, but since we're still looking at different types of content utilizing the same set of templates and patterns, I'd say our Drupal projects still qualify as having a design system, if done well. We do many React and other JS projects as well, which have your more traditional components. We've also utilized component libraries and frameworks like Chakra UI, and have experience in utilizing and adapting premade components for our own use.

She made some good points, like how component libraries are not only great for consistency and efficiency, but they can extend accessibility best practices—or accessibility fixes—in a widespread, low-effort high-reward way.

She then took us on a tour through Cauldron, Deque's open-source React component library system. They've built many different accessibility aspects into their components that don't require developer input, such as automating ARIA id relationships and defaulting to appropriate attributes. Reminds me of something very similar we did with inputs and their labels on a Laravel project!

The next part she went over was testing your component library, which is an area we are making strides in but could still make progress on. A point that she made was that documentation sites make great testing areas for end-to-end testing. Makes sense, but perhaps more difficult to justify at an agency level with only small teams using the components, usually just for one project. So for us, our tests are usually better suited to user flows within the project itself. But I definitely see the need when it's used by larger teams/across multiple projects!

Some things to remember: developers can make mistakes. As of this writing, no component library is 100% accessible by default. Components can be misconfigured or misused. So we need to make sure we're still evaluating the output and overall product with tools such as automated testing, manual testing, end-to-end testing, linting, contrast checkers, etc. to make sure we're building accessible products!

Measuring and Benchmarking Accessibility

Speaker: Niki Ramesh, Digital Accessibility Lead, Canadian Broadcasting Corporation (CBC)

I really loved Niki's concept of content vs. container, as it's very common in the world of CMS systems to have issues that are solely in one bucket or the other. Accessibility goals (important for measurements and benchmarks, of course) are also usually oriented toward one or the other. You might want to bolster accessibility checks and guidance for content admins. You also may need to fix your site's header semantics for proper keyboard navigation. Needless to say, I related to her comparison of the two and keeping them in mind as you go about setting and tracking goals.

Niki broke down measurement metrics into content vs. platform, and customer-facing vs. operational measurement. Some goals may seem soft, but have hard metrics to measure and back it up, such as using the percentage of disabled visitors to measure attitudinal barriers.

She mapped out different testing methods though what has become a familiar-looking process of research, design, develop, and ongoing/maintain. There are challenges along the way, having to do with things like disclosure of information, costs, effort, etc. But incorporating measurements before the end product can be very beneficial to back up design choices!

Benchmarking is something I wish we did more of at RDG. In a nutshell, it means, conduct the test more than once. Get a baseline, address some issues and feedback, then test again! Otherwise, how do you k now if your solution truly addressed the problem? We may do this with end-to-end testing and automated and internal manual testing, but doing it with user testing would be by far the most telling, in my opinion. I also liked that they looked not only at task completion rate, but also issues identified. Users may be able to complete a task, but if they run into issues that hinder their experience then that's still something that needs to be improved.

After this talk, I wouldn't mind seeing if there are standard goals we should have in our back pocket, along with specific ones for clients that are actively conducting accessibility initiatives. It will help before and after reporting on remediation, but also perhaps some ongoing support. And who wouldn't want that?