Why is accessibility so important?
And we're not just talking about people with vision impairments either. Disabilities cover so many areas:
- Visual - low vision, blindness, colour vision deficiency
- Auditory - hearing loss, hard of hearing, deafness
- Physical - amputation, arthritis, fibromyalgia, Repetitive Stress Injury (RSI), tremors, spasms
- Cognitive, learning and neurological - Attention Deficit Hyperactivity Disorder (ADHD), Autism Spectrum Disorder (ASD), mental health, memory impairments such as memory loss, Multiple Sclerosis (MS), neurodiversity, and many more
- Speech - Apraxia of Speech (AOS), cluttering, dysarthia, stuttering, muteness, speech sound disorder.
And don't forget - it's not just the right thing to do, it's also a legal requirement. You don't have a choice if you're a public or private sector organisation.
How do we know if we are accessible enough?
Under GOVUK guidelines for public sector bodies, you have to meet at least AA standard from the WCAG2 guidelines. I consider this to be a reasonable baseline for all websites - public, private, or personal sites.
Following WCAG2 can be a bit long-winded but there are a lot of helpful checklists out there to help you digest it a bit more easily: Handy CodePen, WebFlow guide, The A11y Project checklist, and Not Checklist.
The new version of WCAG is on the horizon, and will make things much easier to understand and will cover a broader range of topics around accessible content.
What is WCAG?
Colour contrast
Adequate colour contrast (the difference between two colours) is a great place to start. There are around 2.2 billion people with a near or distant vision impairment, and over 300 million people with colour vision deficiency.
Making sure your website's colour scheme has enough colour contrast opens your content up to over 2.5 billion more people. Just think about that for a second. There are 8 billion people on this planet, and you might be preventing over 30% of them from using your site or service.
Colour contrast is easy to check for WCAG2 compliance. There are many browser extensions, apps, plugins and websites you can use.
A new colour contrast method
WCAG3 colour contrast uses a new method, known as Advanced Perceptual Contrast Algorithm (APCA) which scores differently, and gives different values depending on whether you're checking a light foreground against a dark background or vice versa.
This means that some combinations previously accessible to AA standard might now fail, and others that previously failed might now be accessible!
To meet AA standard under WCAG2, you'll need to ensure that your contrast ratio is at least 4.5:1 for body copy, and 3:1 for large text such as headings. This is calculated using some mathematical jiggery-pokery.
Font sizes
We live in an age where screen technology is absurdly better than even a few years ago. Most devices now have Retina quality screens so fonts appear much smoother and easier to read. Screen resolutions are much better now too. In fact, the current iPhone 15 standard model has a screen resolution of 2556px x 1179px which is much better than the standard desktop resolution of 1024px x 768px which was the 'standard' for a number of years prior to Retina screens.
There's no real reason to output small fonts on screen. From an accessibility point of view we should be building sites that allow users to control the font size without it breaking the layout, but as a sensible default we should make sure our body copy is big enough to be read without straining for the majority of users.
It's recommended that large text should be at least 18pt, bold text at least 14pt, and body copy at least 12pt (but no smaller than 9pt). The CSS value of 1pt is 1.333px, so this translates (roughly, rounded up) to large text at 24px, bold at 19px, body copy at 16px and nothing smaller than 12px anywhere.
Winning
Descriptive images, audio and video
Any time you use an <img>
or a <picture>
element, you need to add an alt
attribute. If you're adding the image purely for aesthetic purposes and describing it would add no context or purpose to the page content, you can leave the attribute empty.
If it does add context, or isn't purely aesthetic, and users will benefit from a description of the image should they not be able to see it, the alt
attribute should appropriately describe the content of that image. You don't need to start with 'An image of...', or 'A photograph of...' because screen reader software will announce images as such when they find them.
Your alt
text should be descriptive purely of what can be seen. If it's a logo, you can just say 'Logo of Company Name, ltd.'. If it's a photograph, describe the mood, tone and actors in it. If it's a photograph of an incredibly happy, bouncy dog playing with a frisbee in a park with lush green grass on a mid-summer's afternoon with the sun starting to set... maybe write that.
If you're adding audio or video elements to your page, you should ensure you add transcripts for audio, and at least subtitles for videos. If you can also provide transcripts and Closed Captions (CC), then that's even better.
What's the difference?
Link text
It's a tale as old as time. But this isn't Beauty, it's the Beast. 'Click here' or 'Click here' is terrible link text. Not only do people these days often 'tap' instead of 'click', users who visit with assistive software might do neither of those things, and might 'activate' a link instead. And let's face it, link text like: 'Click/tap/activate/push/press here' is even worse.
When a user sees a link, it should feel like it has some sort of context around it. The bit that you can 'click' should give you a good idea of where it'll go. If it's an internal link or an external link, whether it's even something you're interested in reading about at all, or if it's a link to download a file, or go to a form instead of a content page. All those should be considered, and they should all be obvious to your users.
There are good and bad examples of link text, but if you just use a little common sense, it's not a difficult task to get right. Google will even tell you how to do it better for SEO and for your users.
Understandable content
Most people don't read properly on the Internet. Unless they're expecting longform content (like this!), they're likely to scan for just the information they need and leave as quickly as possible. In most cases you should keep your content as concise as possible, and use language as simple as possible without losing meaning.
People will digest your content better if you use shorter paragraphs, well spaced-out content and sensibly section your content with headings and sub-headings. Using lists are also a great way to break down content into smaller, manageable chunks.
Remember to emphasise key points so they stand out. Avoid using uppercase for large blocks of text. Not only is it less 'shouty', but it'll also be easier to read for users with reading difficulties such as Dyslexia because lowercase letters tend to have more distinguishable differences between characters.
Try to avoid using made up words where possible, unless it's necessary or makes sense in context. Remember that content you write could be read by anyone. There could be many different barriers to them understanding your text:
- English might not be a user's first language
- Users may be Dyslexic
- Users may have low vision or blindness
- Users may have an intellectual disability
- Users may have ADHD
- Users may be in a rush
- Users may be young
- Users may be old
The simpler, shorter and easier to break down you can make your content, the more accessible it will be for everybody.
Clutter
There's no reason to cram everything into a small space on screen. Users know that they can scroll. Stop trying to fit everything important on a page into the initial viewport. Once you make everything important, nothing is important!
Cluttered interfaces and content can be triggering for some users, especially those with ADHD. Make sure your text content has adequate line-height
so there's enough whitespace between lines of text. Ensure there's a decent margin between paragraphs and around headings and sections so it's less stressful to look at and more easy on the eyes and brain to read.
WCAG2 requires you to have a line-height
of at least 1.5 times the font size, and a margin of at least 2 times the font size. So if your body copy is 16px, your line-height
would need to be an equivalent of at least 24px and your margin between elements would need to be at least 32px. With CSS, you can use percentages, decimal fractions or rem
values:
body {
font-size: 16px;
line-height: 1.5;
}
p {
line-height: 150%;
margin-bottom: 2rem;
}
ul {
line-height: 1.5rem;
}
Keyboard navigation
Not everybody uses a mouse to interact with your site - even on desktops. There are many people who use assistive software might control their computers with their voice or by keyboard shortcuts. Ensuring your site is keyboard accessible is vital for those users.
You should always test each page using only keyboard for navigation to ensure that you've created logical, hierarchical and semantic content.
Make sure you write sensible link text, use valid, semantic HTML and ensure that you've used the correct headings in the correct order too.
Anything you should be able to 'click' with a mouse, or 'tap' with a finger should be able to be 'activated' by a keyboard user too.
Valid and semantic HTML
People have a preconception that HTML isn't a real programming language because it's so easy to pick up. But like CSS, the barrier to entry is low, but to master it could take a lifetime. It's very easy to do HTML wrong. It's very easy to make HTML inaccessible by doing it wrong.
There is plenty of documentation out there to help you get this right, and you can even validate pages using a HTML validator service.
Valid document outline
The document outline is the structure of your document; the order in which you put your headings, and whether or not page sections are correctly titled.
Although technically HTML5 allows you to have multiple <h2>
elements on a page, from an accessibility perspective you should only have one, it should be unique and should adequately describe the content.
Any other headings should start from <h2>
, and sub-headings under these should be <h3>
, and so on.
It sounds obvious, and it sounds simple, but when you're not paying attention or checking it as you go, or if you work on a small part of a much larger site, this is very easy to get wrong.
I use a browser extension called headingsMap (available for Chrome and Firefox).
This extension can show you the general document outline (all the headings on the page, and whether or not they're in the right order), but it can also show you the HTML5 outline - a view that will tell you if you have sections on the page missing a title, such as if you've used a <section>
and not put a heading as the first element.
ARIA
ARIA stands for Accessible Rich Internet Applications, and is a number of attributes and roles that help give your HTML additional context or assistance for assistive software.
A lot of the semantics that ARIA set out to provide are now part of HTML5 and browsers can determine roles much better than they used to. For example, you no longer need to use <div role="banner">
or <footer role="contentinfo">
because those roles are implicit when you use the correct HTML elements <header>
and <footer>
, as well as other semantic elements.
ARIA roles and attributes can still be very useful when adding functionality to a page, like a mobile menu, an expanding accordion section, or a carousel (if you really, really have to). Using JavaScript you can set state and context to allow assistive software to aid in understand the current state of the page, what is and isn't active, what's hidden and what's shown, and whether or not something is pressed or expanded or not.
Just be aware that using too many roles and attributes can adversely affect your pages and can make them less accessible. I'd offer the same advice as I do for people wanting to add more JavaScript to pages: Only add what you need to make it work better.