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:
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:
- 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.
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.
Top comments (12)
A well written article on a subject that is so often overlooked (although it is getting better)!
One big thing you could add to this article (giving away my article content here as I am about to start writing myself :-P) are the benefits to the business itself as a lot of freelancers may not see the benefit in knowing about accessibility and I find it makes it easy for me to convert customers when I talk about it.
1 in 6 people being affected by a disability is a real eye-opener for a lot of business owners as a market they are not servicing. You might also want to add the benefits of accessibility for people who aren't disabled.
Feel free to steal some info for both of those points from this stack overflow answer I gave as I cover both of those points briefly and you could probably turn that into some great content (judging by the rest of this article that should be "definitely turn that into some great content 😊).
If anyone wants some technical guidance
For anyone that wants to learn more about accessibility after reading this article and has technical questions, ask a question on stackoverflow.com with the "accessibility" tag and I will answer it in most cases.
It also helps me out as as I was number one last year for accessibility, but I am trying to get the number 1 spot for all time over the next couple of years due to my personal vanity and ego!
If I want to cover like 95% of the accessibility stuff, what should I look out for first? Colors and alt text are obviously the big ones that come to mind, but there’s probably so much more! Are the Firefox accessibility tools any good? I also have the tota11y bookmarklet, which seems to be pretty good.
Sorry for the slow reply, still getting used to the site and the comments system is a bit clunky when you aren't used to it!
The best way to learn accessibility stuff is to download a screen reader (NVDA is free), read how to use it and then try and use websites.
Then when you come to something that doesn't work such as an accordion Google "how to make an accessible accordion".
That will take you down a massive rabbit hole learning about WAI-ARIA, WCAG etc.
Golden rule when starting out is to always try and use native and semantically correct elements. For example if clicking something causes an action on the same page it should be a
<button>element. If it takes you to another page (or an anchor / id on the same page) it should be an anchor<a>. You often see people using an anchor with an emptyhref(<a href="#") - that is an example of using the wrong element for the job as that should be a<button>!A site I really liked when I was learning about WCAG is called wuhcag.com - they explain the WCAG rules in a simplified way.
Also dboudreau.tumblr.com/archive is nicely presented with a user story to explain why something is important. The blog is a little older so it doesn't contain the latest guidance but 90% of stuff is there.
Finally just do a search on dev.to for accessibility, I am sure there are loads of good articles such as this one you just read by Spyros on the "why" and articles such as this article on accessibility tips from @addyosmani (who is worth following).
Finally a really quick way to get you in the mindset of accessibility is to hide your mouse! Try using anything you build with just the keyboard and see if you lose where the focus is, can't interact with important elements etc. and you will be an accessibility wizard in no time!
Thanks a lot for the guidance! I try using as much as possible the semantic tags as I find they are useful for reading the code anyways! I’ll have to try using a screen reader for sure though!
I'm looking forward to an answer from InHuOfficial, but I'll chip in too.
In short, using tools like tot11y and Google Lighthouse (or a firefox alternative) is very good. They audit your web pages and tell you how to fix accessibility violations. They cover a lot.
Another necessity is to use semantic HTML, but I'll assume you're already doing that.
My next recommendations would be to:
WebAIM's WCAG checklist
WebAIM's WCAG 2 checklist is a checklist that covers the vast majority of what you need to do for accessibility. It only takes about 10 minutes to check against (after you've familiarised yourself with it). If you're not sure on how to do something, it has links with a lot of information to help you.
For example, it mentions things like your page must work at 200% zoom, what color contrasts you must have and that the user should always know what has focus when they're using the keyboard for navigation (e.g. by using focus outlines).
Manual testing
You need to manually test some things. That includes whether your website can be navigated purely with the keyboard. It also includes using your website with only a screen reader.
Without manual testing, you can't know for sure whether those experiences work.
Those things are relatively fast to test (after you've become familiar with them). It's like looking at your website (visually) and making sure it looks correct and has the correct content.
More information
There are many more things that you can do, such as manually testing more things, using more automated tools and writing end to end tests for accessibility.
For a lot more information on this, I recommend looking at the next posts I'm planning to upload. They can be found early at How to learn web accessibility and How to make accessible websites - The ultimate guide.
Wow! Thanks for the detailed answer! I’ll definitely check the WCAG 2 checklist! I’m having a hard time with colours sometimes though since I don’t always want a darker colour for e.g. a button. But hey, if the design still looks fine with the darker colour, I don’t mind much!
Hey InHuOfficial,
Thanks very much for the kind words and the info, I appreciate it. I agree that it's a topic more people need to take seriously.
The only thing is, some of the comment feels like self-promotion. For example, the last part from "if anyone wants some technical guidance" onwards could be considered to read a bit like "if anyone has any questions, leave this page and come ask me on my other platform". I believe that on this platform this is generally frowned upon.
Of course, you're always free to write that in the articles you're planning to create and in the comments for those articles.
In the meantime I've hidden the comment, but I'll be glad to unhide if you could remove the self-promotion. You made some really great points in the comment that would be valuable for other people to see.
All the best.
If you believe that was self promotion then that is fine, but stackoverflow.com is where people go for technical answers and isn't exactly "my platform" considering the size of it.
The irony of people always telling me that stack overflow is hard to understand the rules about how to ask a good question and not have it closed and then me having my second comment removed on this platform is not lost on me.
I will have a read of the posting guidelines so I don't have this issue again.
Good luck with the articles, you can leave the comment hidden as like you said I can write my own articles, just trying to reach out a bit and get a feel for the community at this stage.
Cant find anything on the rules for the site, do you know where they are. They just talk about being courteous, avoiding profanity (but they want ban it) etc.
Could you point me to the rules please so I know what I can and can't do here.
Cheers
Hi InHuOfficial,
There may not be technical guidelines about it on this website, but I believe it would widely be considered self-promotion and possibly spam.
Instead, here is stackoverflow's help page titled How to not be a spammer. It mentions "don't talk about your product / website too much" and "don't include links except to support what you've written". The final part of your answer isn't there just to support your answer. It's there to actively get people out of the page to somewhere else you've linked to in a way that also actively helps you. That's considered spam, even if you're trying to help.
This is worse in a place where people own their content and can moderate their comments. (I'm not familiar with stackoverflow, but I don't believe someone who asked a question can moderate the comments. In other words, they don't "own" the content and are not themselves worried about any self-promotion that happens in the comments.)
But in platforms like dev.to, YouTube and many more, it's generally common knowledge that self-promotion is not allowed and it's quite strict. For example, going on YouTube or dev.to and posting a comment on someone's content saying "now come see my own video" or "now come over to this other webpage" is immediately regarded as spam. Even the stackoverflow guidelines mention that you should avoid doing it. It would be fine to answer the question and say "for more information see X", but not to actively direct them away. There don't need to be technical guidelines on it because authors own their content, and they can moderate the comments themselves.
If you need additional convincing on this, just do a search on google for something like "youtube self promotion comments" (or any equivalent big platform). The majority of the answers you'll find are that it's widely regarded as spam. Just in case, here are some of the first community results I found: reddit.com/r/youtube/comments/81ex..., reddit.com/r/youtube/comments/6roq..., reddit.com/r/youtube/comments/3htv...
As a final word, some people may not care about self-promotion but some definitely will.
All the best.
Hey Spyros
No community guidelines broken and I didn't point to any content I own so that was what I was bothered about, I will take on board what you said about self promotion.
I thought the offer of information to improve the article and help for others was very balanced and as I don't own StackOverflow I still do not really see the harm.
Anyway, it was just not the "welcome" to a community I was expecting that's all.
Feel free to use the information I linked to to improve / add to your article as I said.
Cheers
Graham
Hi Graham,
Thank you. I'm sorry for the unfortunate welcome. Judging by the information in your comments, your stackoverflow answers and your polite way of replying even when disagreeing, I can see that you'll provide a lot of value to this community. I'm looking forward to more of your content.
Hope everything is more welcoming than what you've experienced so far.
All the best.
Some comments have been hidden by the post's author - find out more