Accessibility is always on our minds at SSE. Our design community talks about it often, and we promote in our cross-functional product teams at any opportunity.
Every accessibility issue has the potential to impact the 14.1m disabled people in the UK. So not only is addressing them the right thing to do, it’s also good business.
A change in UK accessibility regulations meant we needed to focus more in this area. To see how our service stacked up against accessibility guidelines, we audited one of our key journeys. In this article we’ll share our experiences to give you a starting point in your own accessibility journey.
And a good place to start is the access of access-ibility — how someone with a disability accesses your content or functionality.
How we got started… and how you can too
We were lucky to partner with an accessibility consultancy who audited our smart meter booking journey. This gave us a head start by listing our existing accessibility issues.
Not everyone can afford a third-party expert, but anyone can carry out an accessibility audit if you know where to start and what to look for.
Step 1 - Start with a checklist
Everyone loves a checklist. This accessibility compliance checklist from A11Y Project is a great start. It explains in clear terms what each guideline means and gives you a handy checkbox list so you can track your progress. There are a lot, so this is a nice touch.
If you’re wondering, ‘A11Y’ is an abbreviation for accessibility. There’s 11 letters between A and Y. You’ll see it a lot throughout the web.
Step 2 - Get out your magnifying glass
You’ll need to go through your product or service with a fine-tooth comb to discover where it falls short. This includes what you can see, and also what you can't see — the front end code that a browser interprets.
Even if you don’t write code for a living, if you’re in the digital space then understanding the basics of HTML, CSS, and JavaScript will be a huge benefit for you.
If you’re familiar with looking under the hood of a website then this shouldn’t be a problem. If you’re not familiar with HTML and CSS then this could be daunting, so it’s a good idea to pair with a friendly developer.
Go through each screen of your product or service one by one and document which accessibility rules pass, and which fail. Document this however makes sense for you, but a simple spreadsheet is usually fine.
It helps to have a structure, and if you record your data in a meaningful way it’ll help later when you want to analyse and sort that data.
We used this structure:
| Page 1 | Page 2 | Page 3 | ... | |
|---|---|---|---|---|
| Guideline 1 | ||||
| Guideline 2 | ||||
| Guideline 3 | ||||
| ... |
A matrix of screens along the top, and guidelines listed down the left hand side.
For each screen we documented which guideline passed and failed, why it failed, and where on the screen it was. Depending on how many issues you discover, you might end up with a big spreadsheet, a little like ours:
Step 3 - Get to work
Once you’ve completed your audit, you’ll find the results can be divided into two categories: design and content issues, and implementation issues.
Tackling design and content issues
First, speak with your design and content people. Design will need to review any design components which failed and provide updated specifications. And Content will need to review content flow and hierarchy, page structure, and alternative text for images and other rich media.
For example, Design may need to update interface elements’ focus states with higher-contrast colours to meet an AA accessibility standard:
WCAG 2.0 level AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. WCAG 2.1 requires a contrast ratio of at least 3:1 for graphics and user interface components (such as form input borders)
— webaim.org
Design will need to update their design system or documentation with any changes and new design patterns. This ensures future development work won’t undo any improvements made.
Handy tip: the close buttons for modal popups are often forgotten when it comes to focus states:
Content will need to update copy documentation (or whatever single-source-of-truth you use) with changes to alternative text — alternative text is written copy that describes the image it refers to for use by people with visual impairments.
Handy tip: you’ll likely have two types of images in your system:
- Decorative - images used for illustration and aesthetics
- Non-decorative - images which convey some form of meaning like content, system state, and progress.
To meet accessibility standards, non-decorative images must include alternative text to communicate what the image contains to non-visual assistive technology.
Decorative images should have no alternative text, so browsers and screen readers (among other technologies) know to ignore them. The HTML syntax should be: <img src=”url-of-asset” alt=“” />.
Tackling implementation issues
Implementation issues cover how the product was built. Even a well-considered design that fully meets accessibility guidelines in design software can be implemented with severe accessibility problems.
You’ll need to work with your developers to address these issues. They’re experts, and there may be other considerations you’re not aware of. Work openly and collaboratively to find solutions that work best for your team.
Things to look out for
HTML parsing errors
To achieve the basic WCAG Level A compliance, you need to ensure that your product or service conforms to HTML standards and there are no validation errors. As frontend technologies become more complex, there’s more risk of releasing something which works
but breaks long-established HTML standards. Screen readers rely on HTML to convey site content, so you should actively monitor this.
Handy tip: only two of nearly 150 HTML code elements have no built-in accessibility features: <div> and <span>. That’s because these tags are generic containers and don’t impart any additional context about the content they contain. Think about the content you’re trying to communicate and choose the appropriate HTML tag — there’s always one to choose from.
There are nearly 150 HTML elements. Only 2 have no semantic meaning. Guess which one.
— Segun Ola (Inspector General of a11y police) (@segunolalive) January 5, 2020
DIV and SPAN. The only HTML elements that convey absolutely no meaning.
In an attempt to improve accessibility, many demonise the div and span.
People abandon the DIV for the SECTION 🙂
Buttons and links
HTML links and buttons convey different meanings, so be careful to use them appropriately.
Screen readers handle links differently to buttons. All links and buttons are tab-able, but pressing the Space or Enter keys will trigger a button, whereas only the Enter key triggers a link.
Generally speaking:
- use links to navigate between screens or websites
- use buttons to trigger actions like submitting a form, downloading a file, or updating a record
Keyboard tab order
If your product or service includes complex interactions like a calendar or a multi-level navigation menu, think about how someone would navigate it only using their keyboard. Consider if it’s best to have an entry and exit point so they can skip over areas if they need to. Imagine having to tab through a whole calendar just to get to the content which follows it!
Similarly, provide a way to skip long navigation menus. You can do this in a way where sighted visitors won’t see it, but it provides a useful option for those using screen readers or navigating by keyboard, switch, or other forms of assistive input.
Keyboard traps
A keyboard trap occurs when someone can enter a webpage element or component using the keyboard, but cannot exit it through use of the keyboard alone.
This is frustrating for people and may stop them using your product entirely. Combine this issue with missing focus states, and you’ve got a poor experience for anyone relying on their keyboard to navigate.
🙌
Fixed it all? What’s next?
Once you’ve addressed the accessibility issues you found, is your product or service fully accessible now?
Well, sort of, but also not really.
Someone with a disability can now access the content or functionality of your site in the same way that someone without a disability can. This is a great first step. Accessibility needs champions so be vocal about any changes you’ve made. Bring your findings and changes to different teams, spread the word, and encourage others to do their own accessibility audits.
You’ve done everything you can fix the current implementation of your product or site. But don’t stop there. If you really want to find out how your product or service is used by people with disabilities, do some usability testing.
Take a step back and start thinking about how you can change your company culture and processes to consider accessibility throughout your product lifecycle. Start thinking about how different disabilities affect how and when people access your site.
Look out for our next article where we follow up our accessibility audit with usability testing. We invited people with varying access needs to talk to us about how they use technology to navigate their digital lives. We found out first-hand how our website performed and the feedback was invaluable.
Fixing the access part of access-ibility is only the beginning of your accessibility journey...