axe-con 2022: Day One

In one short year, axe-con has grown from a two-day conference to a three-day conference, with over 23,000 attendees. That's a big virtual conference! In fact, according to Deque, it's now one of the biggest accessibility conferences in the world. With the sharp increase in online shopping, working, and collaborating during the past few years, web accessibility is more important than ever, and maybe for the first time experiencing the beginnings of a larger scale cultural shift in how it's viewed by the world. The conference lineup this year is impressive, with an extra day and four tracks to follow. I chose to jump around on most of the tracks to learn from a variety of perspectives. Below is my takeaway from today's talks.

The Future of Web and Accessibility

Speaker: Sir Tim Berners-Lee, Inventor of the world wide web

The conference opened with a bang, and we got to hear from the founder of the web himself. This talk was eye-opening as Sir Tim discussed the journey of the web since its infancy and how it's been corrupted over time. Originally, the internet was supposed to assist users in doing tasks they needed to do. Browsers, with their official name of "user agent," are literally supposed to be agents on behalf of users to execute, fetch, and perform whatever else is necessary. Over time, software and programs have gone from being made to help users to capitalize on them. Developers are now often creating things to increase clicks, distract users, and create revenue for their employers and clients. With this has come the emergence of many types of 'dark patterns' that benefit companies instead of individual users, such as making it difficult or even impossible to unsubscribe from an email newsletter or deactivate an account. Even the domain name system has been corrupted in its own way, with people buying up domains and making a tidy profit when companies and individuals need to pay ridiculously marked-up prices to get the rights to URLs that are sitting there unused. There has also been an increased dependency on the cloud for storing personal data, which can hamper the efficiency of user experiences.

In fact, for Sir Tim, the future of the web is regaining control of our own data through decentralization. We've probably all heard that buzzword around things like cryptocurrency, but it's increasingly applied to data as well. He's currently working with Solid, a project that is working to allow users to keep their information in decentralized data stores that are secure and can be authorized to be used anywhere. One of the goals is to empower people with their own data instead of being at the mercy of companies that use it to target them for their own gain. Another goal is to remove the silos that have built up with companies around data storage, so specific data can be securely shared with any software or app. How might this relate to accessibility? In terms of usability, it can be very useful. As far as being able to maintain privacy and personal autonomy, there's a great benefit in not having to reenter known data every time you need to do something new on the internet, not to mention efficiency of user experience. I for one am curious to see where projects like this, as well as the current push to decentralize the web in general, go in the future.

The State of Accessibility and axe Updates

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

Similar to last year, this talk was Deque's way of setting expectations for the conference and talking about the latest and greatest on axe products. The year's theme is high velocity, which is a good comparison to how many companies have been approaching the accessibility of their own products during the pandemic. Hard to believe, but digital accessibility is actually 50 years old! Of course, web accessibility didn't officially enter the picture until Section 508 in 1998, and here we are today with more and more countries setting accessibility mandates and directives. In the U.S., the landscape of increasing lawsuits may seem bleak, but it's currently the best way of fighting for equal rights in the digital world. I personally am hoping that we can come up with our own directive or mandate that includes more positive avenues communicating issues, as well as committing to and following through on continuous improvements.

There were several exciting developments for axe tools, as well. Their accessibility linter, launched last year, has millions of downloads and continues to improve its rules and expand support for new languages. I'm probably most excited about that, but also the thought of the tools they're working on to better incorporate accessibility into testing and deployment processes. I'll have to see if I can attend the more detailed talk later this week or if it conflicts with another of the many amazing talks in this year's lineup.

New CSS with accessibility in mind

Speaker: Rachel Andrew, Staff Technical Writer, Google

I remember Rachel from last year's conference, although I didn't realize until her talk began that I'd heard her speak before. This time around, she talked about some great things that CSS is offering, along with what to watch out for to make sure we're not getting too crazy with our styles to the detriment of accessibility. So many things were covered, I decided to break down my takeaway for this talk in terms of what I'm most excited about and the most helpful tips (for me and everyone else in development).

What I'm excited about:

1. @container query: While this is still in development and not ready for prime time (booooo!), it's ready for experimenting on Chrome Canary. What is this? What front-end developers have been waiting for for a long time now. Once this is officially launched and gains support and traction, we'll finally have an easy way to design components based on the width of their parent container. Instead of having to repeat HTML or greatly increase lines of CSS to style the same element in two or more different ways, we can tell an element how it should look depending on its own width, not the width of the window or media. this takes both repeated elements and responsive design to a whole new level! I can't wait for it to get further along in the rollout process.
2. display: contents: This has fairly wide support, and can save developers a lot of headaches when styling semantic HTML. If only I got paid for each time I had to override ul and li styles because I didn't want any attached theme or user agent styles to apply, I'd be a rich woman. Too bad there are some bugs with this style and the accessibility tree that need to be worked out with Safari still, so it's most safely used on divs and spans, but hopefully it will be fixed so that it doesn't negatively affect assistive technology users and we can zero in on styles that count and make child elements behave like parents when we need to.
3. media preferences: Okay, so this one has been around for a while. At RDG we're always using color scheme and reduced motion queries, but there are so many more that we can use to further tap into individual user needs and preferences to make an optimized experience for people with any combination of preferences! Some other ones I'd like to explore include prefers-reduced-transparency and prefers-contrast.
4. color-contrast(): As a company, we test out our color combinations to make sure they're at least AA compliant, if not AAA. Implementing this is something else entirely. What if you have a light body background but a dark footer? The rules for compliant combinations in one region of your site may not work in another. With color-contrast, we can have the browser interpret from a list which text color is most compliant with its background color and apply it. Gone are the special overrides for special cases! I can't wait to experiment with this one.

Most helpful tips:

1. Don't stray too far from the document order: These days, with grid and flexbox, we can do a lot of position and flow changes without touching the HTML. However, that can make for a very disruptive experience for keyboard users and pose other challenges with assistive technology. If a change is so extensive it makes the keyboard experience jarring, or the screen reader order doesn't make sense, the source order should be adjusted in HTML.
2. Test, test, test: When implementing something new, or implementing something known using a new method, always test across different browsers using different assistive technology to make sure it's usable and consistent. If it's not consistent, then make sure the fallback is still usable and accessible, and think about the optimized version perhaps as a progressive enhancement.
3. Report browser errors: I never thought to do this, but if something is not testing or behaving as expected, don't assume browsers know about it. It may be that you have put together a new use case that breaks something they previously thought wasn't broken or flawed.

The State of Accessibility Report Findings

Speaker: Joe Devon, Diamond, Founding Partner

Joe was a very passionate speaker for the improvement of accessibility at every level, start to finish. He revealed some eye-opening numbers done from three years of testing that prove how badly automated tests can skew numbers, but also that the state of accessibility of top 100 sites isn't what it should be, despite recent improvements. Mobile testing also proved a huge drop off in accessibility after the top companies, which to me proves that unless it's being "paid for," it's not being thought about by nearly enough developers out there, or properly incorporated into development processes. As an industry, we need to work on shifting the narrative of only caring about accessibility to avoid lawsuits, but for a wide variety of reasons that are both good for the client and their users. For instance, building accessibility into a product automatically broadens the size of the audience it can reach. It also can reduce the number of complaints or bugs that are reported, which in turn saves the company money on having to remediate issues after the fact. That also means the general user experience is improved, which results in greater customer retention, positive review, etc. What's not to love?

Another point that stood out most to me was education. As far as building accessibility into our processes, this should be starting at the education level. Learning good semantics in school and through courses and having strong building blocks is essential, and sadly lacking in a lot of programs today. This extends to both designers and developers. Web designers should not only be taught about color contrast and accessible typography, but how to work with the different options and user preferences that are available, such as designing a site for dark mode, determining what the hover and focus states should be, and how the site would be adapted for those with certain motion or contrast preferences. The more we learn, the less back and forth there has to be and the better the end product.

We also need to advocate for a more clear mandate or directive from the government, specifically the Department of Justice. Much of the high-profile lawsuits over web accessibility in recent years come down to one thing: does the ADA apply to the web? The lack of clarity and specific wording means this gets decided on a per case basis in the courts. Obama's administration made progress on this but left it unfinished, and Trumps' administration scrapped it. It's not looking good that we'll get any clarity within the next three years under Biden's administration, though he has promised to work on it. In order for digital accessibility legislation to be a priority, we need to let the government know it's important.

Removing Bias with Wizard of Oz Screen Reader Usability Testing (partial)

Speakers:
Annabel Weiner, Ally Financial, Senior Inclusive Design Specialist
Courtney Benjamin, zendesk, Senior Accessibility Testing Process Analyst
Tim Harshbarger, Deque Systems, Senior Accessibility Consultant and Trainer

I didn't attend this whole talk (the original talk I wanted to attend had technical difficulties so I hopped on this one until they were resolved), but I thought it was worth mentioning what I did hear, which was a different way to go about screen reader testing using an actual person as a screen reader in early phases of a project. I just thought this was a unique experiment that they conducted, and makes the difficulties and differences that screen reader users face very real and tangible to designers and developers. I definitely plan on following up and watching the recording of this talk later!

Venturing into unmapped ARIAs

Speaker: Sarah Higley, Microsoft, Senior Software Engineer

After some technical difficulty, I was able to join this talk and learn about Sarah's process for creating complex new widgets that don't necessarily follow the norm. She had a good process that involved looking at existing similar accessible widgets with predictable patterns, looking at prior similar implementations on other sites or platforms, interpret the quality of your sources and consider the context of the other implementations vs. your own required context, and determine how to resolve missing functionality. She then walked through the steps with a complex file selection grid as an example.

If anything, this talk helped to validate processes that I and other RDG developers have used in the past. If we come across something complex, for example, a map that displays information when clicking on different states, we work together to figure out what the best experience for assistive technology should be. The first thing we ask ourselves is, "what's under the hood? What's really happening here?" Similar to Sarah's suggestion to look at existing known patterns, we were able to determine that while using a state map is cool for mouse or touch users, it doesn't translate well to keyboard accessibility. Imagine the monstrosity of that tab order! instead, we created a keyboard-only way for users to select their state (from a semantic, alphabetical select box) and handled appropriate screen reader announcements and transfer of focus to relevant information. Overall, as long as we talk it through and figure out the implications of one implementation method over another, we can come up with the most optimized experience for the greatest variety of audiences without sacrificing the "cool" elements of the original design.

Get It Right the 1st Time: Stop 80%+ of A11Y Bugs During Development

Speakers:
Glenda Sims, Deque Systems, Director, Accessibility Services
Jason Wilson, Deque Systems, Senior Product Developer

This talk ended up being a detailed and practical tutorial on using axe DevTools to test as you build. While the basics of this weren't new to me, they did cover an area of the DevTools that I hadn't previously worked with, called Intelligence Guided Tests that assist with manual testing of various aspects of your website. After the fact, I activated a trial pro account in order to further test these tools. What I found was that these tools not only helped to easily organize elements of testing into meaningful groups, but went beyond "this is wrong" to ask the question "does this look right?" That helps to review work with a more critical eye and make sure that things like semantic structure are what you intended, instead of just done in a way to prevent the triggering of automated errors.

I'll have to see if paying for an official pro account at the end of the trial is worth it, but at the very least I intend to take advantage of the tools while I have it to help guide and hone my own manual testing processes.

Making Content Usable for People with Cognitive and Learning Disabilities

Speaker: Rain Michaels, Google, Interaction Designer

When people think of building accessible websites, they often think of building for blind or deaf people, people with motor impairments, etc. Actually, people with cognitive disabilities are part of the largest disabilities group worldwide, with over 1 billion people having some form of cognitive disability. These include a wide range of things, like ADHD, dyslexia, old age, and many more. Even being so tired you can't focus on what you're doing is a temporary cognitive impairment. As we learned earlier, WCAG 2.1 introduced the first success criteria geared toward people with cognitive disabilities, and I expect more in WCAG 3.0. After all, many improvements that can be made for those with cognitive disabilities just improve the general user experience overall. I'll get off my soapbox now.

This talk was great, outlining that cognitive disabilities can include issues with attention, language, learning, memory, and executive function. She also went into the COGA (cognitive accessibility) document created by her working group, aiming to guide content creators, designers, and developers to create accessible content with cognitive disabilities in mind. I highly suggest visiting their Making Content Usable document and learning something new. I know I did! Rain included several personas and use cases in which we can create appropriate content and design that guides users through experiences with appropriate UI feedback and alternative offerings for those that process content differently.

Conclusion of Day One

Day one started strong and I loved hearing some new content from some familiar faces, but also seeing several new speakers as well. I've fallen mainly into design and development tracks which have given me a lot of useful tools already as well as things to try. I can hardly wait to follow up on new testing methods and incorporate more cognitive considerations into my own processes. We'll see what day two of the conference brings.