UX designers vs. developers: Who really owns accessibility (A11y) in UX design?

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:

• A button might only be activated with a mouse “on-click” event
• The keyboard focus gets trapped in one of the interface’s widgets, or
• The tab order of the UI controls on the page might not make sense.

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.

Who actually owns accessibility?

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?

Factors causing accessibility to be siloed

• Accessibility is perceived as being technical — Designers may think they don’t need to worry about accessibility because it involves the underlying code, like the HTML and CSS. But accessibility starts with the designer making sure the designs are keyboard-friendly, have sufficient color contrast, etc.
• Insufficient training and awareness — Some designers and developers don’t have the skills to understand web accessibility, to understand who is responsible for certain criteria, which leads to missed opportunities and inaccessible products
• Lack of team collaboration — When designers, developers, and project managers don’t collaborate on accessibility, it won’t get done. Annotations and documentation for accessibility can easily get lost as developers prioritize functionality and getting a minimal viable product (MVP) out the door
• Accessibility isn’t ingrained in the product cycle — Accessibility isn’t considered until the end of the product development cycle, causing teams to reactively address accessibility issues instead of preventing them from the start. It’s harder to remediate products that have already been built than to design and code with accessibility in mind

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.

Common collaboration pitfalls

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:

• The accessibility “hand-off” trap — Designers assume developers know how to properly code their designs after a simple hand-off, whether it be through a walkthrough of the designs in Figma or a link to documentation. But if the developers aren’t familiar with specific requirements, such as proper tab order, it won’t be implemented after the design hand-off
• Ambiguous design specs — Designers have a lot on their plates when generating design specs for developers; they need to create user flows, prototypes, and annotations specifying interaction patterns. But when annotations are missing or the specs have unclear labels, developers will have to take a guess at what’s implied in the designs
• Speaking different languages — While designers speak in terms of the visuals, developers speak in terms of the code and semantics, leading to a loss in translation. As designers, you may not fully understand technical constraints, but developers experience the same when interpreting the designs. By not using terminology both parties can understand, miscommunication happens
• Misaligned priorities — When designers and developers are rushed to deliver a new feature, module, or webpage, items that aren’t prioritized are descoped. Accessibility is typically descoped because it’s not prioritized by the project manager or developers; they want to crank out the product as fast as possible to meet deliverable goals. This leads to a team prioritizing different things, with designers focusing on accessibility, while developers focus on basic functionality

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.

Where accessibility starts and ends

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?

How designers can have an “accessibility-first” attitude

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:

• Discovery and ideation — Understand accessibility standards like the Web Content Accessibility Guidelines (WCAG), define accessibility goals, and conduct user research with users of diverse abilities to understand their needs
• Design — Use color palettes with high color contrast, provide alt text for any images used, offer a suggested tab order and focus states for all interactive elements, and use headings or organize the content (between H1 and H6)
• Development — Ensure developers use semantic HTML instead of divs and spans, give proper labels to all interactive elements, and provide text alternatives for non-text content, such as providing captions for video content
• Testing and QA — Conduct accessibility audits with both manual and automated testing using tools like WAVE API or Axe Devtools, test the product demo with users with disabilities, and remediate accessibility issues found
• Release and maintenance — Continue to monitor accessibility, prioritize and address any accessibility issues reported by users post-release, and share accessibility efforts with company stakeholders

Accessibility tools for designers

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:

• Stark — Stark offers a Figma plugin designers can use to check color contrast, annotate tab/focus order and landmarks, as well as simulate vision disabilities such as red-green color blindness
• Figma plugins — There are many accessibility-focused Figma plugins, but Text Resizer-Accessibility Checker and A11Y Annotation Kit are a couple of favorites. The Text Resizer plugin helps designers understand how the content will appear when users enlarge text to their preferred size, and the Annotation Kit provides resources that designers can use while creating specifications for developers. For more options, check out these other Figma plugin recommendations
• Accessibility checklist — Deque University offers a handy, quick web accessibility checklist for designers to review their products with, focusing on page structure, navigation, images, and user inputs. This checklist can be downloaded as a PDF for your convenience

Collective model for accessibility success

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:

Team education

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:

• Training sessions — Invite an accessibility subject matter expert (SME) to host a training session and raise awareness. There are options for team or role-specific training for designers, developers, and project managers
• Self-paced courses — Require product team members to complete accessibility training courses that review foundational principles, like W3C’s Intro to Web Accessibility
• Screen reader and keyboard usage — Teach team members how to use the basics of a screen reader and keyboard, such as VoiceOver on Mac, and ask them to navigate the product using a screen reader with only their keyboard

Collaborative workflows

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:

• Accessibility champion — Identify a “champion” to lead the accessibility initiative among the team, but this person should be someone already knowledgeable of web accessibility
• Early involvement — Include designers and developers in the beginning stages of the product cycle to ensure everyone understands the product requirements and accessibility needs
• Accessibility-focused annotations — Require designers to create annotations focused on accessibility needs, such as tab order and landmarks, for developers to reference when viewing designs
• Pair designers and developers — Have designers and developers sit together to walk through designs for hand-off, as well as review what has been implemented to flag accessibility issues early on

Shared tools for testing

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:

• Axe Devtools — Axe Devtools offers a Chrome extension, which is accessed from the “Developer Tools” in Chrome. Though some features are paid, you can get a full-page scan for free to identify issues, as well as see which line of code includes the error
• Google Lighthouse — Similar to Axe Devtools, Lighthouse is an integrated extension in the “Develop tools” for Chrome. Lighthouse generates a report for categories like performance, SEO, and accessibility, and provides a score to see accessibility improvements over time better
• Silktide — Silktide provides a browser extension anyone on the team can use to run an automated check on live web pages, test interactive elements using a keyboard and screen reader, as well as review heading structure, landmarks, and alt text
• WAVE API — The Web Accessibility Evaluation Tool (WAVE) offers a search field to plug-in your URL as well as a browser extension to test directly on the webpage. This tool provides a summary of the results, and makes it easy to identify any errors or alerts on the webpage

Conclusion

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.

The post UX designers vs. developers: Who really owns accessibility (A11y) in UX design? appeared first on LogRocket Blog.

This post first appeared on Read More