Focus on accessibility

Crunch is all about helping people make their business a success. Our guiding principle of helping others, has led us to make accessibility a fundamental part of our development process within our Engineering Team. We want to make inclusive products and services that work for everyone.

What is Web Accessibility?

W3C (World Wide Web Consortium) define Web Accessibility in a traditional yet practical sense: as ensuring we provide an equal access and an inclusive user experience for all regardless of their disability or impairment, quoting Tim Berners-Lee in their Introduction to Web Accessibility article.

“The power of the Web is in its universality.
Access by everyone regardless of disability is an essential aspect.”
Tim Berners-Lee, W3C Director and inventor of the World Wide Web

The Web Content Accessibility Guidelines (often abbreviated to WCAG 2) are a series of guidelines produced by the W3C Web Accessibility Initiative (WAI) for developers and others to follow in order to ensure the accessibility of their online services.

These comprehensive guidelines are divided into 3 levels of success, Level A, Level AA and Level AAA. They include a vast array of success criterion ranging from ensuring that contrast ratio of images and text is sufficient in order to meet the needs of people with visual impairments, to getting your HTML semantics right in order to ensure your website is coherent for Screen Readers.

Whilst it is absolutely essential to consider accessibility in a traditional way (as catering for people with visual, auditory and physical disabilities) we must also look at inclusivity in an even broader sense.

Consider that some impairments are temporarily, such as a broken arm. Some are more hidden, like cognitive impairments such as ADHD. How would you rethink your web application to ensure the inclusion of these people?

Keeping it Simple

For every sort of disability or impairment (temporary or permanent) there are a multitude of solutions or accommodations we can offer to provide a better service for everyone. The Crunch Engineering Team began by focusing on what’s within their reach — with a view to expand this as awareness spreads.

We found that, rather than attempting to implement Accessibility retrospectively, it’s better seen as a basic requirement and founding principle. Many of the so-called accomodations were in fact perfect and sensible defaults.

What criteria do you believe is “a given” in software development?

One obstacle in creating an accessible website is your own lack of disability — in other words, only letting your own experiences guide you, rather than putting yourself in someone else’s shoes. Whilst designers consider user experience daily, us developers are more distant from the user.

With this in mind, It is difficult to know where to start with a topic as large and important as Accessibility — so we began by keeping things simple. Within engineering, we had regular meetings to discuss how accessibility was being approached by teams within Crunch. To help our front-end developers, we took the decision to document key points within levels A, AA and AAA of the WCAG.

This documentation has since become a reference for front-end developers to use during the development process and contains code examples detailing the right way to write accessible HTML.

Implementing Accessibility

The development of the new Crunch Website (built in ReactJS) gave us the opportunity to consider accessibility from day one. We agreed that the new website should be accessible up to WCAG 2.0 Level AA, feeling that this was a realistic goal for us. We had a strong desire to go for Triple A but understood that many of these criterion would be out of our reach acting alone.

During the initial design and development phase, we considered the colours that were to be used very carefully. We had to be confident that colour was not the only way of convey information or instructions to our users, a key part of WCAG 2.0 Level A accessibility.

At Crunch, we practice Styleguide Driven Development and follow Atomic Design principles. We believe this gives us a huge advantage when it comes to implementing Accessibility. Accessibility is literally ‘built in’ — because part of the criteria of every component in our library, is that it’s totally compliant with Accessibility standards. Furthermore, following atomic design means that larger components inherit the attributes of their children — which we already know are solid.

Continuous Reviewing

The documented guidelines we set out at the start would continue to be used as a reference, but we would also need to use tools to confirm that accessibility was being applied correctly during our development process.

For example, we use pull requests to check that these standards are being upheld by the team. During this peer-review stage, front-end developers will review code to check that accessibility is being considered and suggest any changes that may be required. The accessibility documentation is used as a reference to check we are meeting these guidelines.

In addition, we use online accessibility checkers that allow us to compare our code against the WCAG 2.0 Level A, AA or AAA guidelines, to be confident our code is accessible. A few examples can are below:

We also use React A11y which allows us to check the accessibility of our component library.

So how are we doing today?

We are proud to be able to say that our website is nearly WCAG 2.0 Level AAA compliant — with only a couple of errors being reported at the time of writing this post.

Thankfully, making improvements is far easier when you already have a good footing.

We will continue to routinely check our website using the tools mentioned earlier in this post — raising any faults as critical bugs on our product backlog.

How do we compare to our competitors marketing websites? I put a handful of our competitors homepages through the tool using WCAG 2.0 (Level AA) guidelines and got the following results arranged in order from most problems to least.

  • Boox (181 problems)
  • Clearbooks (81 problems)
  • Xero (61 problems)
  • KashFlow (15 problems)
  • FreeAgent (6 problems)
  • Crunch (that’s us!) (1 problem)

Next Steps

You only need the enthusiasm of a few individuals to accomplish a hell of a lot. Yet — with the backing, cooperation and input from the whole team — you can achieve even more!

With that in mind, we’d like to broaden our reach beyond the Engineering Team, in order to bring accessibility to other areas of the business and make improvements across our entire product suite.

We’d like to reach out to the community: to test our software, get hands-on advice and learn how to take things further.

Written by Dan Jackson, Front-End Developer at Crunch. Dan has a passion for all things tech and is always looking to learn something new. In his spare time, you’ll find Dan reading tech blogs or focusing on The Beautiful Game.

Find out more about the Technology team at Crunch and our current opportunities here.