Accessibility for Designers
accessibility · 2017
Introducing accessibility thinking to the design process.
Accessibility is a critical and often overlooked portion of designs. The WAI-ARIA Authoring Practices offer in-depth information on how to create accessible designs. This information is beneficial, but I noticed that the technical nature of the language was overwhelming to some readers and implied a steep learning curve.
A color palette may look beautiful to the designer, but the contrast of the text to the background could be hard to read. A product may function as intended when using a mouse, but inaccessible to a keyboard navigation. It’s possible to go back and fix these issues, but they should be considered about from the beginning.
Accessible designs create a better experience for everyone.
The WAI-ARIA Authoring Practices include information on visual and code requirements to create accessible designs. I reviewed any requirements about the front-end visuals and copied these into a new document. From there I began my research on each one individually. Some accessibility requirements could be handled in the initial design phases, while others need to be kept in mind while the product is under development.
I wanted more context to understand how design and code worked together so I could better communicate the requirements to designers. Thankfully, there was a talk at Google I/O 2017 that did just that. I found the Pragmatic Accessibility talk by Rob Dodson to be incredibly insightful. I began to seek out implemented examples of the requirements and describing them in simple language.
I set out to create a quick and simple reference for both designers and developers with the goal of accessibility becoming part of everyone’s workflow. The UI-Accessibility document is both a guideline and an educational document to achieve that goal.
I started thinking about how the product sounds for screen readers, feels for keyboard navigation, and then how it looks. Creating an accessible product means more considerations to design for, but the result is a design that is better for everyone.
I grouped the requirements under a “Design” heading or “Annotations” heading. “Design” requirements can be taken care of early in the design workflow and mostly rely on the visual design like the color palette, labels, or important images. “Annotations” get into the functionality of the design. These items relate to the functionality of a component such as keyboard accessibility, screen reader labels, or the proper semantic elements. Both sections include links more reading and examples that provide a deeper understanding of the requirements.
The UI-Accessibility document also includes many resources I have found helpful in my research and in designing for my work. Some are technical documentation, and others are more casual writing on the subject. I encourage everyone to look through the readings, watch the videos, and play with the tools to see what accessibility means for your designs.
I wrote this list in a way that makes sense to me and I want to hear from you! Does this help you understand what you need to be doing? Did I miss something? Is there a resource you reference all the time? I put this up on GitHub for a reason! Head over there and let me know!
View the project on GitHub: UI Accessibility