Customer Traction

Reading Time Time to read: 4 minutes

Why accessibility matters to your startup (part 2): So you think it's too time consuming?

Alex Williams

Front-end Developer @ Forward Partners

In my previous article Why Accessibility Matters to Your Startup (Part 1): Who is a disabled user? I discussed the strong likelihood that a decent proportion of your users will be permanently or temporarily disabled, and that designing your product to be inclusive of their needs will significantly widen and diversify your customer base.

In this article I want to consider one of the two main arguments against accessible design for young products: that it is too time-consuming. The assumption behind this argument is that accessible design is hard and that to get it right is something that requires a lot of preparation before you build the product and then a lot of testing afterwards. This doesn't have to be the case.

To prevent accessibility becoming too time-consuming: consider the quick wins early and often (colour contrast, how clear is the copy, and general usability principles), test as you build (voiceover for Mac, WAVE, or even external consultants) and understand that accessible design is an iterative process (don't bite off too much, too soon).

Key Takeaways

  • Consider quick wins when designing your product, rather than trying to fix issues post-launch;
  • Find simple ways to test features as you build them, rather than the whole product after a release;
  • Understand that accessibility is an iterative process.

Consider quick wins when designing your product

Making your product accessible is time-consuming when it is only approached after the product has been researched, designed, built and launched. This retroactive approach to accessibility usually ends up conflicting with already completed work, pushing back deadlines and increasing costs. For example, designing the brand for your product without considering whether the colours are accessible means that the only way to make them accessible at a later date is to change the brand - more than likely out of the question.

However, if you turn this on its head and build a little bit of accessibility into the initial design process then you can often mitigate a lot of time-consuming testing and post-launch bug fixing. Let's use the above example of the brand and expand on how to implement a quick-win here: a considered approach to colour contrast.

Colour contrast determines whether a user is able to see and understand key parts of your brand, from the product logo to major elements on the page (for example, an add to cart or go to checkout button). The Web Content Accessibility Guidelines 2.0 (WCAG) suggest that for coloured text to have good contrast (ranked as level AA in the guidelines) against its background it must have a contrast ratio of 4.5:1 or 3:1 for text over 18px and bold. If you're looking for coloured text to have an excellent contrast (ranked as level AAA in the guidelines) it must have a contrast ratio of 7:1 or 4.5:1 for text over 18px and bold. While this sounds quite complicated it can be a quick-win when considered early in your product design process.

WebAIM, a website providing many tools and solutions for accessibility problems, has a tool designed specifically to check colour contrast and help designers create a colour palette that is visible to the widest number of users. Simply submit your foreground and background colours to the tool and it will explicitly state whether they are AA or AAA accessible.

Taking two minutes while designing the brand to check whether it is accessible gives you a solid foundation to build on rather than realising too late that for, statistically, 8% of your users the colour palette is impossible to read.

Find simple ways to test features as your build them

Testing the accessibility of your product can be time-consuming when, rather than testing small features, accessibility testing is left until either the last few days before launch, or until well after launch. You’ll end up with push-back from your developers if they have to test the entire product for accessibility in one go - a daunting task for even a small digital product.

This tends to lead to either ruling out accessibility testing altogether or outsourcing it to an external agency. While agencies (a great example being the DAC team in Neath, Wales) provide a brilliant service they are clearly prohibitively expensive for early stage companies and can slow down a fast moving startup.

So rather than waiting until the last minute to test your site for accessibility, build testing into your development process and approach it in small chunks. With free technologies such as Voiceover (Mac OS and iOS) becoming simpler to use, it is now easier than ever to test small self-contained features as soon as they are built. Similarly the WAVE plugin for Google Chrome can help developers quickly discover problems while a feature is being developed and fix them on the fly.

Like the quick-win of considering colour contrast when designing your brand, integrating testing into your development workflow can drastically reduce both the actual and perceived time it takes to discover and fix possible accessibility problems.

Don't bite off more than you can chew

Finally, it has to be understood that accessibility is an iterative process. It's often seen as time consuming because it seems like such a daunting, endless task to undertake. How do you make your complex, cutting-edge product visible to a user who may be blind, comprehendible to a user with learning difficulties or operable for a user with a disability such as Parkinson's? As such it's ruled out as too time-consuming a task for the company at its current size, and relegated to a task that could be revisited once the company is big enough to afford to pay an expert to review the product.

However it doesn't have to be this way. If you consider accessibility as an iterative process then you can start off small by baking simple checks like colour contrast into your design process, and you can develop and test small features instead of the whole product. Accessibility matters to your startup, and if you build it in from the beginning, in small manageable chunks, then you'll find it is not as time-consuming as some might think. Bake quality and accessibility right into your product in its infancy, and you'll be building on a stronger foundation that you won't have to revisit later on.

0 Comments

Comments are closed for this guide.

Similar Guides