Making Octopus accessible for everyone

Ashley Firth writes about making the octopus website as user-friendly as possible...

The Home Office recently published guidance on how companies can use web design and development to make sites accessible to everyone. They outlined rules to help those with low vision, physical or motor disabilities, dyslexia, users on the autism spectrum, or those using screen readers (software that reads webpages or displays them on braille readers).

We took this as the perfect opportunity to audit our website and see if we were providing all of our visitors and customers with an easy and enjoyable experience. The results of this audit were good, but not perfect, so we got to work. Here are some of the checks we ran and a few areas in which we improved – hopefully our progress will encourage others to do the same.

Alt text

The first thing we checked was that the text sitting behind the images of our website actually described the image’s meaning, rather than its function on the page. For example, the alt text for our “About Us” page banner should be “an image of the Octopus Energy operations team,” and not “About us banner image.”

Headers

The next step was looking at page headers. We needed to make sure that the headers organised the page in the right way, in a logical, hierarchical structure. We used a specific mapping program (Headings Map chrome extension) that showed us the headers’ positions and we optimised this so that screen readers gave each section the right emphasis.

HTML5

Then, we had to make sure that our page was correctly structured in HTML5 (the code that describes webpages). By coding the site correctly, each element of the page works in harmony – nothing is “marooned” without context. This also means users can generate a table of contents using assistive technology, helping them to navigate the site.

Tab index

Many users prefer to use just a keyboard, or can only use a keyboard, to navigate a website. So this was probably the most important addition to the site throughout the audit. For pages such as articles this is relatively easy as all the content is there, but for core flows on our site, such as getting a quote, breaking it down and signing up, this content exists over multiple pages, within modals and dropdowns, and requires user input.

Most browsers are very good at allowing keyboard interaction with elements such as buttons, links, and form inputs. However, sometimes design and UX dictates custom components that stray from this, and they need to be just as accessible. Tab index allows you to define a sequence that users follow when they use the Tab key to navigate through a page. With this, you can ensure that users have access to all the information on a page in an order that is both clear and logical. Once we’d completed this, we went through some additional stages making sure that once the elements of page could be focused on, that users could interact with them too.

Contrast levels

This is a tricky issue to spot sometimes, but easy to test. W3C Web Content Accessibility Guidelines state that the contrast level between foreground and background colours should be at least 7:1 for regular text to beAAA compliant. This is especially important for users with low vision, who may have trouble focusing on text coloured similarly to the background.

As it would be incredibly difficult assessing contrast with the human eye, there are quite a few helpful online tools. The Webaim contrast tool is what we used (you submit the two hex codes manually), but there are tools that can assess a whole page, such as Webaim Wave. The Google Accessibility developer tools extension also raises any issues with contrast when you audit a page.

And many more…

Some minimal effort “quick wins” that really help customers:

• Raising the base font size to help those with low vision. The gov.uk site has 19px as the lowest font size, ensuring everyone can easily read their content (we use 18px).
• Ensuring that action buttons state what you’re about to do, instead of being vague. For example, a sign up button should say “Sign up” and not “Click here”.
• When using icons or colour to convey meaning or action, always support it with text. Colour only impacts those with low vision or colourblindness, and the use of figures of speech, idioms, or visuals that could be misinterpreted can affect those on the autistic spectrum.
• Don’t have large text in paragraph tags masquerading as headers. The visual meaning attributed to it will never be conveyed via a screen reader.

Tools

Finding the problems are sometimes just as hard as fixing them. These were the best tools we found over the course of the audit:

• Google accessibility developer tools (ran in the ‘audit’ panel of developer tools)
• Headings map extension (Chrome) – for HTML5 outline and heading structure
• Voice over for Mac – screen reader
• Validity extension – for inline W3C validation
• Experte: Accessibility - Automated top-level testing for accessibility issues. It can check hundreds of pages, just by entering your home page URL. Good for finding and solving low-hanging fruit.

Inspiration

The Home Office’s excellent visual posters of the Do’s and Don’ts of Designing with Accessibility in Mind.

How have the changes affected our customers?

Users can now:

• Get a quote, interact with it, and sign up using just the keyboard or a screen reader.
• Perform regular tasks within the members area such as submit a meter reading, view their bills or edit their details using just the keyboard or a screen reader.
• Use screen readers with more ease, as all pages follow a logical informational and heading structure, with descriptive alt tags for images.
• Easily read all content on the website, as it has a passing AAA contrast rating.
• Clearly understand the purpose of links and buttons, with descriptive action text and no instances where only imagery is used to convey meaning.

I am proud of the progress we’ve made on the site’s accessibility, but no site we’ve seen is perfect all the time. We’ll diligently maintain the new standards we’ve set for ourselves, with the goal that nobody will be excluded based on the way they interact with our site.

Ashley Firth,

Head of Interfaces