20160505_161337.jpg

Introducing Accessibility to Designers

Accessibility, UX

Accessibility is a critical and often overlooked portion of designs. Colors in a project may look nice at first but lack sufficient contrast, and become hard to read. A site may function correctly with a mouse while simultaneously being inaccessible to keyboard navigation. By considering accessibility throughout the design process, you are creating a better experience for everyone.

Research

Research

The WAI-ARIA Authoring Practices include information on visual and code requirements to create accessible designs. I reviewed these criteria and realized 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