Accessibility vs. Inclusive Design: My Point of View

Note: This is one point of view (POV), at a particular point of time in my professional career. My POV sways and shifts over time. The intent of this article is to generate discussion and spark different POVs.

Many times, the terms “accessibility” and “inclusive design” appear to be used interchangeably to refer to accessible design and development.

As my journey in digital accessibility continues and matures, my thoughts on these two topics continue to evolve, typically based on real-world work in corporate and client-based interaction.

And while many people may desire to talk inclusive design rather than accessibility, there are scenarios that focus on two unique topics, which need to be addressed.

In this post, I illustrate my thoughts on these two topics, how they differ and can complement one another.

My Point of View

Accessibility is the activity of making pre-existing websites and apps accessible. Inclusive Design considers accessibility upfront, at the beginning and throughout the lifecycle of a project, and includes user experience solutions in support of a rich experience for the most individuals possible, no matter their ability.

In situations I’ve experienced, the emphasis is on instructing designers and developers what to do, and how to fix accessibility issues.

There’s a famous quote, which reads, “Give a Man a Fish, and You Feed Him for a Day. Teach a Man To Fish, and You Feed Him for a Lifetime.”

To use this in the context of accessibility, “Give a designer or developer the instructions how to fix an accessibility problem, they are able to fix that problem.”

Accessibility

Accessibility is the awareness of, attention to, and remediation of existing factors that prevent individuals with varying abilities from performing tasks or obtaining information. It’s global in nature.

In my experience, sadly, it is rare for accessibility to get appropriate and timely attention and consideration at the beginning of a project. In many cases, accessibility is a last minute “fix” or a “fast follower” task after a launch.

With real-world accessibility activities, sites or apps are reviewed and analyzed for their compliance to standard guidelines for accessibility, such as the Web Content Accessibility Guidelines (WCAG).

Violations are reported and recommended remediations (fixes) are designed, developed and implemented, typically with the least amount of visual change as possible.

These items must go through a quality assurance phase, and often, are sent back for re-development work. In some cases (yet not enough), proper usability testing is performed, typically when mandated or due to legal action.

These activities tend to make what is lacking accessibility, more accessible, while really not changing much in the design, except for accessibility issues such as color contrast.

Efforts are expensive, as it takes more time and resources to remediate sites and apps than it would if they had been created in an accessible manner at the beginning.

Additionally, much of remediation work only includes compliance fixes. It doesn’t alter the user experience, as this would be potentially intrusive to the design.

You’ll find many compliant websites which offer poor experiences for people with disabilities.

If accessibility is considered upfront, by design, and developed in accessible ways, accessibility can be a seamless facet to the entire workflow process. This, in my mind, is considered inclusive design and development.

Inclusive Design & Development

Inclusive Design is the consideration of all users, with varying levels of ability, following accessibility guidance and best practices upfront and throughout the lifecycle of a project or product.

Imagine performing user research and developing personas that include individuals with low-to-no vision, or individuals who are deaf or hard-of-hearing.

Also consider individuals using non-mainstream input devices and assistive technology, such as switches, or puff and sip.

Moreover, considerations are needed for cognitive and learning impairments that are invisible to the eye.

Your group of designers will now need to recognize more than color contrast when creating designs.

Font and UI element size and spacing, proper organizational and semantic headings and sub-headings, impact of accordions, tooltips, sliders, toggle buttons and carousels, all of these factors are more readily addressed during the design phase rather than while remediating, when design changes may be required.

With the knowledge of accessibility considerations upfront, accessibility will find itself seamlessly in the resulting designs.

Developers, who for years have been accustomed to leveraging non-semantic elements like divs and spans to perform their scripted magic, now need to think holistically about code semantics and craftsmanship as they approach development.

They’ll also need to pay attention to the relationships between labels, input fields, and their messaging, as well as the roles, properties, and states of custom widgets.

Inclusive Design addresses the second portion of that famous quote, “Teach a designer or developer to design and develop in an accessible manner, and they will consider it in all their work.”

Rather than focusing on providing remediation steps, teach accessible considerations when designing or coding upfront.

You’ll reduce the time and resources needed to repeatedly remediate websites and apps.

And that is better for all.