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
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
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
Testing
Chrome and Firefox both have accessibility tools in their DevTools
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.