Strong Fundamentals

Reading Time Time to read: 8 minutes

Why accessibility matters to your startup (Part 3): So you think it's too expensive?

Alex Williams

Front-end Developer @ Forward Partners

In my previous article 'Why accessibility matters to your startup (part 2): So you think it's too time consuming?' I aimed to show that if you approach accessibility as an iterative process then it is not prohibitively time-consuming, even for startups. Instead it can save you time in the long run.

In this article I want to consider the second of the two arguments against accessible design for young products: that accessibility is too expensive. The assumption behind this argument is that regardless of how long it takes to implement improvements to accessibility it will be expensive, and with startups cash is at a premium. Large sums earmarked for accessibility testing could instead be spent on enlarging marketing budgets or improving the product in anticipation of the next round of fundraising.

However, both accessible design and testing do not have to be prohibitively expensive. Many big wins can be done cheaply and building good habits into your team from an early stage becomes an investment in your future product. Yet if you do not invest in accessibility from the beginning you run the risk of paying a higher bill later in the product's life.

Key Takeaways

  • You can achieve a lot with very little additional resource, ie. accessibility can be done "on the cheap"

  • Investing in accessibility is also an investment in your product team

  • Failing to invest in accessibility early is a false economy, one that will be more expensive to rectify as the product grows

Accessibility done on the cheap

Implementing good, accessible design can appear frighteningly expensive when you consider that to truly cover all of your bases you need to, for example, invest in assistive software like JAWS. JAWS reads out elements on the page aiding visually disabled users in navigating and in understanding your product. It is an expensive product not only to buy but also to develop for.

Like internet browsers JAWS has multiple versions and often users will buy and hold onto a version for a long time as the starting price for the Microsoft Window's-only screen reader is $900. Therefore to make your product truly accessible you would have to consider testing your product across all 18 versions of the assistive software as there is no guarantee that one of your users is not stuck on version 10 with no way to upgrade.

Obviously this example is overkill, however it is worth mentioning, as I believe many people consider this to be the epitome of what accessibility testing consists of. It is therefore not surprising that testing is pushed back to a time when the company is larger or in many cases, indefinitely.

However, accessible design and testing doesn't have to be expensive. Let's take a look at three big wins that can greatly enhance the usability of your product while costing very little to implement: structured semantic content, well constructed copy, and clearly focusable links.

Digital products are created using HTML, CSS and JavaScript. Out of these three technologies, the HTML forms the structure of the page - a document outline. You may have seen this when a website fails to fully load and you are faced with a white page containing headings, black text and bright blue links. It is this outline that is important to visually disabled users who rely on an assistive device such as a screen reader. The screen reader will parse the HTML on the page and create its own document outline so that the user can move through the page in the right order and the device will be able to audibly read out each element.

This becomes quite confusing if the developer has used the wrong type of HTML element in the wrong order. For example, using a second level heading (H2) because it looks correct when the content being described in the heading is actually a third level heading (H3). This will cause the assistive device to misrepresent the content on the page. However this is a simple, inexpensive problem to solve. Writing semantic, well structured HTML will go a long way towards making your product fully compatible with an assistive device.

Similarly it can be common for designers and developers to create custom links and buttons out of non-focusable HTML elements. In simple terms the default blue hyperlink and grey button which are the browser’s default implementation are easily recognised by assistive devices. The device is able to add the elements to its document outline and when a disabled user moves through the page each element can be focused on (clicked, or passed over). With custom elements the assistive device is unable to recognise the element. This can result in links and buttons failing to appear in the document outline and becoming invisible to the disabled user.

Again, this is a simple and inexpensive problem to solve. In following best practices for using and styling the default implementation of elements like the hyperlink and the button rather than creating custom elements, you can ensure that right off the bat any user will be able to focus on and interact with all you your products key calls to action.

Our final example is an often overlooked but very effective way of making your product more accessible to a range of different users with different disabilities: well constructed copy. One of the lesser considered disabilities is learning difficulties. A user with dyslexia when faced with a landing page covered in jargon, and overly dense descriptions will struggle to both read and comprehend the message that your product is trying to get across. This could result in a lost sale, and a customer who will never return to your product. However, a landing page that uses simple language. Language that is clear and concise, and that speaks in a way that a layman would understand will be both easier to read and to comprehend. Taking more time to carefully construct your copy is an inexpensive investment in making your product accessible.

A False Economy

Ignoring accessibility due to perceived expense is a false economy. In trying to save money by not investing a small amount of time in making your product accessible, you start restricting your maximum possible audience size at the very time when you need to throw your product's gates wide open and demonstrate aggressive growth.

While it costs very little to invest in building an accessible product in its early stages, that cost begins to dramatically rise as the product develops. The cost of an engineer spending an extra half an hour checking to make sure that elements in a small feature can be focused using the keyboard is very little in comparison to the cost of hiring an agency to review and recommend changes to an entire website or product.

This becomes compounded when you consider that a designer who learns to build in accessibility to the process by which they design an element will be able to repeat this process for every new element and it will become second nature. You will begin to install best practices in your team while your product is small and straightforward.

This is much harder to do when the product is older, more complex and the team may have grown past the original handful who helped launch version one. Furthermore, if recommended changes are not be coming from the team, but instead imposed upon them by an external agency they will not absorb them into their process quite as easily.

Accessibility matters to your startup because implementing best practices from day one is cheaper than ignoring accessibility and having to retrofit it onto your product at a much later date. If you start with 'cheap' big wins then your product will start off inexpensively accessible and go on from there.



No comments yet

Post your comment

Similar Guides