Our Web Accessibility Hack Day at Attest

Here at Attest, we’ve realised that we need to be better at accessibility when building our product (a web-based survey editor and results tool).

In order to do this, we’ve taken a two-pronged attack — auditing our existing product for accessibility, and increasing internal knowledge and understanding of web accessibility so that we can consider accessibility when we are building new features.

To do this we decided to run a fun accessibility hack day last month, the aim of which was to help educate and increase awareness about web accessibility, show the kinds of issues that people face, and figure out how these issues can be resolved by keeping accessibility in mind.

We wanted to include as many people from Attest as we could from all corners of the business. We ended up with around 20% of the company involved on the day.

The hack day itself

We used the first part of the day to audit where we could improve accessibility. We started with an introduction, guiding participants through how to find issues and how to report them.

Some things we asked people to look out for included:

• ensuring the screen readers can describe content correctly.
• checking the colour palette that we use, to help those with sight issues or who are colourblind.
• making sure that the website does not require a mouse and can be used with just a keyboard.
• Using plain and unambiguous text to make it easy to understand.

We had our own checklist of issues that we were expecting to find — inspired by the excellent Vox Media Accessibility guidelines and the A11Y Project checklist.

We also made heavy use of some Chrome plugins, such as IBM Equal Access, WAVE and Accessibility Insights for Web.

We split into small teams, each team consisting of at least one frontend Engineer and one designer.

The teams were assigned a certain area of the website or a product feature — tasked to find and report issues, and then later in the day work on solving the problems.

To make the day interesting, we made it into a little competition. We had a scoring system with points assigned for finding issues and fixing them. To ensure we included everyone (including the technical parts of making code changes), more points would be earned if a non-engineer fixed the issue (often assisted by an engineer). Prizes were handed out at the end of the day to winner team members.

At 5 pm we had a short wrap-up video call, where we announced the winners — based on the number of issues reported and fixes added.

What we achieved during the hack day

• 143 issues found (approx 10% were duplicates)
• 25 pull requests (code changes to fix the issues)
• And we fixed 8 issues during the day
• We also had 6 of those pull requests added by non-frontend engineers, which was great to include them and show them our normal day-to-day processes

What we’ve achieved since the hack day

A few weeks have passed since the hack day. The biggest and most important outcome from the day was that we have much more awareness of accessibility issues.

Our frontend engineers have started to code things with accessibility in mind, and test new features of our survey editor using only the keyboard and even using screen readers.

We have also started to ensure that when we split a large feature into small tickets, we always include a story to ensure it is accessible before it is marked as ‘finished’.

We found that most accessibility improvements were not technically very hard, we just needed to be more aware of them.

Since the hack day, we have all noticed more pull requests which have accessibility in mind. We have also ensured that all new work adherers to WCAG 2.1 AA standard.

What’s next?

Although the hack day was a single day event, we are still actively working on some of the issues reported from the day. We aim to get all issues reported on the hack day fixed soon.

In the interests of increasing accessibility, we will soon be conducting an in-depth formal evaluation of accessibility on our survey platform and dedicating engineering time to get everything up to the WCAG 2.1 AA standard.