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:
Are you implying someone without a college degree would have a harder time understanding WCAG?
I have a cognitive disability. I'm capable of understanding WCAG and linked resources that helped with that in the blog.
Relatively few people are proficient at using the web, let alone assistive technology, so that's not a good reason not to develop something.
I'm going to link the same blog I linked in the last comment, because it debunks a few of the points you made, especially re: screen readers: ericwbailey.design/writing/truths-...
One example is color contrast.
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.
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?
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.
Why is the onus always on the developer?
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.