mailwal

The Intersection of Design and Development for Accessibility [5/6]

Marcy Sutton
Hey, there!
There is only so much one can fix with code for accessibility. Slapping ARIA attributes and JavaScript onto an interface won't necessarily make it usable to people with disabilities because accessibility needs to be considered much earlier than the development and testing phases. As a developer, you can and should build up your knowledge of accessible patterns and best practices to apply efficiently in your work. It's also important to identify design issues for accessibility as early as possible and gather feedback from people with disabilities to counter your own biases.
This email will focus on the intersection of design and development for accessibility. It includes tips for evaluating a design for issues and identifying barriers to access before writing code. You'll learn how to create prototypes for accessibility as part of your development practice and test for viability of design implementations quickly and pragmatically.
Accessibility is heavily impacted by UX and design
There are a couple of comparisons that could help to understand how design and accessibility relate to one another. First, accessibility is like blueberry muffins: you wouldn't make them by shoving the berries in after baking (paraphrased from Cordelia McGee-Tubb). You also wouldn't "take a condemned home and put new siding on it to successfully pass building code" (Shell Little).
The most inclusive websites and web apps consider accessibility as part of the design process (and earlier, such as in requirements gathering). This is often referred to as "shifting left", where the responsibility for accessibility isn't left to developers or QAs to identify and fix alone. Keeping this ideal process knowledge in mind can be helpful when working with your colleagues in different disciplines. As a developer, you shouldn't be on your own to implement accessibility–even though it happens quite often.
How to evaluate a design for accessibility issues
Ideally, accessibility would be considered long before a design lands in your inbox for code implementation. Sometimes it happens, but often not. No matter the attention paid by your colleagues, the moment a design becomes known to you is a great time to identify accessibility challenges: up front, before writing code.
Your "spidey senses" should go off for accessibility any time you build a User Interface, but particularly for any interactivity or content structure. For example:
  • Anything a mouse user can do, a keyboard user should be able to accomplish as well (sometimes with an alternative function, or "affordance"). Keyboard support has the added benefit of supporting assistive technologies quite often, making it a base requirement for any interactivity.
  • Visual treatments should have enough contrast and not rely on color alone. This applies to links and text over backgrounds, data visualizations and legends, and product color pickers in e-commerce. Use underlines, text labels, and patterns along with colors that meet WCAG contrast requirements.
  • Designs could annotate accessibility information for non-visual mediums like screen readers, such as suggestions for semantics/structure and alternative text for images. This could note intent for markup like headings, links, or buttons; ARIA roles and widget patterns; focus/tab order; and responsive/flow details.
  • Motion, animation, and autoplay can make people sick and should be employed responsibly. Have conversations about necessary movement in designs to determine the most accessible ways forward that respect humans. You can also use the prefers-reduced-motion CSS media query.
The more accessibility information and user intent provided with visual designs, the better. Figma tools like Stark and the Accessibility Annotation Kit could be helpful recommendations for the design process, preventing teams from having to "shove blueberries in" later. Collaborate with your UX/visual designer colleagues on accessibility and annotate designs together, if necessary. Keep an open dialogue and mind, while encouraging accessibility to be a core part of the process.
Coding prototypes for accessibility
As a front-end developer, one thing you can do is create prototypes with code to test out design implementations quickly. Your exact role may depend on your organization's size, but you still shouldn't shy away from prototyping in your own development process. Prototypes can save time and money overall by causing less guesswork in development, especially when working with a design team. You may determine through code and basic testing that tweaking a component slightly could make it much more accessible, allowing you to provide feedback to the team in a rapid cycle.
You could play around with one widget or section of a page to test out accessibility, say for a responsive megamenu or inline form validation. CodePen is a great environment for creating and sharing web UI prototypes with minimal setup. You can also use Parcel as a lightweight bundler and prototype JavaScript app components, trying out various open source packages for their built-in accessibility. Testing things out in this way can change the trajectory of a project!
Responsive design and accessibility
Just as accessibility can be more successful when prototyped early with UI code, so can responsive design. As you write HTML, CSS, and JavaScript to bring a design to life, testing it in multiple viewport sizes and contexts can shape the necessary code structure and lead you to make implementation decisions that carry forward in the project. Perhaps you'll formulate your markup for a component a certain way for an accessible responsive design, because you tested for keyboard accessibility on multiple screens right away.
Implementing a design to work well in one responsive column can also be helpful to people with low vision and other disabilities who zoom in and/or need fewer distractions. There's a reason why people sometimes prefer mobile websites offered by retailers and other places online: they're streamlined, simplified, and easier to use. Doing responsive testing throughout the development process can ensure your site is usable to people on mobile devices, in any context. HTML is laid out in a single column before CSS is applied, after all!
Embedding accessibility into pattern libraries
UI implementations in pattern and component libraries are great places to bake in accessibility. Demos could show best practices and how things should be implemented accessibly. Everything from headings to custom widgets would benefit from an accessibility point of view, to iron out issues early with accompanying automated tests. A pattern library can provide a great place to collaborate on accessibility and make code contributions. Examples of accessible pattern libraries can be found on DigitalA11y.
Honoring the U(ser) in UI development
As a technology professional, you are not the user (typically). You create experiences for people to use: people who are not in front of you interacting with a page. It is important to foster humility in your work and seek feedback from people with disabilities to determine whether something is actually accessible. Working with testing groups like Fable and Access Works can help your team gather feedback and learn how to develop more inclusive sites and apps. You can move past your own biases and assumptions and build things rooted in an accessible user experience.
User testing may not always be an option for your team, but user-centered design is still something to strive for. Honor the phrase "nothing about us without us" while designing for accessibility, seeking feedback from people with disabilities as much as possible. If you center and factor in their perspectives, you'll make more inclusive products.
Until next time,
Marcy Sutton
P.S. There's only one more email left in this series! Click to answer a quick question, and I'll send it over.

130 Nickerson St. Suite 207, Seattle, WA 98109