A bit of background
ustwo is renowned for our focus on experiences that delight and empower our users. For over twenty years we have been delivering breakthrough experiences that work for everyone.
Our expertise in accessibility doesn't just come from work that is specifically designed to empower people with disabilities, although it does help: for example, via our work on Wayfindr we empowered vision-impaired people to navigate the world independently, and partered with the RLSB to define and publish an Open Standard for accessible built environments.
Everything we do at ustwo โ all of our work โ is designed and delivered to meet the widest possible spectrum of needs. We do this because we put our users first, and our users are as diverse as we are.
We hope that this article series will share with the world how we do this, the lessons we've learnt, and ultimately provide a blueprint for delivering accessible work that still delights, inspires and empowers.
Incontrovertible facts
First things first. Some incontrovertible facts about designing and building for inclusivity:
- When we design for inclusivity we improve the experience for everyone
- You can still deliver innovative and breathtaking experiences
- It is always better to design and build for inclusivity from the get-go
Our Inclusivity principles
We've created a set of guiding accessibility principles to help cross-discipline teams deliver breakthrough accessible work, distilled from our two decades delivering digital. Just like us, they are fun, playful... even somewhat sensuous:
- Level-up your gear
- Enjoy the patterns
- Think beyond touch
- Close your eyes
- Party party (test) party
In short, teams who expertly wield the best tools, follow tried-and-tested patterns and test regularly with keyboards and screen readers will deliver work that is inclusive and accessible to everyone.
1. Level-up your gear
Just use the tools. There is a wealth of accessibility testing tools (contrast checkers, checklists, simulators). We use them to ensure our work meets basic accessibility standards.
2. Enjoy the patterns
An accessible design pattern is a repeatable solution that solves a common accessibility problem. We know we're a highly original and unique creative mind โ but it's unlikely we're the first person to design form validation, or a tooltip.
3. Think beyond touch
Most users are happy with touchscreens and trackpads (and yes some of us still use mice). But it is essential we think beyond mice and touch. Using the digital products we build using only our keyboards allows us to determine if they are perceivable, operable, understandable, and robust.
4. Close your eyes
If the site is usable with a keyboard, there's a good chance it'll work nicely with a screenreader. But we won't know this unless we try it ourselves. Everyone on the project should learn how to use at least one screen reader, and regularly use the product with it enabled.
5. Party party (test) party
Testing the application for accessibility is not just the QA's responsibility. Get the team together and huddle around the product. Does it work on everyone's device? Where possible, we test with actual users/customers who have differing access needs!
This article series
Part two is a love-letter to HTML.
In parts three and four we'll see how we applied the principles to deliver a set of accessible React components on a recent project.
Part five will be all about the benefits to be found in an off-the-shelf component library such as Radix.
Beyond this, we hope to keep the series going with articles on form validation patterns, date pickers, and more.
We hope you enjoy your chance to come backstage with us and see how we deliver breakthrough digital experiences that work for everyone.
Now, onto Part two: HTML first: building accessible components
Please do get in touch with any thoughts, feedback or comments!