Listen to the latest articles and insights from our experts.
Listen to the latest articles and insights from our experts.
The concept of Inclusive Design – making mainstream software, web applications, and digital experiences that are accessible to the widest possible range of users, regardless of ability, disability, gender, language, and more – is not a new one. But as web applications grow increasingly complex, accessibility often gets left out of the development process, which can result in costly product redesigns.
Fortunately, User Experience (UX) designers who are familiar with the basic principles of Universal Design and Web Content Accessibility Guidelines can incorporate Inclusive Design into their products from inception. By adhering to a few simple rules, UX designers can vastly widen the population that can successfully navigate their products – thereby mitigating risk and eliminating substantial hours of retrofitting.
“Accessibility needs to be taken care of from day one,” says Nitika Sharma, Head of Accessibility for Tricon Infotech. “It has to be part of the entire product life cycle.”
This is particularly important in Sharma’s world, as many of Tricon Infotech’s educational publishing clients like McGraw-Hill Education, Pearson, and Taylor & Francis serve schools and universities that are bound by their own accessibility requirements.
By contrast, trying to make an existing product more accessible to satisfy legal, regulatory, or commercial requirements can be expensive: a common rule of thumb holds that the cost to retrofit an existing product can be ten times as much as making it accessible from the start.
“Your design has to change, your code has to change, testing has to change,” Sharma says. “It’s not that we’re just going to put a layer on top of the existing product, and it’s going to be accessible.”
“Accessibility needs to be taken care of from day one. It has to be part of the entire product life cycle.”
“Accessibility needs to be taken care of from day one. It has to be part of the entire product life cycle.”
Nitika Sharma
Head of Accessibility
Tricon Infotech
When many people think of accessibility, they think of blindness, and specifically, how to make digital products compatible with screen readers. But real accessibility considers a wide spectrum of users with a diverse array of disabilities: visual (low vision, color blindness), auditory (deafness, hard of hearing), motor (inability to use a mouse/trackpad), and cognitive (learning disabilities, distractibility).
To be clear, Inclusive Design doesn’t suggest that it’s always possible to meet every user’s unique needs, but it does maintain that products should be created appropriately to meet the needs of the widest possible audience, especially within the target population.
A comprehensive strategy selects colors and contrast levels that are easy to read; onscreen navigation and controls that can be operated with keyboard commands rather than only using a mouse, trackpad, or touchscreen; and page layouts that are optimized for magnified views.
Of the many types of disabilities, Sharma says, cognitive challenges like learning disabilities, dyslexia, or difficulty focusing or remembering information, are among the least appreciated. “I think a lot of people don’t understand how to make sure that their content is understandable to people who have cognitive disabilities.”
Sharma recommends several solutions to better serve these users, beginning with writing clear, well-structured text with a logical reading order and vocabulary that is easily comprehended. “If a nine-year-old can read and understand it, that means you know your content is accessible for anybody.”
Other suggestions include employing proper heading and list structures; maintaining consistent fonts, colors, and locations of page elements; and ensuring that all actions can be initiated using a keyboard.
UX designers and engineers have many automated tools that can inform them during the design process, but wherever possible, before releasing products, Sharma cautions, creators should try to work with groups of test users who possess the identified disabilities.
“If I don’t have a visual disability, I know that I’m just testing based on what I understand. But somebody who’s actually blind, for example, would be the better person to give us the feedback.”
Adding this extra level of Quality Assurance can be a valuable part of the development process. For Sharma, they offer a definitive check before going live. “At the end of the day, the testers are the ones who are going to actually give a heads-up and say we’re good to go for the release.”
