Abbey Perini

Posted on May 19, 2022 • Edited on Jun 21, 2023

Web Development === Accessibility

#webdev #a11y #javascript #html

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

Write with Plain Language

Tools

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)

WhiteOakAmplification • May 24 '22

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.

Abbey Perini • May 24 '22

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.

WhiteOakAmplification • May 24 '22

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

Abbey Perini • May 24 '22 • Edited

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.

Russell • May 25 '22

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.

Chris Bongers • May 20 '22

Amazing article Abbey 👏

Abbey Perini • May 20 '22

Thanks, Chris!

Been loving your new series, too!

Chris Bongers • May 20 '22

Thanks Abbey, Hope you they keep being good 💖

Lebogang Sekaleli • May 24 '22

What an interesting article 👏👏👏

Thomas Bnt • May 19 '22

Oh woaw many resources ! 🚀♿

Ayu Adiati • May 19 '22

Thank you for sharing, Abbey! 😃
I'm so bookmarking this! ❤

Abbey Perini • May 19 '22

Thanks for reading! 💙

Robert Andrews • May 19 '22

You make a good case, and these are useful links.

Ravavyr • May 24 '22

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.

Abbey Perini • May 24 '22

😂 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.

Todd Libby • May 25 '22

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

GrahamTheDev • May 25 '22

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” 🔥💪

GrahamTheDev • May 24 '22

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 ❤️