A common misconception held by UX designers is that accessibility is solely the developer’s responsibility. Some assume that if they use a high-contrast color palette and hand off clean designs, the final product will automatically be accessible.
But accessible UX goes far beyond the design’s color contrast. And it’s not just up to developers. Designers play a crucial role in ensuring accessibility from the very beginning. Developers may intuitively know how to create accessible products, but they often rely on designers to provide experiences that consider a wide range of user needs — especially for users with disabilities.
Take, for example, a keyboard-only user — someone who navigates a webpage using only the keyboard (typically Tab, Enter, Space, and arrow keys). Even with perfect color contrast, this user may be unable to complete key tasks if:
Any of these issues will ruin the user experience — making the website unusable and inaccessible to non-mouse users.
Web accessibility is not a “nice-to-have” feature — it’s a necessity. Designers and developers have to collaborate to build accessible products. Designers lay the foundation with their design choices, but they must also advocate for accessible implementation during development.
But why does accessibility usually fall through the cracks? And why is it the designer’s job to make sure the designs are accessible? To answer these questions, let’s discuss who “owns” accessibility, where accessibility starts in the product development cycle, and then review common collaboration pitfalls and how to build a model for accessibility success.
As a designer, you might be thinking, “Isn’t web accessibility reliant on code and how the designs are implemented?” Although there is some dependency on how developers code a design, web accessibility has historically been siloed within the development team, meaning designers have often felt “off the hook” when it comes to creating accessible designs.
But why is this the case?
These factors lead to inaccessible products, causing poor user experiences for specific user groups, such as users with low vision or keyboard-only users. And when product teams are asked why the product isn’t accessible, a finger-pointing game is initiated.
Ultimately, developers aren’t the only ones in a product team who are responsible for accessibility. All team members are (especially designers). Designers have an obligation to both create designs with an “accessibility-first” mindset and advocate for accessible implementation, providing annotations and recommendations for their developer teammates.
One of the biggest barriers when creating accessible products is a lack of team collaboration. However, it can be challenging to determine if your team has effective collaboration when it comes to accessibility, especially when it’s first being integrated into your workflow.
To better understand common pitfalls of collaboration, let’s look at some examples:
To create inclusive websites and applications, the entire product development team must be aligned and have effective communication channels in place. We’ll see some strategies your product team can do to enhance collaboration later, such as team education and shared tools for testing.
As we discussed earlier, if accessibility isn’t ingrained in the product’s lifecycle, there’s a greater risk of creating inaccessible and exclusive websites and applications. Inclusive thinking begins at the start of product development, with initial discovery and requirement gathering, and then continues throughout the entire product cycle.
But what does this mean, and how can designers best consider accessibility from the beginning?
Again, accessibility doesn’t magically happen when the designs are handed off to development; it begins at the start of a project, whether it be a new feature or an entire product. Though there are many variations of the product development cycle, some starting with “Discovery” and others with “Ideation,” accessibility must be built into this step and each following step.
Here are strategies to integrate accessibility for each product development stage:
Integrating accessibility into the product development process, specifically the design stage, can seem tedious and challenging. But there are tools made for designers to make this process seamless. Let’s look at a few:
Because web accessibility is a product-wide concern, the entire team needs to have a model in place to ensure its success. And integrating a model for accessibility doesn’t happen overnight; it takes time and effort from all team members.
Although there are tools like Level Access’ Digital Accessibility Maturity Model (DAMM) that can measure your product team’s accessibility maturity, there are strategies your team can focus on now to jumpstart its conformance to accessibility:
Before a product team can think about accessibility, everyone needs to understand what it is, who it impacts, and how it is governed. Many people think accessibility is an effort to ensure adequate color contrast in an interface, but it also encompasses many other requirements, such as keyboard and screen reader functionality.
Ways to educate all product team members include:
Once the product team has a solid understanding of web accessibility, they can move on to generating workflows and processes that support accessibility. These workflows create a sense of shared responsibility among each team member, and open communication throughout the team. This way, the team can generate an effective feedback loop to ideate, test concepts, and then get feedback from different perspectives.
Strategies to foster collaboration on accessibility:
Once the product is in development or already exists, it’s critical to test it. If testing is done during the development stage, the team can catch accessibility issues and fix them before they become a costly problem if found post-release. And when testing live products, the team can identify issues to create a remediation plan, prioritizing them from most to least critical. Testing the product at every stage is best practice for monitoring and maintaining inclusivity, and anyone on the team can conduct the testing using the right tools.
Recommended tools product teams can use for free:
The responsibility of creating accessible digital products doesn’t entirely fall on the laps of developers; UX designers also share these duties. It’s a common myth that developers naturally know how to create web pages that are accessible, but many developers lack awareness of how to create accessible code because it’s not a priority. Web accessibility is essential, and it’s up to both designers and developers to collaborate and upskill in accessibility to build accessible products that diverse people can use.
Although UX designers rely on developers to implement their designs, accessibility has historically been siloed to developers due to its perceived technicality, insufficient training, and accessibility being considered at the end of the product development cycle. This is only exacerbated by common collaboration issues such as ambiguous design specs, designers and developers speaking different languages, and misaligned priorities. So even if designers create annotations for accessibility, developers may not properly interpret the documentation if it’s not translated into terms they better understand.
To get the entire product team on board with accessibility, it needs to be integrated from the beginning to the end of the product development cycle. Having an “accessibility-first” attitude begins by understanding WCAG standards and defining product requirements that incorporate these standards. This better equips the design and development stages to meet these standards with elements like proper tab order and semantic HTML. Once the product is tested and released, a few accessibility issues are identified and need to be remediated, thereby saving time and resources.
Lastly, fostering a culture of accessibility among the product team requires a collective approach to be successful. Although this process can take months to years to establish, product teams can begin by conducting training sessions to increase accessibility knowledge and awareness, creating workflows that boost collaboration among siloed teammates, and sharing tools to test products at any stage of fidelity.
Web accessibility is no longer a “nice-to-have” that may or may not happen if the team has time. It’s a “must-have” to ensure people with diverse abilities can access and use any product they wish whenever they want.
LogRocket's Galileo AI watches sessions and understands user feedback for you, automating the most time-intensive parts of your job and giving you more time to focus on great design.
See how design choices, interactions, and issues affect your users — get a demo of LogRocket today.
I used to leave design reviews with a stack of subjective edits. Then I learned to tell the story behind my work and rework dropped fast.
Prototyping turns static designs into living blueprints. See how it saves UX teams from rework, missteps, and costly misunderstandings.
Vibe coding lets you describe an app in plain language and watch AI build it for you. Here’s how I created two micro-apps — a form-filling extension and a X trend finder —that cut my daily workload in half.
See how unifying screens in a trading platform redesign halved task time and how you can use the same UX principles in your product.
Learn more →
