Employee Resource Group Creation

As a Frontend Developer at AO.com, I co-founded the Accessibility Guild, an internal employee resource group that promoted accessibility as a priority within the organisation.

The Project

Over the course of several projects, it became apparent that there were some gaps in accessibility knowledge in different parts of the business. There was a need to create a baseline understanding and a way to communicate the importance of accessibility to other parts of the business that weren't always in regular direct contact with developers.

The Action

I co-founded the guild with two other members and we met regularly to plan events and talks around accessibility. We gave a number of talks on specific accessibility topics, including demonstrations of assistive technology like screen readers.

The guild welcomed technical and non-technical participants, allowing anyone to come to meetings or give talks. This meant people from different roles could learn from each other and understand how accessibility was relevant in their day to day work. Designers, developers, testers and business roles could all interact and exchange ideas.

We also established a weekly remote drop-in session; a one hour time slot where anyone in the business could join the call and ask questions or listen in to discussions. Occasionally, this would become a mob coding session to problem solve an issue that someone was having.

The Outcome

The guild acted as a first point of contact for anyone with an accessibility concern. We had an active Teams channel for continuous discussions and a Sharepoint to host meeting recordings, documentation and articles.

As a result of the drop-in sessions, we collaborated with different teams to research tools or approaches to improve or resolve accessibility issues on certain projects. One example was a comparison between jest-axe, Eslint-plugin-jsx-a11y and cypress-axe for automated testing, which led to some interesting discoveries of the things each caught and missed. It highlighted the limitations of automated testing for accessibility and emphasised the need to use multiple tools, rather than just one, in order to get a good level of coverage. Two different teams made decisions about accessibility testing tools based on the research, and added these into their projects. As a result, tests would automatically run to check for the most common accessibility violations every time new code was added to the projects.

The guild didn't just work on customer facing problems, but also internal issues. When a question arose about a particular branding decision, I worked with a designer to raise it higher within the business. We met a number of times with the branding team and were able to voice our concerns so that future decisions would be made with accessibility in mind.