axe-con 2023: Day One (Ashley)

Well, this year axe-con went back from three days to two, but I think that was more about conference burnout than anything else. One can only sit through and absorb so many talks, right? Lesson learned. With some common themes of organizational and cultural growth and "shifting left," it is clear that accessibility continues to grow in its importance and is making progress toward being included in all parts of the research, design, and development process. But we can always get better! This year the conference was also attended by one of my fellow RDG coworkers, so we get twice the information and benefit! But still, with four tracks, we were only able to attend about 1/2 of the talks live. Here's my takeaway from the talks I attended on day one.

Accessibility at Google: Lessons Learned

Speaker: Eve Anderson - Google, Senior Director of Product Inclusion, Equity, and Accessibility

Sometimes, as a member of an agency-size company, I find it difficult to listen to talks from experts at large-scale organizations. This is for a variety of reasons, one of which being jealous of how robust their processes are, but also, sometimes it's difficult to see how their initiatives could translate to my own place of work. However, Eve brought up many good points that, although they were applied to the massive enterprise that is Google and its autonomous product teams, still held real value for an organization of any size. Here are some of the ideas I thought were universally relevant:

• The Hub and Spoke Model: As accessibility lead for RDG, I suppose I would be the "hub" within our company, with other designers and developers being the "spokes." At Google, there is a core accessibility team that has created standards and works with the different product teams. While there are people within the product teams that act as "spokes" from the hub, or help carry out requirements and influence their teams to create and meet accessibility goals, they are looking to the hub inside the organization to partner with and learn from.
• Influence, not Control: This is something I need to take to heart in every aspect of my life. Since not everyone has the time to become an accessibility expert on our team, it's only natural that accessibility barriers are unintentionally introduced in our work. In my role, I intend to see what I can do to create a set of standards and practices that help guide our designers and developers to not only build things accessibly, but also how to conduct tests and seek help when needed.
• Meet people where they're at: There are many robust and great systems out there to check accessibility. Google boasts its Trusted Tester Program, as well as a series of automated checks, and having Googlers (employees) with disabilities working on product teams and within their accessibility department. However, many organizations, even if they're lacking in accessibility, have systems in which they work, that work well for them. So, rather than trying to introduce a tool or process that may be great, but completely disruptive to the natural way your company works, it's better to see what processes and tools your people are already using, and see how you can incorporate accessibility into the existing systems. That way, there's a greater likelihood of it being adopted and embraced. There's also the idea that people with different roles have different areas of accessibility that are important for them to know and be able to test. Not everyone has to know everything, but knowledge of accessibility within their sphere of job requirements is important and more achievable.
• Prioritize and focus: Perfection in accessibility is a tall order. As Eve pointed out during her talk, it's really impossible. Sure, you can get an automated test to zero out, and real-life users can be satisfied with their experience with your product. But there's always something you could do to make it more efficient, more delightful. Rather than getting discouraged by the unachievable goal of perfection, or the volume of issues currently affecting a product, focus on incremental goals, and prioritize smaller fixes with big impact, or areas that are heavily used, instead of being overwhelmed by trying to improve everything at once.

After this talk, I feel inspired to distill some of my knowledge and provide some resources to members of my team so that we can continue taking steps in the right direction as a company. We can do this, RDG!

Update on The State of Accessibility

Speaker: Preety Kumar, CEO, Founder & Board Member, and Dylan Barrell, CTO and Author, both of Deque Systems

All I have to say is that this talk gave me a new appreciation of my dishwasher and vacuum cleaner (and testing tools). For a more detailed review, see Riley's take on axe-con: Day One.

Microsoft Inclusive Design: The Cognitive Model

Speaker: Anna Cook, Microsoft, Senior Inclusive Designer

First off, Anna's talk was very well organized and easy to follow. Which is a good thing, especially considering the topic of cognition was the theme of her talk. Cognition is one of the most difficult areas to pin down and create testable criteria before, since the range of ways people process information, focus, and complete tasks is so widely different, and that user group is essentially every user of the web. I especially liked that she compared people with and cognitive differences as simply mismatched human interactions, not as a condition or "otherness" to account for. She outlined a useful process for designing for cognitive differences, and identified five different areas of cognitive demand that can have vast differences in requirements for individual user groups.

Cognitive Exclusion Guidelines

1. Start with motivation: It's important not to get caught up in the possibilities that technological capabilities and advancements can bring. Innovation is great, but it's not always beneficial. Instead, we should look at people's motivation to interact with our products, and see what we can do to make sure the cognitive load doesn't outweigh the motivation for the task.
2. Identify cognitive demand: Cognitive demand has to do with what you're asking of a user in order to interact successfully with your product. There are different types, and ranges within them. Anna brought up these five:
   1. Learning: As we're aware of by now, not everyone does well on standardized tests. But that doesn't mean they're not smart. If your product has a teaching aspect to it, is it designed to only cater to those that like to read long articles? Or is information broken up into pieces, or presented in different visual formats? Technology often struggles with adapting learning for different types of users.
   2. Focus: Some people need complete silence and a computer with only one program open to be productive. Others prefer some background noise, or an environment with other people around for collaboration to truly thrive. The same extends to a digital experience. How are you helping different types of people focus?
   3. Decision making: This one rings true for me. I often get scared to click a button if I'm unsure of what the consequences will be. I might not be ready to submit a form, or make a final purchase, because I still feel like I'm missing some information that will make me regret my decision. Offering information at the right time can help ease decision-making for people like me. Not so much for my impulsive husband.
   4. Recall: Forcing people to remember something they entered ten steps ago on a long, paged form is not ideal. Some people may have no trouble, but others may have to click back through to see what they entered, then go all the way back to continue their task. Carrying relevant information through an experience helps with people's confidence and efficiency.
   5. Communication: Whether it be alerts, help content, or error messages, communication in technology can be a blessing. It can also be a curse if you're bombarded with too much information, presented with confusing data, or if non-urgent alerts interrupt you. Try to make sure communications are clear, concise, and helpful without being overbearing.
3. Co-create with diversity in mind: Anna's solution to help with cognitive inclusion? Bring in different types of people during all steps of the process. Conduct user testing with neuro-divergent people. Work with them. Learn from every type of person, since everyone has different interests, preferences, and needs.

Research Through Broken Lenses: The Need to ‘Shift Left’ in UX Research

Speaker: Michele Williams, M.A.W. Consulting, LLC, UX & Accessibility Consultant

"Shifting Left" is not a new concept for me, or for accessibility in general. In general, we've grown from awareness of accessibility and its importance to already working on incorporating it earlier and continually throughout the process—which is the definition of shifting left. If a project timeline is left to right, shifting accessibility left on that timeline instead of being tacked on the end or the right side. The point that Michele Williams makes is that UX Research goes hand in hand with accessibility, and needs to be foundational in nature. We should be doing different types of research depending on where we are in the project, not just trying to leverage user testing at the end to affirm assumptions that have been made along the way. However, even if your process is already good at incorporating UX research in all parts of the project process, you could be doing it through a "broken lens," which can end up misguiding a project so that it's not a true and inclusive solution. Here's some of the "broken lenses" we need to work on avoiding as we conduct and synthesizing user research:

• Trying to "fix" something instead of exploring alternatives: People with disabilities don't need to be "fixed." Nor should a single type of technology try to be all things to all people. Instead of trying to force a solution to work the same way for every person, which would result in a workable experience for some, but a truly horrific or unusable experience for others, we should make sure we provide equitable (not to be confused with separate) alternatives for people to interact with our products.
• Bucking "ableist" views: Ableism can skew our perceptions of innovations, especially with regards to accommodation. Looking down on people with disabilities, or lauding innovations as a way to help out those user groups, does a disservice to them. People are people. And everyone is different.
• Avoid a "savior complex:" How would you feel if the inventor of the washing machine delivered it proudly with the comment that it would help make your life easier since you have trouble washing your clothes the same way that "everyone else" does? People with disabilities aren't looking to be saved by product designers and developers. They just want to do the same things everyone else does, even if how they do them is different.
• Inventing solutions: If we don't actually work with and interact with users in the disability community, how can we come up with a solution that works for them? This is a pitfall that leads many to build out a so-called innovative solution that actually doesn't help anybody, since the fundamental user need was not discovered early in the process.

DevOps: Top Lessons Learned on Shifting Left For Accessibility and Other Experts

Speaker: Gene Kim, Wall Street Journal bestselling author, researcher, and multiple award-winning CTO

Gene Kim's talk was very open to interpretation for how his concepts could be applied to accessibility and incorporating earlier into the process. Many of the points he made had to do with efficiency, communication, and the concept of technical debt. I'll just go ahead and made some of those connections to accessibility here:

• Efficiency: If our devOps and processes don't incorporate things like accessibility early and often, then the miscommunications can result in having to circle back and refactor, rebuild, or start over completely.
• Communication: Gene made an analogy between moving a couch together with someone or moving two chairs individually. The thing we have to do with regards to accessibility is determine which areas of your processes require teams and team members to work together and communicate, vs. which ones can and should be carried out by individuals. For instance, you would not need to coordinate with a back-end developer on purely cosmetic design choices, but if you are looking to build more complex functionality, it's important to have an understanding on both sides. Move that couch!
• Technical debt: I found this part of Gene's talk perhaps the most interesting. He discussed the concept of incurring a lot of technical debt if you try to do things too fast or cut corners, that over time can lower the quality of your product, satisfaction of both customers and developers, or even make an entire product fail. The more technical debt you introduce, the more work you have to do to either fix it or try to complete tasks that would otherwise be quick and easy. Addressing technical debt should be included in every time you go through a development cycle. For accessibility, this could surface as headaches trying to "bolt on" accessible solutions, or worse, the dreaded lawsuit. Don't let technical debt take your product down!
• Safety: Nobody wants to dread pushing the deploy button, right? If we think about accessibility earlier in the process and incorporate it into our workflow and tests, we can have a higher degree of confidence that what's being rolled out won't introduce accessibility barriers.

Digital Accessibility Legal Update

Speaker: Kristina Launey, Seyfarth Shaw, Partner

I've attended this talk every year since axe-con started (a whopping three years, I know), and I'm never disappointed. Navigating the legal waters of digital accessibility is difficult. It's murky and often contradictory. Unfortunately in the United States, there is still a wide degree of separation between legal requirements and compliance guidelines, with no real legislation officially targeting online entities in the private sector. So, in a country where enforcement of laws such as these comes in the form of lawsuits and damages, we're still stuck after well over a decade quibbling over the same question: does the ADA (Americans with Disabilities Act) apply to websites? Even the federal courts disagree.

Since one of Biden's promises was to come up with legislation for this exact issue by the end of his administration, we've luckily seen a little progress in what was abandoned during the Trump administration. However, it's still mainly targeting state and federal government entities (Title II), not the private sector. Call me one frustrated lady. In February of this year, a report was released regarding government compliance with Section 508 over the last 10 years. As of the publishing of the report, there are still many government agencies with non-compliant websites. Ouch!

In other news, the number of accessibility lawsuits dropped significantly in 2022, contrary to the growing pattern from the decade prior. Interestingly enough, the number of lawsuits coming from California dropped drastically. Whether this is because district attorneys are preventing the historically high number of filings, or the fact that in California there have been decisions that websites are largely not included in the ADA, I'm not quite sure. New York, on the other hand, has had a steady increase in the number of web accessibility lawsuits, and decisions there are that websites are covered by the ADA. Make of that what you will.

Lastly, we should be aware that lawsuits are not limited to consumers with intent to patronize our online experiences. Serial plaintiff testers can test for issues regardless of whether they want to use the site, and file a claim if they discover accessibility barriers. So never assume that people with disabilities fall outside your user group. One, they don't. They're part of your audience. Two, even if they're not (but trust me, they are), you're not safe from legal action.

Next Generation Accessibility Test Automation

Speaker: Jonathan Thickens, Deque Systems, Product Manager

One word. Drool. Launching this year is Deque's new Watcher API which will allow for an easy way to integrate accessibility testing into existing git workflows. The axe Developer Hub that is paired with this API presents information from automated testing to developers, allowing for comparisons of data, assisting with prioritization of fixes, even setting acceptable thresholds of errors allowed to be deployed, so organizations can make sure they're steadily improving and not introducing more issues. We'll see if RDG gets accepted into the beta testing for this product! I for one, would love to integrate this into our current processes to help increase awareness and guide fixes for our entire team.