Why isn't your website accessible?

In the UK, the Equality Act 2010 requires your website to be accessible. Ignoring the Act at the design and coding stages of your product could have repercussions as you discriminate against your users.

How long has my website had to be accessible?

The Disability Discrimination Act 1995 came into force in 1996. Since this time it has been a requirement not to discriminate against your users based on their abilities. It may surprise you to know that almost no websites currently produced in the UK comply with these discrimination regulations.

Lack of awareness, ignorance of the Equality Act, and lack of technical skill are all cited as reasons for websites to lack accessibility features. Go to any web or digital agency sites and you will probably notice that most of them lack any kind of statement about accessibility in their products. These companies should be avoided; it is your responsibility to provide equal access to your users and it's you who they may sue for discrimination.

Aren't accessible websites ugly and boring?

This website is fully accessible. It's not necessarily the most interactive website out there, but that was more my decision to make it this way rather than a constraint of accessibility. Making a website accessible is actually quite straightforward if you follow the guidance freely available from the World Wide Web Consortium, and you will only be limited by your own technical abilities.

Who needs an accessible website?

If you're just thinking about the blind then you've forgotten the partially sighted, users who've lost limbs, lost fine motor control such as that caused by Parkinson's disease, have cognitive disabilities, and the most obvious – everyone else too. An accessible website will have an easy, obvious user interface (UI) and provide an excellent user experience (UX).

How do I make my website accessible?

This isn't actually too tricky. Once you're in the know, you'll be strongly recommended to follow the W3C WCAG 2.0 to Level AA. If you know how to make semantic and valid HTML then you're already halfway there.

It's always best to validate your HTML before you check your accessibility, and the W3C Markup Validation Service is a great tool to help you do this. Checking your code for semantics is the next step; making sure your heading levels are in order and not missing (e.g.: you don't have an H4 following an H2, and don't have more than one H1 on any one page unless it's inside its own section element), and checking that you've used the correct element to markup your code. Nav elements for navigation, H1-H6 for headings – that sort of thing.

Then you can use WebAIM's Wave tool to check some basic accessibility features on your site. This won't catch everything, but clearing all of the errors and warnings from this tool will vastly improve the accessibility of your website. Don't forget the contrast section – using colours that are too similar is a definite failure. As we age our eyes resolve less contrast; grey text on a grey background can become impossible to read.

Things to consider which aren't always caught by these tools include not using colour as a means to direct user flow. This makes sense when you consider that a big red cancel button and a big green continue button are of a similar colour to a sufferer of red/green colour blindness. Text size is also important because although it can be changed in a web browser, many sighted users that only struggle with the smallest text simply won't bother. Never put important information in small print which may be missed – poorly sighted users would have a good case against you if they missed something important because you made it inaccessible in this way.

Bypass blocks are an important feature and allow a keyboard user to skip your navigation sections. This is especially important if you have an excessively large navigation, such as that you may expect from an online catalogue style website.

Dynamically loading content, such as that now becoming much more common from JavaScript Frameworks, can be a real problem. In this instance I'd recommend testing with a screen reader such as JAWS or Window-Eyes to make sure the user is notified of altered content. The role and aria attributes of HTML elements can assist in this endeavour, but note that the WAI-ARIA specification explicitly states that you should not use roles and ARIA where a semantic element is available instead.

Scolljacking is a definite no; some people think it looks fancy but for most of us it provides a horrific UX and a poor UI. If scrolling a webpage takes longer because it now smooth scrolls on its own, is that benefitting your desire for something pretty or your user who only wants the information as quickly as they can consume it? Almost every scrolljacking site I've used has completely broken when trying to navigate the page by tab, too.

Carousels. We've known that carousels which contain information have been bad since their inception, but some agencies will continue to use them. Studies have shown that most users will never see past the first slide, and those that auto-scroll induce much frustration.

Mystery Meat is another thing that should be banished from your website. I never want to see an unlabelled icon again, thank you.

Are there any other benefits to an accessible website?

Absolutely. If you've gone to the effort of making your site accessible then it's likely to be valid, meaning that it won't break in the future as browsers update themselves, the semantic and valid code will both benefit your search engine optimisation (SEO) as web spiders will find it easier to crawl and categorise your site, and Google is forever improving its algorithms to move better sites to the top of its index.

This sounds like a lot of effort for little gain. Why should I bother?

Aside from the benefits listed above, it's the law. Your website must be accessible, and you can't use the excuse that "no one else does it" either. Let me tell you that companies have been sued for millions over their accessibility – do you want to be next?