Our Approach to Accessibility

Every person should be able to learn and have their learning rewarded and recognised.

We firmly believe this, and it's what drives us to design and develop our application in an accessible and inclusive way. We know a lot of our current and future users will rely on assistive technology in order to do what they need to do. We don't want to be another obstacle for them - we want to supercharge their workflow and support them as much as possible.

That's why we have built accessibility into our process from the very beginning, and why we'll continue to do so with any feature we release in the future.

Our accessibility process

Whereas some companies tack on accessibility as an additional 'nice-to-have' after everything has been built, we opt to bake accessibility into our design and development process as standard, so we are consistently delivering a good experience for everyone.

Accessibility is a very broad field, but to give a few simple examples of how we design inclusively, we:

• Maintain an accessible design system - we ensure our design tokens and components meet certain standards (e.g. WCAG 2.1 AA) for things like contrast, colour and sizing. This makes building entire interfaces in an accessible way much easier further down the process because most of the decisions around the interface are already made and have already considered accessibility. There's less room for error on our part.
• Regularly review the UI with accessibility checkers - there are a number of tools we use to monitor the UI and dissect any potential accessibility issues in the interface before they are finalised.
• Optimise copy - we want all our content to be easy to understand and read, therefore we optimise it during the design phase to make it as simple and effective as possible.

We don’t stop at design though - we recognise that development plays a very key role in creating an accessible experience and so we continue to improve and monitor accessibility there, by:

• Considering assistive technology throughout the build - while developing a feature we will consider how someone with assistive technology would use the system. We build in a simple, semantic way to achieve as much compatibility with tools like screen readers as possible, and include aria attributes and alt text wherever relevant to ensure the interface is logical.
• Analyse how the app works with assistive technology - we use a number of automated tools to help us spot any potential accessibility issues. This includes tools like taba11y which helps visualise the tab order of a page and Google Lighthouse which detects basic issues on different pages and informs us of how to fix them.
• Manually complete tasks with assistive technology - we recognise that automated accessibility tests could never give you a full picture of the experience for someone using assistive technology, which is why we regularly complete tasks in the app using the same tools our users will rely on. Often, the automated tools have found most of the issues but we’ll spot one or two things that could be improved to really optimise the experience.
  

The result

Ultimately what we aim to achieve is that anyone who receives a credential through our platform can quickly access it and use it to prove their experience and skills. That’s our main goal.

We use the WCAG to guide our decisions and aim to meet their AA standard (often we also meet numerous AAA criteria, too).

As a result of all our hard work and planning, the app is consistently accessible across all areas (we don’t limit this strategy just to learners, we consider institutional users and recruiters in the same way). We are WCAG 2.1 AA compliant and achieve 100/100 on all Google Lighthouse accessibility audits.

However, we understand that there is no such thing as perfect accessibility, and so we welcome anyone (be it one of our users, or an accessibility specialist) to speak to us if they spot anything they think could be improved. We are committed to making the experience as good as possible.

Want more information?

We have an accessibility statement available here for you to read through, which goes into much more detail about our strategies and details which WCAG 2.1 specification criteria we meet.