Embedding accessibility and inclusive design throughout the product life cycle is a little like giving up smoking, said Leonie Watson, director of TetraLogical, a London-based inclusive design agency. Everybody knows it’s the right thing to do, but it seems almost impossible until you summon the will.
Today, a growing number of companies are focused on inclusive design as a matter of legal compliance and ethical obligation, Watson said. Few are integrating best-practice guidelines at all stages of product development, however.
Watson, who is a member of the W3C Advisory Board and co-chairs a Web Platform working group that contributes to the Web Content Accessibility Guidelines (WCAG) and the Accessible Rich Internet Applications (ARIA) specification, is working to change that. Her team at TetraLogical co-authored a set of Inclusive Design Principles aimed at giving design and development teams a framework for thinking about the needs of people with disabilities.
The UK-based software engineer, who speaks and writes frequently on accessible design, fell into the specialization somewhat unexpectedly. She lost her sight to diabetic retinopathy in 2000 after working as a web designer for many years.
After taking several years off, she began to use a screen reader and joined online forums to educate herself. One day she answered a query from Alastair Campbell, director of accessibility at Nomensa, a UX design agency that was seeking screen-reader users to provide feedback on a new web design. After a few successful contract jobs, they brought her on full time.
She went on to consult for the UK’s Government Digital Service, an agency tasked with revamping the nation’s online public services, and worked for the software accessibility consultancy The Paciello Group, before launching TetraLogical.
Collectively, these experiences have given her a rare insight into the procedures and tactical decisions involved in designing with accessibility front of mind. We spoke with her about how teams can adapt their processes after a recent presentation Accessibility and Inclusive Design in the Production Lifecycle at Kin + Carta’s fwd2o.
Choose to Act
- Change your attitude. Tell yourself you’ll do it.
- Adopt a policy-driven approach.
- Make it reality, not a fantasy. Allow six months to three years for a full transition.
- Conduct a cost-benefit analysis.
Choosing to commit to accessibility and inclusive design practices is the first step — and often the most intimidating. One of the most significant hurdles to organizational change, Watson said, is fear among executives and senior managers that the transition will require substantial upfront investment.
This is not entirely untrue. However, when accounting for the legal, public relations and commercial costs of inaction, the business case for incorporating accessibility standards and procedures into the product life cycle is well supported by research. The Click-Away Pound Report 2016 prepared by the UK disability and diversity consultancy Freeney Williams, for instance, found that:
- “71 percent of UK internet users with access needs (4.3 million people) will click away from a website that they find difficult to use.”
- “Those customers who click away have an estimated spending power of £11.75 billion in the UK alone, around 10 percent of the total UK online spend in 2016.”
- “82 percent of customers with access needs would spend more if websites were more accessible.”
Though the report does not spell out a specific timeline for return on investment, it does estimate the additional cost of building accessibility into a new website at “around £5,000 per site” — a relatively modest amount when assessed against the potential gains.
The economic case is further supported by Inclusive Design and the Bottom Line, a paper presented by a group of Cambridge researchers at the International Conference on Universal Access in Human-Computer Interaction. The authors provide a cost-benefit model that quantifies captured value as a function of increased sales and increased productivity, the latter resulting from “less rework, fewer support calls, and enhanced user learnability.”
“If you invest in putting the right kind of plan in place, there is a financial cost upfront, but what you get back is [a developer’s] salaried time.”
Moreover, they argue that “an intuitive user interface design, as shown with the Apple’s iPhone and iPad, may be the unique selling point” that leads to “increased customer advocacy” and “a ‘viral’ effect in the uptake of the product.”
Companies like Uber and Transsion Holdings also have leveraged accessibility-focused design frameworks to capture new customers and improve their interfaces, as reported by Built In in an earlier story.
Taking a more restrained approach to inclusive design — doing just enough to achieve legal compliance — may seem fiscally prudent until you start to unpack the hidden costs.
“A developer can be spending up to 40 percent of their time fixing accessibility problems,” Watson said. “If you invest in putting the right kind of plan in place, there is a financial cost upfront, but what you get back is all that person’s salaried time.”
Define Policies and Procedures
- Identify skills gaps and address them through staff training and recruitment.
- Employ tooling that can run automated accessibility checks.
- Form a champions network of UX designers, product managers and developers to lead the transition.
- Integrate accessibility and inclusive design standards into product requirements documents, user research, user stories, acceptance criteria and design notations.
- Give individual employees the time, responsibility and authority to achieve results.
Formalizing policies and processes is crucial. If you want your organization to adopt accessible and inclusive design practices, Watson said, it’s a good idea to state those goals explicitly in an organizational statement.
“It doesn’t have to be War and Peace,” she said. “Just something that says, as an organization, here’s what we’re going to do, how we’re going to do it and by when.”
After that, things get trickier.
“Essentially, what you want to do is look at your production lifecycle, and work out how and where to slot accessibility into it. So you’re dealing with it in small chunks, all the way through the production pipeline, not in one big scary blocker at the end,” she said.
Specific steps vary depending on the size and methodology of the organization, but there are common threads.
One aspect of workflow integration is staff training. Earlier this year, as reported by Built In, the World Wide Web Consortium WC3 launched an online course on web accessibility covering the use of screen readers, semantic markup of HTML, keyboard navigation and audio transcriptions. The framework for the course — taught largely through demonstrations rather than recitation of guidelines — is one Watson recommends.
Tooling also needs to be woven into the development approach, she said. Free browser extensions, the audit panel in Chrome DevTools and services like webhint.io offer informal accessibility audits for locally stored web pages.
“Essentially, what you want to do is look at your production lifecycle, and work out how and where to slot accessibility into it. So you’re dealing with it in small chunks.”
For a more systemic solution, however, Watson recommends investing in fee-based services with application program interfaces (APIs) that can define conventions across multiple software applications such as the Web Accessibility Evaluation Tool (WAVE) or The Paciello Group’s ARC platform. These services can run automated checks as changes are introduced to the codebase; however, they typically only catch 30 percent of potential issues, Watson said.
While catching all issues may be nearly impossible, integrating accessibility standards into the production cycle — in product requirements documents, user research, user stories, acceptance criteria, design notations and metrics of success — can help close the gap.
Forming a champions network of UX designers, product managers and developers is a good way to drive these changes, she said.
Often, progress happens in baby steps, with workflow protocols that place responsibility on individual employees. For a creative designer, that might mean using WebAIM to check color swatches for contrast levels. For a content designer, it might mean using a tool like Hemingway to check the readability of a document. For a developer, it might include testing a new feature with a keyboard to make sure it’s serviceable without a mouse.
“They’re all things that take, maybe, 30 seconds, a couple of minutes,” Watson said. “But if you get into the habit of doing those every day and fixing what you find, you start making small but pretty decisive steps in the right direction.”
Gather Insights From Your Target Audience
- Include people with permanent, temporary and situational disabilities in usability testing.
- Craft user stories around those in your target audience with accessibility limitations.
When it comes to user research, it’s important to include people representing a range of disabilities and accessibility considerations. Recruiting internal volunteers or external participants through email or social networks can be a good starting point.
“Look within your target audience,” Watson said. “You can take it on faith that a significant chunk of people will have a permanent disability of some description. Put out an appeal and offer something [like a coffee] by way of a thank you.”
Usability testing should include people with temporary or situational disabilities, as well — an individual who has broken their arm and can’t operate a mouse, for instance. Casting a wide net will help ensure web and mobile experiences are better for all users, not just those with the most acute or longest-term disabilities.
“Color contrast is great for people who are partially sighted. It’s also great for anyone looking at a touchscreen outside in sunny weather.”
“Color contrast is great for people who are partially sighted,” Watson pointed out. “It’s also great for anyone looking at a touchscreen outside in sunny weather, which, even in the UK, we have from time to time.”
Later in the development cycle, Watson recommends crafting user stories that identify and document the needs of those with disabilities, as in: “I’m a blind person, I want to [take this action]. The reason is because of [x],” she explained. This will help designers and developers create more accommodating and equitable user interfaces.
Lead a Culture Shift
- Treat accessibility and inclusive design as a matter of professional pride.
- Identify and recruit candidates with accessibility and inclusive design experience.
- Honor outstanding employee contributions through formal and informal recognition.
- Getting serious about accessibility and inclusive design means going beyond audits and assessments, or the optics of a quarterly report to a board of directors. It requires a fundamental shift in an organization’s culture.
“You need to stop people from thinking of it as an extra burden,” she said. “And get them to think about it as a matter of professional pride.”
That begins with direction and support from the top, she said. Recruitment teams need to be brought into the conversation to lay the groundwork for how an organization can actively seek candidates with experience working on accessible interfaces. Product managers need to be given the authority to budget additional time into the development pipeline, particularly during usability and QA testing. Employees who are doing an exceptional job implementing accessibility standards need to be recognized for their contributions.
“You need to stop people from thinking of it as an extra burden. And get them to think about it as a matter of professional pride.”
Of course, none of this happens overnight. TetraLogical spends years working with brands like Herbal Essences, Coil and Babylon Health to help them improve the accessibility of their online services. The boutique consultancy offers user research and customer service support, accessibility assessments — even development services for creating pattern libraries and voice assistant applications. At its core, though, the work is psychological.
“You can change an organization’s culture,” Watson said. “It takes time, it’s like turning a tanker, but it can be done.”
Back in 2011, the UK government embraced the challenge. It decided to replace a constellation of outdated central government websites with a single site built using open-source web standards and a set of accessible design principles. A 12-person team put together the first prototype to the disbelief of skeptics.
“Everybody just laughed at them at the time and said, ‘It can’t be done,’” Watson, who joined the Government Digital Service team when it grew to 25, said.
But the team was unruffled. Together, its members formalized a set of design standards. These were far from moonshot ideas. Things like “putting the user first” and “doing the hard work so users don’t have to,” Watson said. But they made a big difference. Today, the site is considered a model of best practices in accessible web design.
“Nine years later, that thread of putting people first and getting accessibility right, getting inclusive design to work, is still a huge part of the cultural mindset,” she said. “When people are being recruited, it’s something they’re asked about. Everybody just regards accessibility as a matter of professional quality. Part of doing your job, doing it properly and doing it well. And that’s incredibly important.”