Accessibility is the core philosophy of the web.
I haven't been in this space long, and I already see many accessibility experts exhausted from yelling, "Accessibility is a right not a privilege!" I don't know how to explain that you should care about people, so let me put it this way:
From the technology to the philosophy, the web is based on the idea that anyone, anywhere should be able to access your content. If you're a web developer, and you're not thinking about who you're excluding with the way you've built your page or app, you're not developing for the web.
- The World Wide Web
- The Tools We Use
- You're Not Developing for the Web If
- Learning Resources and Tools
- Conclusion
The World Wide Web
Recently, Mia's video for Mozilla, Why Is CSS So Weird?, came across my feed. One of the reasons I love this video is that it reminds me of when I was a baby dev in isolation, reading Mozilla Developer Network's "Getting Started with the Web." The more universal reason to love this video is the context it gives to what we're trying to do as web developers:
Give the maximum number of people access to content.
The W3C, or World Wide Web Consortium, is the main international standards organization for the web. They developed WCAG and have several mission statements, and the first one is "Web for All:"
The social value of the Web is that it enables human communication, commerce, and opportunities to share knowledge. One of W3C's primary goals is to make these benefits available to all people, whatever their hardware, software, network infrastructure, native language, culture, geographical location, or physical or mental ability.
To the W3C, this doesn't just mean developing for assistive technology, it also means internationalization, performance, and reducing cognitive load.
When you think about the "good old days" of the internet, the main thing we love to reminisce about was how anyone could host some content and we could all go find it in its hideous glory. The main thing we complain about are the barriers to the content like internet speeds causing pictures to load a couple pixels at a time.
The Tools We Use
I've heard it over and over again from different angles.
- JavaScript is forgiving, so that there's a better chance it'll end up displaying what you need on the page.
- CSS fails silently and in a way that usually keeps content displayed.
- Poorly written HTML will still display, so you should run your code through a validator.
- Semantic HTML has information built in so that more people can access its content.
The freedom to write bad code and many of the inconsistencies we complain about as web developers are features, not bugs. Furthermore, it's our job to build web applications in a way that gives as many people as possible access to our content. In the same way you'd write error handling, responsive design, and progressive enhancement, it's your job as a web developer to make sure the accessibility tree reflects your content accurately. Just like you'd think about whether it's justified from a performance perspective when you add in extra JavaScript, you need to think about what assistive technology you'd be preventing from getting the state it needs when you write an event handler.
You're Not Developing for the Web If
- You've disabled default accessibility features without building a replacement.
- You're not writing semantic HTML.
- Accessibility testing isn't a part of your release process.
It's built in for a reason. The browsers can't agree with the HTML5 spec or on image types, but do you think a focus outline magically made it into all of them unnecessarily?
Just like you use Prettier or ESLint, you can use an accessibility linter. It's your job to add tools to your toolchain that support your ability to write accessible code for the web. You wouldn't ask if you should write error handling, so you don't need to ask if you should make sure all your images have alt text.
Speaking of, a lot of this stuff cuts down on the work you have to do, involves writing cleaner code, and/or provides graceful fallbacks if things go wrong. Alt text isn't just for screen readers, it's also what shows up if your link to your image breaks.
In the U.S., if your employer is really adamantly against development with accessibility in mind, you can always reference the Americans with Disabilities Act. Yes, even if it's just an intranet, your employees can sue you for making it inaccessible.
Documentation and Plain Language
Accessibility doesn't end with the code you push to production. You can't remove the human element from tech. Writing documentation and writing it in the plainest language possible doesn't just help with onboarding, it also makes your development lifecycle more accessible. You have no idea what kind of background an incoming developer will have, which departments in your company may need to reference your process, or what cognitive disabilities your coworker may have. There's a reason writing materials at an 8th-grade reading level is a communications standard.
Don't believe me? Watch Julia Seidman's talk, Docs for Equity. Listen to people who are mad about websites circumventing attempts to archive information. Information should be accessible for those who need it - that's the true power of the web.
Learning Resources and Tools
Ready to learn more? Here are the free resources I've found helpful in the last two years. If I missed a tool or resource you love, leave a comment!
Learn Web Accessibility
- Mozilla Developer Network's Getting Started with the Web Guide
- Inclusive Design Principles
- Web accessibility in mind (WebAIM)
- How to Set Up a Screen Reader
- Hand tremors and the giant-button-problem
- W3C's Accessibility Fundamentals
- W3C's Introduction to Web Accessibility course
- W3C's WCAG Standards Guide
- Testing Accessibility Workshop resources by Marcy Sutton
- Harvard's Digital Accessibility Resources
- Accessibility Maze
- HOCUS :FOCUS
- University of Minnesota Duluth Webdev Newsletter
- a11yproject list of resources
Write with Plain Language
- Make over your internal communication by writing much more simply
- Simply Put - A guide for creating easy-to-understand materials
Tools
- WebAIM contrast checker
- Accessible color generator
- Reasonable Colors
- a11ysupport - caniuse but for accessibility
Testing
- Manual Accessibility Testing: Why & How
- The Importance Of Manual Accessibility Testing
- Chrome and Firefox both have accessibility tools in their DevTools
- web accessibility evaluation tool (WAVE)
- axe DevTools extension
- ARC dev toolkit for chrome dev tools
- IBM Equal Access Accessibility checker
- Microsoft Accessibility Insights
- axe Accessibility Linter
Conclusion
I want to be really clear: you should care about the people your app is excluding. The majority of sites being inaccessible means over a billion people are limited in their independence and options. Still, I see people attending an accessibility conference asking why accessibility experts are even needed...
Web accessibility is a huge topic with many grey areas. Requirements change based on the browser and user. As long as you are striving to learn more about it, listening to those who are being harmed or excluded, and implementing what you know, you are developing for the web.
Top comments (25)
I will bookmark and send link to a bootcamp discord server chat where I literally asked if accessibility and the standards expected by search engine bots would be covered. Only the sound of crickets replied. What is most useful about the article is the many links providing solutions to be designed before any code is written. Thanks so much.
Yeah, we didn't touch on it at all in my bootcamp. I got lucky and got a suggested pre-work document from a different teacher than I had, which made a point to say we should read the guide I linked from MDN.
I wrote the HTTP 101 series for a similar reason. I'm looking forward to writing a Web Security 101 series after I learned a lot from the basic web security training for my current role.
Perhaps you can answer a question: is there a default CSS that IS considered accessible that would be a standard to adhere to which already exists? Is there some website that would be a best case scenario template? Thanks
For CSS in general, the most I can give you is HTML = content, CSS = presentation and guides like MDN's and WebAIM's with best practices. It tends to be more like googling "accessible component" rather than boilerplate CSS for a whole page, if that makes sense.
CSS frameworks usually have plugins and guides in their docs, but I'm big on learning CSS like you would JavaScript when you are starting out. It will help you in the long run.
Great article. Accessibility from web documents can propagate better features for the interface down to the operating system and hardware peripherals in some cases. So it's not just the web but software in general that can and should utilize roles, states, and properties. The process of describing your code for more connections to the interface is a really powerful concept. Reminds me of the electronic curb cut side effect.
Amazing article Abbey 👏
Thanks, Chris!
Been loving your new series, too!
Thanks Abbey, Hope you they keep being good 💖
What an interesting article 👏👏👏
Oh woaw many resources ! 🚀♿
Thank you for sharing, Abbey! 😃
I'm so bookmarking this! ❤
Thanks for reading! 💙
You make a good case, and these are useful links.
We very well written article. Definitely covers a lot of ground, especially the resource section. Some of what i discuss below is not about this article as Abbey was quite thorough, but maybe some of you have dealt with the same and have some input to share with me.
What I keep finding hard is that clients come to me, and they've seen an article or two like this and go "Use WebAIM" and the "WAVE" tool so my site's accessible.
They don't realize those testing tools just tell you a fraction of the accessible problems your site has and that NO ONE can claim a site is accessible or "ADA Compliant" unless they're with some government agency or have some sort of certification AND are able to test it by having someone with actual disabilities testing and verifying it.
Clients all want it cheap, and a lot of Developers claim to write "accessible code" without stating that their code may be fine but that does not make a website accessible or compliant at all, and god forbid you question them about it.
They sell this as a service and screw good people out of their hard earned money.
Your code can be perfect and your site could still be useless to blind people[you have 5000 lines of tracking pixels in your code and their screenreader can't reach anything useful ], or deaf people [if you have audio/video and they can't find the transcripts], or others for whatever reasons.
Clients come to me asking for ADA compliance and then balk at the costs.
Getting compliant is not cheap. I've had clients work with Level Access [levelaccess.com/ they start at like $5k for a small 5-10 page site and expect a recurring service to review it every X months]
And they just tell you what's wrong, clients frown when i tell them i have to bill them for time spent fixing whatever is found that's flawed. I can do my best, but I won't work for free.
So then they go "Can we use these" and they link me to half a dozen Overlay crap sites like Accessibe. Not gonna list all the reasons you don't want to use overlay accessibility tools that claim compliance.
These guys have done it for me, extensively:
siteimprove.com/glossary/accessibi...
overlayfactsheet.com/
In the end, Accessibility and ADA Compliance aren't the same thing, and there are few people qualified to say if your site actually is or not.
On top of that, the law, as defined, is very gray area on what does and does not apply to business sites, so business seek to go with the lowest common denominator which i find is "AA compliance" via the WCAG guideliness.
Any input on a good approach to helping small business solve their compliance needs? Cost-effective, as in, cheap solutions are always preferred, but I'd like to do this thing right.
😂 I appreciate the notice that this wasn't necessarily about the article. You're right - it's time consuming and complicated and expensive and a lot for one person to do. Maybe @colabottles or @inhuofficial will have some advice.
I wrote about it here and along with the advice given here, I have to say that accessibility isn't a checklist or a group of features. I've told that to former clients. It is a process and more so if accessibility wasn't factored in from the very start.
Clients need to be educated in a way so that they can understand this isn't a quick fix that will be done in a day or two. Clients know what they want, but they don't. They don't know what they want because what they want is usually inaccessible.
Another thing I would tell clients is, "There is no such thing as your site being ADA compliant (if it isn't a government entity or fall under Section 508 here in the States), there is no such thing as a quick fix, and if you don't want to get sued, you'll let me handle the accessibility side of things and let this be done so that it protects you and your visitors."
Small businesses can get sued too.
One last thing, if you do have clients you're doing work for and they're paying you, you factor in that time doing accessibility before contracts are signed and you just do it. I did that for the final two years I freelanced. Jobs were completed and accessibility was done from the beginning. It also helped that in my contract, there was a section that spoke to accessibility and how it was going to be WCAG AA compliant or even go for AAA in areas where it was feasible.
You'd be surprised how many business owners, stakeholders, or CEOs don't read a contract.
Thanks for the tag, @abbeyperini This is a great conversation to have. Good stuff also from @inhuofficial
Awesome tips in here and, (not to infringe on a trademark or anything) but when it comes to accessibility Todd made a great point…”Just Do It” 🔥💪
Change their mindset. Small businesses that are “we need compliance” thinking will never be able to afford to be compliant.
Instead what I like to do is to slowly guide them the realisation that a11y is the path to profits (size of the market, spending power etc. Are the tools at your disposal here).
It takes some effort, but once they realise that full buy-in and “a11y first” thinking benefits the business your whole approach can change and it becomes affordable.
They focus on long term improvement plans, rather than a VPAT and minimal fixes. They change their development and procurement processes to build a11y in from day 1 and so it adds very little cost.
These are all achievable for a small business, making sure that everything they do going forward is accessible and that they have a plan to slowly fix old mistakes does not add an undue burden. In fact, if you can help them shout about their improvements (without it being virtue signalling) and their commitment to improvement it will add to their bottom line and be a major differentiator for them.
So to answer the question, sadly there are no cheap fixes in the short term I am afraid. But if you can get long term buy-in then it is no longer a cost, it is a growth strategy and your job becomes 100 times easier (you are advising on a11y before they take action, so you can find accessible libraries, components etc. early and save tech debt (a11y debt) being a barrier.
Hope that helps a little, not sure if it made sense as it is hard to write long comments on my phone! ❤️
P.s. thanks for the shout out / for tagging me in Abbey ❤️
Excellent answer, especially on mobile!
😅 Not gonna lie - I was like "I just develop. My company has whole departments for this. Who do I know who is brave enough to do this on their own?"
Awesome article.
Excellent explanation!
Thanks!
I don't have an argument with anything you say here. But the "grey areas" are a problem and WCAG, even though well-meaning, has not helped the situation. Demanding the same experience for everyone has made development much more difficult than it should be, and turns off the people they should be trying to bring into the fold. The truth is that user experience will never be exactly the same for everyone. Before WCAG2, equivalent access was the goal. That goal is pretty easily obtainable using the steps you describe. But now I find myself having to override HTML semantics with ARIA in order for non-sighted users to know whether a menu is open or closed. Why does that matter? If the navigation is a semantic table of contents, and the user can navigate that with JAWS by skipping whatever sub-trees aren't relevant, a dropdown menu has no meaning and actually gets in the way.
Firstly - yeah, the grey areas and ambiguity are tough. Like, it's not enough that we have to try and consider every browser and screen size!? I do want to stress that no site is 100% accessible, and yet, there are people out there trying to act like that is a possibility. Ultimately, you can't predict every single user scenario. The important thing is to give an easy way to for users to provide feedback and listen to it. This post was merely a pointed appeal to the ego of developers who aren't bothered by excluding people.
Could you expand on what you mean by "WCAG, even though well-meaning, has not helped the situation" or show where WCAG2 is demanding the same experience for everyone? Because I agree, it's about equivalent access. The same experience is impossible. I'm not saying it's perfect, but without the W3C pushing for accessibility with WCAG, I don't think we'd be seeing the amount of interest in digital accessibility that the industry is currently celebrating.
Your example seems very specific and I don't know the full context but I'll try to give some reasons for why it may matter:
I really wish I could send you a recording of a demonstration I watched last week, because it made it seem really important to give anything a user can interact with as much context as possible. For example, if we just thought about non-sighted screen reader users, my dark mode toggle wouldn't need any semantics. Currently, the semantics are good for sighted screen reader users, but I got feedback that I could probably add more labelling for those with cognitive disabilities who may not associate the sun with light mode or use a screen reader.
What I mean is that WCAGs guidelines are too vague and too broad. Define "cognitive disabilities." Yet the WCAG site itself is hard to understand for me - an experienced web developer with a college degree. How on earth is someone with cognitive disability going to make sense of it?
I've been doing my best to build accessible sites for 15 years. I'm speaking as an advocate for accessibility.
In the past few years, sites that are semantic, validate and pass the automated checker and WAVE are being branded "unusable" by the accessibility team because of some quirk in JAWS or some overly stringent interpretation of WCAG. Or things that were accessible 5 years ago, aren't anymore because the scope of WCAG expanded. The "spirit" of the law has been replaced by the "letter" of the law. Except the law is far from precise and changing.
One example is color contrast. The color contrast algorithm is broken when it comes to white text - especially on a background with a saturated color. I can use my discretion to use white and make this readable to the vast majority of people, or I can make it black and hard to see and risk being sued by some ambulance-chasing lawyer. It's crazy.
People who depend on screen readers become power users very quickly. Why should I be expected to code for someone not proficient in the technology they use, especially when - as you say - all screen readers work differently. None of the screen reader manufacturers provide guides for how to code for these screen readers. It's all trial and error. Why is the onus always on the developer? At what point do the screen reader manufacturers need to be responsible for providing a seamless experience? Why can't they - after all these years - interpret content inserted programmatically by CSS?
When adhering to accessibility guidelines becomes too onerous for developers, the community risks alienating the people they need to make it a reality.
Normally when someone is clearly taking their frustration out on me, I would stop responding, but we've looped back to points adjacent to this blog, so I'm going to try to address this as helpfully as I can.
This comment seems to be arguing that developers shouldn't care about accessibility because the standards keep changing and there's ambiguity.
I clocked that you're experienced when you referenced WCAG before 2 - my point was that this article is specifically for those who don't care, and I can tell that you are feeling the pressure from trying for a long time. I would be shocked if things looked the same today as they did 5 years ago in web development. Programming, especially web development, involves lifelong learning. Ambiguity exists in most areas of programming. There are often many ways to do one thing and no clear right answer.
It also sounds like you're butting heads over guidelines with the accessibility team you're working with.
Automated tooling isn't going to catch a lot of things - especially only one tool. Multiple automated tools and in-depth manual testing is required - I linked a couple guides on that in the blog. It is the job of the accessibility team you're working with to help you catch these things and mitigate harm, but it sounds like you're taking that personally or as criticism of you.
What mainly concerns me is you are centering yourself as an accessibility advocate, but some of your arguments are ablest, show a lack of willingness to learn, or are not empathetic to edge case users:
Color contrast math is very hard and something that is being updated in the next version of WCAG. I enjoy coming up with accessible color schemes, have been able to implement white text on color, and don't agree that aesthetics and accessibility are mutually exclusive.
Half the answer is because people don't care and thus time and money haven't been invested. The other half is browsers being unable to agree, which is the bane of the web developer's existence.
The examples of things within the developer's responsibility I listed in the blog are things like alt-text, semantic HTML, and installing a linter - I'm asking no one to become a perfect accessibility expert and a web developer. I am vocal about the fact that I don't expect any developer to anticipate every user scenario. I've even said elsewhere that I've seen a pattern where developers are listening to their ego and believe they should do everything and that is a folly. It takes a team.
If I had an easy solution to accessibility, I would give it to you. What I wrote isn't about how to keep people engaged in the accessibility sphere after they've decided to care, but that's a good idea for a blog. I hope you can find the reason why you want to keep caring about accessibility.