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 tag, and can go all the way down to
an . You can use as many or as few of these as you like, but they must start
with an 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 tags in a page is no
longer a huge taboo. Google themselves state that you can have up to three ’s
in a page that are used to garner
its content. The real importance is that those ’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:
Was that key the spacebar or the enter button (common keys used to interact with buttons, forms, links, etc.)?
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:
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
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.
Source:: Kraken Technologies