axe-con 2023: Day Two (Ashley)

Day two, currently bright-eyed and bushy-tailed! We'll see how I feel by the end of the day. In the interest of unique article write ups, if you're still with me after reading my write up of day one of axe-con, I salute you. I won't be sharing my thoughts on the first keynote on the day, since Riley will be covering it in her article. All I'll say was it was emotional! (See Riley's day two axe-con article if you're curious). Without further ado, here's my take on the talks I attended on day two of axe-con 2023!

Accessibility Beyond Code Compliance

Speaker: Aaron Gustafon, Microsoft, Principal Accessibility Innovation Strategist

I don't know what I was expecting from this talk based on its title and the fact that it was part of the development track of the conference, but it was surprising, to say the least. Aaron Gustafon is a known figure in the development space, and it was refreshing to see his encouragement for how accessibility devs can take advantage of opportunities in different areas to help foster growth and change. He discussed five different areas, though as we all know, there are many more, and depending on the size of your organization, can overlap. 

• Design systems: If you work in development, your organization may have its own system, or you may rely on other ones in your work. Either way, we can be working to ensure design systems are built accessibly and also reduce the chances of being used and changed in a non-accessible way. Pair programming with people that work on components of the design system is another way to help make sure that knowledge is transferred and the final product is what it should be.
• Product design: We heard the "shift left" mantra here yet again. If you work for (or are looking to work for) a company that does product design, guiding the design process and giving feedback early and often can help set your projects on the right track and make sure the final product doesn't have barriers and actually addresses a real need.
• Analytics/data analysis: This can span the gamut from user research to accessibility testing and bug-fixing. I know that RDG could use a better, team-wide view of existing accessibility issues, but also new ones that are introduced and how long it takes to fix them, or if there are ones that are marked as "won't fix." Some more sophisticated tooling in the offing? We shall see.
• AI: We should work not to make the same mistakes that voice recognition did, where they focused on only narrow dialects of English, and didn't account for the plethora of accents that exist in the United States, people for whom English is a second language, etc. Aaron brought up a cool example here of an initiative that is trying to approach a similar helpful tool in a way that is helpful to everyone. There is an image recognition software that uses AI and machine learning to build up its database by having blind people take images and short videos of objects. That way, it doesn't just get crisp, well-centered images, but images that are taken by someone who maybe can't tell if part of the object is cut off or the camera lens is out of focus. That way, blind users have a greater chance of being able to point their camera at something and have it accurately tell them what it is. Pretty cool, huh?
• Diversity & inclusion: As always, we should work not only to recruit people from diverse backgrounds (both to work with and for testing and research), but we should work hard to make sure our environments are ready to accept them. If your culture isn't a safe and supportive place for people with diverse backgrounds, they will leave.

So let's advocate in all areas! As if we don't have enough to do already, ha ha. But if we're pairing, training, and mentoring, the load won't be so heavy.

The Successes and Challenges of the Irish Government Accessibility Monitoring System

Speaker: Dónal Rice, National Disability Authority of Ireland, Senior Standards and Monitoring Officer—EU Web Accessibility Directive

Knowing we have some projects in Ireland and other countries that are part of the EU, I was curious about what they were doing to monitor and report on accessibility. What they've done is something I'd love to start doing on a smaller scale. They choose a collection of websites,  for "simplified monitoring," on which they conduct automated testing on a high volume of pages. For these, they use axe-core, with 57% coverage of WCAG success criteria. Then they choose a smaller set of websites to conduct in-depth reviews on a narrow collection of pages, but with more thorough automated and manual testing to cover 100% of WCAG success criteria and requirements set forth by the EN 301 549. These results are then made transparent and reported to the public bodies in question, so they can do what they need to do to improve their accessibility to comply with the directive. If we could do more wide-scale simplified monitoring, I would be one happy camper.

One of the requirements is something that not enough websites in the States do. Let me say it loud and clear. You need an accessibility statement on your website. One to be compliant in the EU. But even if you don't do business there, you need one anyway. This is a simple matter that's easy to do, too. There are even accessibility statement tools and templates out there for you to use. What they usually boil down to is a short explanation of what type of measurements you are using for compliance (ex. WCAG 2.1 Level AA), and some ways that users can contact you to report accessibility issues. Which would you prefer, a disgruntled email, or a lawsuit? I know which one I'd choose.

It was great to hear about the benefits of the monitoring system the National Disability Authority (NDA) in Ireland has already had in such a short time. There is greater awareness and relationship building, issues are getting fixed, and the responsibility has trickled down into the design and development agencies so they're producing better work too, even outside of public bodies. Just goes to show how powerful monitoring can be.

WCAG 2.2 and 3.0 Update

Speaker: Wilco Fiers, Senior Accessibility Engineer, and Melanie Philipp, Director, Services Methodology, both of Deque Systems

I'm always eager to see what's happening with WCAG. Unfortunately, for something so widely used and with a huge burden of responsibility placed on it, that means the working groups and task forces that shape these guidelines make slow progress, because they want to do it right. But there are some exciting things on the horizon! WCAG 2.2, which we've already seen around for at least a couple years, is projected to become the official recommendation later this spring. Huzzah! WCAG 2.2 has nine new success criteria, primarily aimed at keyboard navigation and mobile. Melanie did mention that 2.4.11 Focus Appearance might be changed or even struck altogether from 2.2. I really hope that's not the case since I've seen issues with focus getting "lost" far too often due to issues with contrast or barely noticeable change between the resting state and focused state of an element. However, I concede that the criteria as written is not the easiest to understand. Let's vote for change, not removal!

WCAG 3.0 has also made some progress in the last year, but it's still far from complete. So far, in fact, they're no longer trying to put any type of estimate on when it will replace WCAG 2.x as the recommendation. However, between now and 2025 they intend to finalize the foundational work for WCAG 3.0, which will hopefully make all of the work in the individual areas happen more quickly. By foundational work, I mean the ways in which WCAG 3.0 will be organized, how websites will be tested, graded, etc. It will be a huge departure from WCAG 2.x for a variety of reasons, most of which I think are good. Here are a few ways that 3.0 is going to change how we look at digital accessibility:

• Different levels of "passing" instead of pass/fail: While there will still be some issues that are considered critical and would make your website "fail" a compliance check, not everything will be passing or failing anymore. Instead, 3.0 seeks to measure how well the site does a particular something, with three levels of passing. These will be bronze, silver, and gold, and will not be direct equivalents to the Level A, AA, AAA that we see for levels of conformance. Rather, each guideline will have these three levels of passing. This was done to be encouraging as much as to give a more accurate picture of a website's accessibility.
• Success criteria will become outcomes: Again with the reframing of pass/fail, this shifts the idea of how something is done to the end result. In the end, we don't want to just tick off boxes. We want the outcome of our work to be accessible, usable, and, dare I say, delightful.
• Understandable: Funnily enough, "understandable" is the "U" in POUR (Perceivable, Operable, Understandable, Robust) by which WCAG 2.x organizes its success criteria. Except that it's written in such a way that it can be difficult to understand the criteria at all, let alone know how to implement it correctly! They were written that way for a purpose, mainly so that they could be specifically testable and within a certain scope, but the result isn't exactly user-friendly. Some of the WCAG 3.0 examples shared by Wilco were already written in simple, clear language, which makes it not only easier for designers and developers to understand but also makes it easier to share these guidelines with clients so they can better understand their impact.
• Testing the untestable: As mentioned previously, WCAG 2.x is centered around a set of clearly testable criteria. But what about more intangible elements of accessibility, such as whether an interface is easy to understand, or whether too much jargon is being used? This is one thing that they hope to tackle in 3.0, and I'm excited to see what they come up with.
• Accountability: There are already some types of documents out there, such as the VPAT, that outline what's been tested, what passes, and what fails on a website. But WCAG 3.0 wants to take this one step further, and introduce the idea of "Assertions," in which websites would have to provide the person or organization responsible for accessibility, the description and scope of procedures for testing/compliance, and a contact method to report issues. This can be scary or not, depending on who you are. We'll see what this looks like as it takes shape, but to me, foundationally having an accessibility statement already gets you part of the way there. Those with VPATs are even closer.

So, while WCAG 3.0 is still years away, and when it finally does launch will not immediately replace 2.x as the standard, we should definitely keep an eye on its development and see what we can do to fall in line with it early, instead of playing catch up later.

GitHub Accessibility: Bridging the Disability Divide through Code Collaboration

Speaker: Ed Summers, GitHub, Head of Accessibility

This talk explained disability in a way I don't think I've ever heard before. At least, not in such a clean and distinct way. He pointed out that disabilities aren't inherent to people. He used this equation, which is just beautiful:

impairments x barriers = disabilities

As with all math, if you multiply something by zero, you get zero. Therefore, if we have zero barriers, then people with impairments can participate in our culture and society, the same way as people who may not.

Ed Summers also said that it's important to develop your own accessibility principles, so you can use them to guide your work. He was nice enough to share his with us:

1. Everyone deserves the opportunity to participate.
2. Disabilities are not inherent to people (again, see the math equation).
3. We all have the power to prevent disabilities.
4. Technology is a disruptive force for inclusion AND exclusion.
5. Progress trumps perfection.

I have to say, those all resonated with me, and I'll be thinking about defining my own principles.

GitHub also has some cool projects that will help people with impairments with code that were really cool. One is GitHub Copilot, which is an AI pair programmer that helps make code suggestions to screen reader users. They're also working on Hey GitHub, which is another form of AI pair programmer, but with voice control. It's great to see steps being made to remove barriers for people with vision or motor impairments so they can work in the tech space!

One of the last things he showed us was how people were working with a young gamer named Becky on eye-tracking software, EyeMine. Becky has motor impairments, but that didn't stop her from collaborating with a developer through video calls to make improvements to the software relevant to coding games, so she can do what she loves more efficiently. Something great to see that would be awesome if we saw happening everywhere!

Supporting accessibility in React: the difficulties and niceties

Speaker: Diane Ko, Etsy, Staff Software Engineer, Accessibility

Note to self: have a cup of coffee before attending a technical talk near the end of a conference. I haven't worked in React lately, so my brain had to think for a minute to think about how the principles Diane outlined could be used in other frameworks (I've been pretty deep in Laravel land lately). Luckily for me, her points, while React specific, had applications in almost any composable framework. To generalize the talk a little, I'll share her niceties and difficulties more in terms of any composable framework:

Niceties of composable frameworks:

• Component reusability: I mean, it's in the name, right? When you build a set of components and "compose" them on your different pages, you can make accessibility improvements in one place that have a large impact, instead of having to remember how to "do it right" each time you need to print some type of element, form, etc.
• Prop enforcement: An example of a prop in React would be having a `Field` component that accepts `labelText`. React props have the nicety of being able to declare not only what a prop is, but what type of value you can pass through (ex. labelText would accept a string) and whether it is required.
• Using logic within HTML: Error messages in forms were a great example that Diane used. Error messages may or may not be there, but if they are you want them to be consistently placed and styled. You can wrap a condition around the error message so that it only prints if an error message exists. I just did the same exact thing in a Laravel blade component!
• ID generation: There are a variety of ways that this can be done, from passing a prop to actually writing a function to generate unique IDs. Since complex layouts like a grid of cards, accordions, or a long form all rely on appropriate programatic relationships, unique IDs is a must for a navigable screen reader experience, and who wants to have to think about that every time they build something?
• Variable elements: This one turned me a little green with envy. I'll have to figure out a way to do this in Drupal. Basically, Diane walked through a neat example of how you could inform the heading levels within a component based on where you place them within a page. I can't tell you how many times I've built a block with the correct heading level, only for it to be placed in a second location where it no longer followed a logical heading hierarchy. Oy!

Difficulties

• Accessing DOM elements of other components: As Diane pointed out, React components by nature aren't made to be aware of the state of other components. However, you can build the ability to inform a parent component of the state of something in the child. It just takes some additional work.
• Knowing where a component might be used: Tied to the idea of variable elements, you might build a component that works in a particular place but has issues out of context. There are two paths here: One, take the time and effort to make your component variable to work for potential future contexts, or two, don't make it variable and wait until it's used inappropriately to make the necessary parts variable. Potentially a lot of work for nothing, or introducing accessibility issues, take your pick.
• Deciding between strict or loose prop definitions: This one is a bit more React specific as well, but Laravel has something similar with `$attributes->merge`. Basically, will you allow the attributes of a component to be overridden when they're placed, or only let them pass through what you've defined? Strict can be safer, but you may prevent someone from adding an attribute they need to add, so you'd have to do more upfront work to try and define all the possible attributes. Loose props let you override and add new props as needed, but opens up the possibility for it to be done incorrectly.

Mega-Accessible – Mega Menus

Speaker: Stephanie Andrecovich, Accenture, Front End Development Specialist

I wanted to attend this talk for a couple of reasons. One, to see whether or not our current mega menu patterns were up to snuff, and two, to see if there's anything new that we weren't aware of. I ended up loving the structure of this talk. Mega menus are often a big colossus of confusion, but Stephanie made the different patterns really clear, as well as their impacts on assistive technology. I spotted some things that we could simplify in some areas too to make sure we're following the patterns correctly! Here's a list of the three patterns she described:

1. Disclosure navigation bar: This pattern treats the top level navigation as buttons that open submenus (PSA: top level navigation should NOT open submenus AND go to a different page. Links go somewhere. Buttons open things. End of story). Users need to be able to tab through top level navigation, open it, and navigate the sub navigation. This is the simplest of the three, and, in my opinion, the cleanest. However, the second pattern helps appease the folks that insist on having top level navigation go somewhere and open a menu (hint: it still won't).
2. Disclosure + link navigation bar: This pattern has top level links that take you to a page, which then have arrow buttons next to them that open the submenus, programmatically labeled by the top-level link text. So does it allow top level navigation to have links instead of just buttons? Yes. But does it allow you use the link both as a link and as a submenu nav toggle? Absolutely not. Personally, I find this pattern clunky, but that's just my opinion.
3. Application menubar: There are certain roles that, when introduced, are promising screenreader and keyboard users that the menu navigation will behave the same way as navigating your OS navigation. If you don't strictly follow all of the ARIA and keyboard patterns (which are far more extensive than the other two patterns), you risk a broken and confusing experience. You may even have a confusing experience if everything is done correctly, because some screen readers like JAWS may automatically enter "application mode" when navigating these menus, which is not a typical mode used when within a website.

All in all, I was very happy with this talk, both for the clarity it offered and the details on implementation. I'll be checking on our menu implementations as I go, for sure!

Conference Conclusion

This lady is burnt out. But chock full of new information, inspiration, and motivation! Definitely saw the themes of "shifting left" and changing our perspective of how we view accessibility and people with disabilities. I'm excited to help keep things moving forward in this field.