My Favorite Panels from AxeCon 2022

AxeCon is a free digital accessibility conference put on by Deque Systems. I attended AxeCon for the first time in March of 2022, focusing on panels related to web components and design systems. In no particular order, here is an overview of some of my favorite panels from AxeCon 2022!

How a Developer Can Break Your UI Component Library’s Accessibility, and What To Do About

Speaker: Beth Qiang (Software Engineer at Lob)

Session: https://www.deque.com/axe-con/sessions/how-a-developer-can-break-your-ui-component-librarys-accessibility-and-what-to-do-about-it/

Beth Qiang gives an excellent overview of the challenges of building an accessible component library from the perspective of both component authors and consumers.

Take-aways:

Strike a balance between allowing composition through slots and relying on props. Composition is more flexible, as consumers can pass whatever content they wish into a component, but it can require more work on the consumer’s part to ensure accessibility.
Make sure consumers can pass screen reader accessible labels into components.
Document what accessibility features the components have and how to utilize the components in an accessible manner.
Accept that there are some things you can’t prevent developers from doing incorrectly (You can’t stop a developer from skipping header levels, for example)
Page accessibility tests need to be performed in addition to testing individual components. Accessibility can’t be thoroughly evaluated in isolation.

New CSS with Accessibility In Mind

Speaker: Rachel Andrew (Technical Writer at Google)

Session: https://www.deque.com/axe-con/sessions/new-css-with-accessibility-in-mind/

Rachel reviews accessibility concerns to keep in mind while leveraging newer CSS technologies like flexbox, grid, container queries, and subgrid.

Take-aways:

Use normal document structure-based flow as much as possible instead of using CSS to control ordering.
Always test tabbing order within grids to make sure it flows as expected
Make sure that changing an element’s display type doesn’t disrupt or invalidate how the element is reported to accessibility technology. (For example, using display: grid instead of display: table or a semantic table tag on a container element that is actually a table)
Using display: contents on an element causes its children to be promoted as direct children of the element’s container for the purposes of flexbox. This can be useful for maintaining semantic structure inside flex containers.

Venturing into Unmapped ARIAs

Speaker: Sarah Higley (Senior Software Engineer at Microsoft)

Session: https://www.deque.com/axe-con/sessions/venturing-into-unmapped-arias/

Sarah’s talk explores how to approach building an accessible custom UI component that falls outside existing semantic HTML and ARIA patterns. She covers the process of of researching potential solutions, reviewing usability studies, and running user tests.

Take-aways:

Start by reviewing existing accessibility “maps”, including ARIA and accessibility specs, and a11y blogs and websites.
Research existing solutions through accessibility documentation for existing frameworks with similar UI components to the one you’re trying to build. Keep the context of your sources in mind and compare different sources when deciding what to pull from.
Identify what information you are missing after performing research, particularly when what you are building is a hybrid of several established patterns.
Break down your component into parts and identify ARIA roles that meet your needs. If a pattern isn’t supported, consider proposing a revision to the ARIA specs themselves! (For example, Sarah opened an issue concerning secondary widget roles)

Building Accessible Design Systems - Try, Try, Try Again

Speakers: Daniel Henderson-Ede (Senior Accessibility Designer at CVS Health); Meghan Morris (Senior Accessibility Designer at CVS Health)

Session: https://www.deque.com/axe-con/sessions/building-accessible-design-systems-try-try-try-again/

Daniel and Meghan give a compelling (and humorous) account of their efforts to launch an accessible design system at CVS Health.

Take-aways:

Naming is important, and each potential name for a component comes with its own expectations. When deciding on a name, you should consider not only the user experience, design, and potential semantic meaning, but how the name will be interpreted by all stakeholders.
Start by defining component scope, and categorizing components into logical groups
Narrow your scope as much as possible while maintaining a good user experience. Avoid worrying about use cases that may need to be added in the future so you can focus on the accessibility of current uses.
Platform parity doesn’t exist. Rather than aiming for consistent components across all devices, aim for parity between your app’s user experience and your user’s device. Consistency doesn’t have to mean the exact same appearance across all platforms.
Document how your components are meeting accessibility guidelines. If engineers aren’t trained in accessibility, and aren’t given documentation of the efforts and experts involved in making a component accessible, they may not be aware that accessibility concerns have been addressed.

Modern CSS Upgrades to Improve Accessibility

Speaker: Stephanie Eckles (Software Engineer at Microsoft)

Session: https://www.deque.com/axe-con/sessions/modern-css-upgrades-to-improve-accessibility/

Stephanie explains how modern CSS features can help improve the accessibility of layout, focus state, zoom reflow, and more, and how these work towards satisfying WCAG criteria.

Take-aways:

Using CSS custom properties to describe the size, style, color, and optionally offset of a focus outline on interactive elements can provide a basis for rendering a focus indicator, while allowing low-effort overrides for specific cases. (Such as having the focus indicator appear inset on button elements)
CSS functions like max can be used to allow outlines to scale with elements while maintaining a minimum width to ensure accessibility.
Modern browsers may only show focus indicators for the :focus-visible state, which is only reached through keyboard tabbing, unless you have defined your own styles for :focus states.
Be mindful of altering focus order with styling through absolute, fixed, and sticky positioning, grid cell placement, and order properties within grid and flexbox. Consider reordering your HTML source instead of relying on CSS to keep visual and focus order aligned.
Be aware that supporting zoom reflow differs from responsive design. The goal is to re-arrange and not to remove content and functionality, and targets desktop users.
Leveraging CSS functions like min and clamp along with vh and vw units can allow you to define spacing between sections that remain appropriate across zoom levels.
User motion and color contrast preferences are available via media queries such as prefers-reduced-motion.