Improving accessibility at Octopus Energy

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, dyslexia, users on the autism spectrum, or those using screen 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 tags

Ever questioned the importance of alt tags? Have them read out to you at speed by a screen reader and you’ll be persuaded. The only real rule here is to ensure that the text used actually describes what is in the image, rather than the image’s purpose within the page. For example, the alt text for our “About Us” page banner should be “an image of the Octopus Energy operations team,” rather than “About us banner image.”

Heading structure

All headers in a web page should have a hierarchy, beginning with the most important header to the least, and the markup of the page should reflect that. In HTML, the most important title is an <h1> tag, and can go all the way down to an <h6>. You can use as many or as few of these as you like, but they must start with an <h1> and must always be used in order. The reason for this is that heading tags denote importance to screen readers, and out of order headers may well confuse a user. Proper heading structure also benefits the SEO of your page.

You can check this using the Headings Map chrome extension. When run on a page, this generates a tree based on the headings on your page, and highlights any that are out of place or have been skipped entirely

Note: To dispel a common myth, having multiple <h1> tags in a page is no longer a huge taboo. Google themselves state that you can have up to three <h1>’s in a page that are used to garner its content. The real importance is that those <h1>’s remain on the same hierarchical level as each other, and that as you make your way down the heading ladder, no rung is skipped or added out of place.

HTML5 outline

That same extension is also terrific for assessing your compliance with HTML5 outline. This is the structure of a document, generated by the document’s headings, form titles, table titles, and any other appropriate landmarks to map out the document. The user agent can apply this information to generate a table of contents, for example, which could then be used by assistive technology to help the user navigate.

The key here is to make sure that each section has an appropriate header, and that no parts of the page are “marooned” from a screen reader’s perspective without context. Although this feature has been in the W3C spec for years – (2008), it has only recently gone beyond a theoretical stage. However, it stands to make the whole page – not just it’s headers – more digestible for screen readers.

Off-screen headers

Whilst auditing the site, I found that certain sections lacked context. Most notable was the navigation, which sat at the top of every page without a title. Very few menus call for a title, so a small utility class was used to add these headers but place them off the screen visually so they didn’t impact design.

Use correct HTML5 tags

There’s nothing new I could write here as it’s such standard practice now. And you’re doing it perfectly… right?!

Tab index

This was probably the most important addition to the site throughout the audit. Many users prefer to use just a keyboard, or can only use a keyboard, to navigate a website. 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.

DOM interactions

Tab index helped a keyboard user focus a particular element, but this didn’t guarantee that they could actually interact with it. For components created with divs and spans, a browser wouldn’t be able to recognise the role they were designed to play without appropriate markup.

Therefore, we set up listeners that checked for the following when a key is pressed:

  1. Was that key the spacebar or the enter button (common keys used to interact with buttons, forms, links, etc.)?

  2. Is there an element currently focused (either naturally by the browser or through tab index)?

If these both return true, a click is triggered on the element. An additional check is made for elements that use the “aria-role=‘button’” attribute, as those are typically only interacted with using the space bar.

Focus styles

Once we’d overcome the tab indexing issues, we needed to ensure it was obvious to users which part of the site they were focused on. There are default browser styles for focused elements, but it’s fairly common for developers to apply blanket rules to these selectors due to the less than preferable blue line it shows when a user clicks them.

As they’re seen when a user clicks the element as well as when it’s focused via keyboard, focus styles need to tread the line between being obvious and not negatively impacting a page’s design. Nice alternatives to the typical outline rule can be box-shadows or changes in background and border colour.

Contrast levels

This is a tricky issue to spot sometimes, but easy to test. W3C state that the contrast level between foreground and background colours should be at least 7:1 for regular text to be AAA 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.

Semantics

This isn’t solely focused on accessibility, since all aspects of page markup are intrinsically linked to a good page. You would struggle to have a good heading structure or HTML outline without having semantic markup. Also, passing validation gives you that warm, fuzzy feeling inside. We used the Validity Chrome extension to test our pages on the fly.

And many more…

Some minimal effort “quick wins” that can 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:

Inspiration

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

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.

Posted by Ashley Firth Head of Front-End Development on Jul 22, 2016