For everything you need to know about accessibility, check out Web accessibility – Everything you need to know, on Programming Duck.
Disclaimer: I’m not a lawyer. This article only represents my personal opinion and current understanding. It is not legal advice. Please consult a lawyer for information on the legal aspects of accessibility.
This article examines why you need to know about accessibility. Other than being something which many jobs probably require you to know, there are some very strong reasons for knowing about it.
Accessibility is a legal requirement
Accessibility seems to be a legal requirement in many countries / continents all over the world. This includes USA, Europe, UK and many more.
For example, companies in the UK have to meet the international WCAG 2.1 AA accessibility standard and publish an accessibility statement. This is stated on the UK’s government guidance page on web and app accessibility.
Other countries probably have similar requirements.
If your website or application fails to meet these requirements, it doesn’t necessarily mean that it will get sued. However, to really be safe, you should probably try to meet them.
For more information on accessibility laws, please see:
It’s the right thing to do
There isn’t much to say on this point. Making your product accessible and usable by everyone is the morally correct thing to do.
Inaccessibility can lose your company market share
- 71% of individuals with disabilities will abandon a website that’s difficult to use
- 1 in 5 people in Australia have a disability. 1 in 4 people in the US have a disability. 44 million people aged between 15 and 64 (14% of that age group) in the EU have reported a basic activity difficulty.
- Overall, you could be losing out on up to 25% market share
Better for your employer: Better accessibility, more efficient development, saves the company money
Since accessibility is a legal requirement, someone has to make sure it’s done properly.
That can be the developers of the company, a third-party consultancy (which would perform accessibility audits and provide instructions on how to fix accessibility problems), or both.
If developers know about accessibility, then they can do most of the required work themselves. Then, the third-party consultancy can audit it and find anything that has been missed or anything that can be improved.
Having two teams working on accessibility is better than having one team working on it. It means that less things will be overlooked. This means that the accessibility of your website will be better.
It’s more efficient
In short, fixing problems now (or as early as possible) is cheaper and more efficient than fixing them later. This is a general principle in life, it doesn’t only apply to programming.
The same applies with accessibility work. Most of the work that developers have to do for accessibility is really easy. It hardly takes up any additional time. It can be done as the developer works.
On the other hand, if that work is not done at that point, then the third-party consultancy will have to handle it later. Here’s what the process would probably look like:
- The consultants will spend time testing website accessibility. They’ll find multiple issues.
- They’ll take detailed notes of those issues and why it’s important to fix them.
- They’ll write detailed instructions for developers, with multiple options and recommendations, on how to fix those issues.
- They’ll create a report out of those notes to provide to the company and the developers.
- The issues from the report will be converted into stories, then estimated, then pulled into a sprint.
- A developer will start a story about an accessibility issue. They will code the fix and test it manually to ensure it works. They’ll also run the automated tests and do other required things based on the development process in the company. They’ll create a pull request, wait for someone to review the code, make any changes requested in the code review, re-test everything and finally merge the code when everything is done. Then, QA will test everything to ensure that things work as intended. Eventually, the changes will be published. This process will be repeated for every story.
- Repeat for all accessibility issues that are neglected by developers.
This process is a tremendous waste of time. It’s much more efficient for developers to handle the accessibility work themselves during their day-to-day work. It should only require a few more minutes of work on their part. As a result, it would almost completely eliminate this long process.
If developers know about accessibility, the company saves money:
- Maybe the company won’t have to hire an accessibility consultancy.
- Even if the company hires an accessibility consultancy, they’ll have far less work to do because developers themselves will handle the majority of accessibility requirements. This should (hopefully) mean that they’ll cost the company less.
You should already be 80% of the way there
The biggest win for website accessibility is using semantic HTML. As a developer who works on the front end, this is something that you should already be doing. This accounts for probably 80% of what you need to know and do for accessibility.
All that’s left to learn is the remaining 20%.
Anything you learn will help
Even if you don’t apply all of the required accessibility standards, anything you learn will help. Applying even one additional accessibility technique is better than not applying it.
In other words, you could spend just 1 hour learning accessibility and you would still come out ahead.
In short, if you work on the front end of an application, you should learn accessibility. It’s probably required for jobs, it’s a legal requirement, it makes you a more valuable developer to your company and more.
That’s it for this article.
If you have any feedback, or even counter-arguments, please let me know in the comments.
Next, if you want to know more about accessibility, as well as how to apply it while you work, please see the article Web accessibility – Everything you need to know.