Accessibility is becoming even more essential for programmers to understand. In 2020, the US Supreme Court ruled in Domino's vs. Robles that the internet and apps are 'places' in relation to the Americans with Disabilities Act. That means that disabled people can now sue digital applications that aren't accessible.

More than just a legal obligation, many developers feel a responsibility to improve accessibility. This led Electronic Arts to announce they wouldn't enforce their accessibility patents so that other developers could leverage them to make more inclusive games.

The trend towards accessibility is clear. Knowing how to integrate accessibility into development will soon be a core competency for programmers of all types.

What Is Digital Accessibility?

Digital accessibility is the process of ensuring that disabled people can access digital products like apps and websites. That could mean making sure that video conferencing apps have captions so that Deaf or hard of hearing people won’t miss what’s happening. Or it could mean adding alt text to images so that blind people can have the visuals explained to them by screen readers.

The most commonly used guidelines around accessibility are the Web Content Accessibility Guidelines, an international accessibility standard created by the World Wide Web Consortium (W3C).

The guidelines currently in place, known as WCAG 2.2, were published in late 2021. These guidelines focus on four key principles that are at the core of digital accessibility: perceivable, operable, understandable, and robust.

Each section addresses how people with different kinds of impairments or assistive devices use tech and how programmers should design for that.

Conformance levels are measured via Level A, Level AA, and Level AAA standards with the lowest level a minimum threshold and the highest level meant to address more complex and specific accessibility issues that enhance disabled users’ experience.

The Problem With Compliance-Based Approaches

There are two main problems with traditional approaches to digital accessibility. The first is that there’s often a multi-year lag between an emerging inaccessible technology or practice and the guidelines that help correct for it.

With WCAG 2.2 released over a year late and work on the next iteration, WCAG 3.0, underway now for years, it's clear that the accessibility guidelines currently being used were outdated before they were even published.

The second problem is harder for many programmers to understand. It’s that these guidelines don’t go far enough.

Why Enhanced Accessibility Matters

Unfortunately, many developers are using a cookie-cutter approach to digital accessibility that relies too heavily on compliance to WCAG guidelines when accessible design should be a more dynamic process.

Standards-compliant developers often believe that if they just tick all the boxes their products will be accessible. But that simply isn’t true. In fact, if sued under the ADA, a company’s defense that they complied with WCAG guidelines might not be enough.

Why? Because even conforming to Level AAA does not guarantee your project or website is accessible—it’s designed to set a minimum standard of accessibility.

Development teams shouldn’t just want to make their work accessible to a broader population, they could eventually be required to as new regulations or case law emerges.

Why You Should Care About "Accessibility Debt"

Most programmers are familiar with the term "tech debt". It describes the consequences of development work that uses the easiest coding solutions rather than the best ones. This often leads to inefficient code and the need for future remediation work.

"Accessibility debt" is a similar concept. It refers to the inaccessible code and products a team or company has on the market or in development that will take time, effort, and money to make fully accessible. Over time and across products or sites, this accessibility debt grows until it becomes incredibly costly to fix.

By not working on accessibility now, programmers aren’t just making it harder for disabled people to use their products. They're also creating future liabilities for their companies should regulations or accessibility standards shift.

The Challenge of Enhancing Digital Accessibility

One of the biggest impediments to creating more accessible code is that many programmers have a limited conception of what disability encompasses. The accessibility personas that Product and UX teams sometimes use to help guide design are too often focused on commonly known disabilities like blindness, deafness, or paralysis.

Programmers might know they have to design with epileptics in mind but might not consider the accessibility needs of users who have chronic migraines, a condition that is disabling for many sufferers.

What’s more, these personas rarely encompass users with multiple disabilities or those who use a variety of accessibility devices. For example, many of the functionalities on a popular voice-to-text software can’t be used if users have high contrast mode enabled.

For a product that’s commonly used as an assistive device by people who have visual disabilities—a group for whom high contrast mode can often be necessary—that’s an extraordinary oversight by the development team.

Using Universal Design For Better Accessibility

So, what can a programmer do if they want to achieve higher accessibility standards? The first step is to let go of the type of thinking that protocols like WCAG 2.2 foster, which is that accessibility is something objective with specific, clearly defined design and programming interventions.

As an alternative, universal design concepts, which are part of a group of practices that are sometimes referred to as inclusive design, can help programmers reevaluate their designs and change their design process to consider how to make their products more accessible to people of all abilities right from the problem definition stage.

There are seven universal design principles to deploy: equitable use, flexibility in use, simple and intuitive use, perceptible information, tolerance for error, low physical effort, and size and space for approaches and uses.

At first glance, they seem likely to lead to code that parallels WCAG 2.2 guidelines. However, the key difference is that designers start by considering these principles as fundamental to their design for all users rather than focusing on conforming designs that were created for the "average user" to accessibility standards later on.

This flips the problem definition and design stages as it requires programmers to assume all users might have a disability. That often ends up saving companies money since tacking on unplanned accessibility features adds to the time and budget needed to complete a project.

Universal design also often leads to better products as products developed according to universal design principles are often more usable for everyone.

The Importance of Usability

Universal design principles also explicitly talk about use—something that’s not within the scope of WCAG guidelines. While related, usability and accessibility are different lenses with which to gauge a disabled user’s experience.

Accessibility is focused simply on ensuring that disabled people can access a site or product, not that they can do so in a way that is efficient, flexible, or preferable.

For example, a website can meet accessibility requirements if a visually impaired user can access it via a screen reader. However, some visually disabled people prefer text-to-voice apps and don’t own a screen reader.

If your website prohibits the exportation of text to an app as some news sites do, your website is technically accessible to that user... but it’s not usable to them. So while that doesn't violate the ADA, it means a disabled person can't use your product.

Another challenge occurs when programmers encounter situations where they're technically conforming to accessibility guidelines but not functionally conforming to them.

In this case, a website might meet WCAG requirements via a code audit, but it still might not fulfill the objective of "full and equal enjoyment" according to the ADA if a disabled person doesn't have access to the same things as a non-disabled person.

Most accessible design standards stop short of focusing on usability and usability testing often doesn’t include disabled users. But usability should be a key metric in accessibility testing and usability testing should be focused, not just on the average user, but also on disabled users, a group far more likely to experience issues.

How Design Justice Can Help

One final concept programmers should understand is design justice. An approach to design that explores the relationship between design, power, and social justice, it rethinks design processes to center the voices of those who have been traditionally ignored in design practices.

Indeed, design justice’s processes recast the designer as a facilitator rather than an expert. This shift can be helpful since disabled people are authorities on what they need. Not centering them could mean spending time and money on accessibility features that aren’t useful.

Disabled design strategist and activist Liz Jackson even coined a term to refer to the elegant but useless solutions non-disabled designers come up with: disability dongles. These are products that aren’t needed or offer a solution that isn’t usable.

What would a design justice process look like for your product? It could mean hiring a number of disabled experts to help with accessibility research, UX design, programming, QA, and usability testing. It could also mean hosting paid focus groups with disabled users at every stage in your development workflow.

Ultimately, the most important aspect of design justice is how it helps programmers understand the power they hold. Every coding or design choice you make could have a huge impact on the lives of disabled people if your decisions create barriers.

That could impact not just their access to your product, but also their access to the things your product facilitates like communities, experiences, or even employment.

Next Steps for Improving Digital Accessibility

Now that you know why digital accessibility is so important and the complexities involved in doing it well, what can you do?

• Start by learning more about universal design and design justice. There are workshops, online courses, and books available to help.
• Review your development workflow to center accessibility at every stage.
• Budget for your team to get training in accessible and universal design.
• Hire disabled programmers and include disabled people as collaborators on projects.
• Establish clear guidelines on accessibility conformance and usability.
• Use disabled people who are native users of assistive technologies to do QA testing rather than simulating disabled people’s experiences.
• Create checklists that capture key accessibility milestones during development.

Nothing can ever be 100% accessible because human impairments are multi-faceted and different disabled people’s accessibility needs often conflict. But the more time programmers spend thinking about the needs of disabled users, universal design, and design justice, the more accessible future products will be.