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 y...
For further actions, you may consider blocking this person and/or reporting abuse
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.