Accessibility is one of those things you got taught at uni. You sat through the same tired lecture about door-frames which were too narrow, teapots which didn’t pour properly, and how colourblind people can’t tell the difference between red and green.
What didn’t seem to get covered much, was actually how to *do* accessibility.
So now you’re out in the world and you get asked to design a website which meets WCAG 2.0 AA standard. What? You try and read the guidelines but they’re so heavy and
Fear not! Here’s list of basic rules around accessibility to help get you started.
While it is tempting to just call everything a div and be done with it, its not very helpful for anyone using assistive technology.
HTML 5 has brought new semantic markup elements into the web and they should be used (where applicable). This really helps assistive technology to make sense of a page to its users. It also helps search engine bots prioritise certain content which you are telling it is important.
Mozilla
ARIA (Accessible Rich Internet Applications) has roles, states, and properties which tells browsers (and assistive tech) what bits of your website are. They are invisible to sighted users but can be invaluable to those using screen readers.
If you’ve used the correct semantic markup, your site should be easily navigable by keyboard. There’s an awful lot built into browsers to help people who can’t use a mouse but when you start using <div>
rather than <button>
it goes haywire.
So before you launch your site into the wild, try two things.
A form which allows a user to tab through easily enough but can’t submit when they hit Enter isn’t much use.
If you need to add a little something to your elements, tabindex
Tabindex
is used to tell browsers that an element can be focused on. This I’ve found is most commonly used when you’ve repurposed <div>
<button>
. <div>
isn’t included taborder
tabindex=0
While we are past the days of using tables for layout, they still feature (rightly so) in websites today. But, that doesn’t mean they’ve been built well.
Often, people miss <thead>
and <tbody>
when creating their tables which skips out on telling assistive technology how the table is structured. Webaim have a great resource about how tables should be structured for optimal accessibility.
I cannot stress this enough. Your images should include an alt
attribute which describes a description of what the image shows. You can also provide additional content with a title
attribute.
For bonus points (and a more flexible solution), you can also use aria-labelledby
on a separate element to give more information to your users.
I am very much of the opinion that WCAG AA should be used as a minimum standard in regards to colour contrast. This means you should have a contrast ration of at least 4.5:1 between your background colour and your text colour if your text is below 24px (below 19px if the text is bold).
There are a number of checkers out there but for starters, WebAIM has one you can use.
In general, you should pick fonts which are easy to read. This will probably mean keeping away from cursive fonts, especially at smaller sizes.
The size of text you choose should be easily read on mobile and tablet, 12px used to be the standard but its gradually gotten bigger. Line height should also be around 1.5 in paragraphs as it makes them easier to read (1.2 is the browser standard).
Forms are often critical parts of your website or app. They’re how users sign up, subscribe to your newsletter, and buy products. So you should really make sure that as many people as possible can fill them in!
SHOULD NEVER BE USED FOR VITAL INSTRUCTIONS
Seriously, placeholder text is great for giving a bit more context to an input box but that context completely disappears when a user clicks into the box. Use the input’s label (which you should have) and helper text instead.
Wherever possible, forms shouldn’t have time limits on them. Screen readers aren’t exactly the fastest method of using a website or app and users with cognitive issues sometimes need a bit more time than others to fill in your form.
Use elements like <fieldset>
and <legend>
to group elements together in a way that makes sense. This helps by giving each input a bit more context around what it is you’re wanting from the user and helps to stop confusion between shipping and billing addresses etc.
Ideally, your form should be as short as possible. But if you need to get a lot of information from a user, break your form up into pages or stages. Each page/stage should have its own set of instructions and contain like for like information (so shipping information on one page, then payment information on another). Just make sure and give your users an indication of how far through your form they are so they stick around rather than leaving.
Accessibility is big. There’s a lot to consider when you start getting into it but that shouldn’t stop you from trying. By making simple additions to your websites you can make them easier to use by thousands of potential users. None of these rules guidelines will turn you into an accessibility wizard but they’re a good place to start.
There’s a whole host of resources available for developers and designers out there, some of which I’ve linked to in this article. MDN and WebAim are probably my favourites for getting started with.
Good luck!