Accessible design empowers you to create major usability improvements and a more positive digital experience for all—especially for those with a disability. When it’s taken lightly or misunderstood, it can result in exclusionary products for specific user groups. It can also cause usability issues after the product has been released, which can cost product teams 40-100 times more to fix.

Considering one billion of the world’s population live with some form of disability, building accessible products shouldn’t be a practice that’s taken lightly. Thankfully, in more recent times we’re seeing a bigger commitment to building a more accessible digital world. For instance, about $10-16 billion in design spending between the US and Canada alone, will shift towards tech companies that are prioritizing accessibility.

To contribute to this mission and to truly serve all users of your product, try to avoid the five accessible design mistakes highlighted below.

1. Designing strictly for accessibility compliance

When getting started with building accessibility into new or existing products, it’s easy to fall into a trap of just building for minimal compliance requirements. In the beginning, this may be a good starting point. However, strictly building for accessibility compliance results in a product that may pass checks, but still results in an inadequate and exclusionary experience for some users. This is because compliance guidelines such as those noted in WCAG aren’t all-encompassing, and can’t replace the real and lived experiences of individuals with disabilities.

For instance, wrapping social media toolbars inside nav elements isn’t currently a success criterion within WCAG. However, adopting this best practice can save screen reader users time and effort, since they no longer have to listen to them on every page.

One way you can further your goal beyond minimal compliance is by starting early and incorporating best practices into all aspects of your product development life cycle. In particular, be sure to conduct accessibility research and early-stage testing with all users, including those with disabilities.

2. Using overlays as a catch-all solution

Accessibility overlays are plugin tools that claim to find accessibility problems on a webpage using AI, and fix those issues on your browser as the page loads. They've become popular as an “accessibility quick fix” or a “catch-all solution”. However, the reality is they fail to detect 70-80% of barriers that disabled users normally face. In fact, overlays often create their own barriers for users with disabilities, while still leaving sites vulnerable to web accessibility lawsuits. For example, closed captioning, focus order, and mislabeled or unlabeled form fields are common accessibility issues that aren’t accurately detected or diagnosed by overlays.

Rather than relying on a quick fix solution, it’s best to fully commit to building truly accessible digital products. You can do this by testing manually and addressing the issues detected within your underlying source code. Testing should always include users with disabilities as they can provide further insights into your product’s accessibility standards. Additionally, there are many tools that offer teams the support they need to bake accessibility into their products. For instance, you can easily QA projects in flight, and retrofit work that’s already been done by using the tools available in Stark for Chrome!

3. Assuming accessibility is only the developer’s problem

Despite digital accessibility being prioritized in more and more companies, there’s still a lingering assumption that the onus of baking accessibility into a product is on developers. For example, annotating landmarks or the focus order of a web page was something that developers historically took on, and incorporated into their code. However, truly accessible and usable products can only be built more efficiently when designers share the responsibility, and organizations prioritize cross-functional collaboration between both teams.

For instance, going back to our landmarks example, you can use tools such as Stark’s Landmarks to think through the navigation of your digital products. When you intentionally label landmarks, developers no longer have to approximate where exactly they should be included in their code—saving them an abundance of time. This not only results in a better experience for your end-users but also allows you to create a final product that works exactly as you intended to.

Together with the right tools and the implementation of best practices such as creating accessible user journey maps, designers can be intentional about accessibility rather than taking a back seat approach.

4. Thinking accessibility is costly or at odds with aesthetics

It’s a common misconception to think that beautiful design and accessibility can’t go hand in hand. In many cases, designers adopt the view that meeting contrast ratio requirements, for example, means that you have to pick boring colors that go against your brand identity. Even with text, sometimes it feels like you don’t have the opportunity to play around with different fonts, and make your website your own.

The reality is far from this! The truth is, accessibility and beauty are not at odds with each other. One should argue that truly accessible products are beautiful because they’re usable and therefore designed well. It’s easy to skip out on accessibility and just focus on adding bells and whistles in the name of visual aesthetics. However, it’s our job as designers to make sure that we find the middle ground where something is both aesthetically beautiful, and accessible to all. One way to ensure that you can do this is by testing alongside users with and without a disability. If all of your users showcase positive experiences with your beautifully designed product, then you most likely found that middle ground!

5. Lack of accessibility baked into data visualization design

One of the most overlooked accessibility considerations when it comes to design is data visualization. Think of data labels, for example, and how difficult they are to consume despite ability. Or how a pie chart’s colorful segments can result in confusion if contrast and white space aren’t considered. Beyond this, think of how emergency maps are often designed to be purely color-based. And how this can seriously contribute to harm if colorblind people can’t navigate them during an emergency.

Data visualization is meant to aid your written content by removing the noise and clarifying your point in a timely manner—in seconds to be exact! So if any of your audience members are unable to access your visual data, or experience any level of distress while engaging with it, then there’s a major accessibility issue to be addressed.

It’s important to note, however, that not all accessibility issues as it pertains to data visualization, are specific to visual impairments or blindness. For example, individuals with cognitive, learning, and neurological disabilities may also experience difficulties with overly complex visuals.

The most productive way to think about accessible data visualization is by considering an alternative storytelling path that addresses the needs of users with both physical and cognitive disabilities. For instance, if you had no visuals at your disposal, how would you make the same points? If you keep this strategy in mind, it’ll inform the design choices you make like choosing drop-downs instead of sliders to manipulate data with ease.

---

By prioritizing accessibility and making an effort to avoid these mistakes you’ll be able to realize major usability improvements, and a more equitable digital experience for all—regardless of ability, condition, or circumstances.

---

Want to join a community of other designers, developers, and product managers to share, learn, and talk shop around accessibility? Join our Slack community, and follow us on Twitter and Instagram.

To stay up to date with the latest features and news, sign up for our newsletter.