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.

For everything you need to know about accessibility, check out Web accessibility - Everything you need to know, on Programming Duck.

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.

Also, thousands of companies are getting sued every year for accessibility-related matters.

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:

• WebAIM article on world laws
• WCAG page on web accessibility laws and policies

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.

More benefits: 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.

Better accessibility

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:

1. The consultants will spend time testing website accessibility. They'll find multiple issues.
2. They'll take detailed notes of those issues and why it's important to fix them.
3. They'll write detailed instructions for developers, with multiple options and recommendations, on how to fix those issues.
4. They'll create a report out of those notes to provide to the company and the developers.
5. The issues from the report will be converted into stories, then estimated, then pulled into a sprint.
6. 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.
7. 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.

It's cheaper

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.

Conclusion

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.

Final notes

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.