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 jargon-filled that you quickly stop reading. You download Chrome add-ons to test your site and see hundreds of errors. The looming fear of “is it illegal to not have an accessible website?” It’s daunting. If only you knew earlier! You could have implemented standards!

Fear not! Here’s list of basic rules around accessibility to help get you started.

The Rules

Semantic markup is your friend

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 has a great resource to help you know which elements you should be using and when.

Use ARIA where you can

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.

ARIA Examples

  • aria-label
    • quite handy to pop onto links to tell screen readers where the link goes
  • aria-expanded
    • think of all those accordions you’ve ever implemented. Or drop-down menus. Aria-expanded is what tells screen readers what element is meant to be visible to the user at any given time.
  • aria-describedby
    • tells screen readers which element of a page describes it. Like error messages.

Navigate without using your mouse

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.

  1. Navigate to your key pages just using the keyboard
  2. Try and submit your form without using your mouse

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, use 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 a <div> into something like <button>. <div> isn’t included in taborder by default so you need to set tabindex=0 for it to be included. You do, however, need to be careful.

Check your tables

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.

IMAGES SHOULD HAVE ALT TEXT

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.

Use a contrast analysing tool on your colour choices

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.

Typography matters

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

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!

Placeholder text

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.

Time limits

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.

Group your inputs

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.

Keep it short or cut it up

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.

Conclusion

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!