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:
Whether or not the menu is open can be very important for a user orienting themselves on a page so they can find something.
I'm guessing it could be beneficial for some cognitive disabilities, like dyslexia.
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:
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.
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.