I have been reading through the State of HTML 2023 results site (https://2023.stateofhtml.com/) and I am so disappointed in the overall #accessibility efforts — both in the questions and in the code.
@aardrian having seen what I’ve seen from the survey creator’s other surveys and commitment (or lack thereof) to diversity and inclusion, I’m not even remotely surprised.
@cferdinandi I had been giving the benefit of the doubt, but after a couple years of failure to act and compounding bad patterns with worse patterns and terrible survey assumptions, I am done giving that benefit.
@aardrian My understanding was free advice was given multiple times but not acted upon. They also solicited a "web components expert" for help, but for $0 pay.
Then we get to “Other Accessibility Techniques” and, instead of maybe leaning on the results of the WebAIM million report (https://webaim.org/projects/million/#wcag), overlaps a few of them while adding some questionable ones.
prefers-contrast? I feel like the authors think that has more value (and support) than forced colors mode.
The not relying on pointer only entry is rich given how I opened this thread.
I am underwhelmed at the options and framing for each.
At the screen readers section, things become clearer.
Respondents had a plurality using VoiceOver (though the survey does not distinguish between macOS or iDeviceOS, which have different behaviors). Far different from actual use in the wild.
There is also no discussion of browser pairing, of course, nor any way to filter for browser pairing.
I did not expect Narrator nor Orca, nor do I know if it was asked.
The results for #accessibility testing tools were novel. Lighthouse and Axe are both, well, Axe.
Seeing VoiceOver.js alarms me. Not sure if that was an option or a write-in.
But if you are a practitioner, head to “Accessibility Pain Points,” expand the improperly-coded disclosures, and read the options with the comments (unless you’re a keyboard user because fuck you I guess?).
@Lukew Devs (I work with) are consistently confused how it differs from light/dark and forced colors. There is also no good guidance on what do, given ‘more contrast’ is hand-wavy at best.
But if you like maintaining yet more color schemes, sure?
I was looking for a post I recall that broke down experience in the wild, but ran out of time owing to cafe trying to shoo me out.
@aardrian Windows conflating contrast with forced colour schemes will always annoy me. Makes it much harder for the average Dev to understand the difference.
Windows makes no such conflation. The forced-colors feature query is just a standardized version of -ms-high-contrast, which predates prefers-contrast.
Though prefers-contrast allows system colors, something forced-colors does by default, it is not triggered by it.
@aardrian There's no contrast setting on Windows independent of the forced colour pallete unlike every other platform (Android is slightly more complicated but closer enough). You can't trigger prefers-contrast: more without forced-colors: active on windows. The contrast value is based on the chosen colour pallete too. If it's low contrast then prefers-contrast: less will be triggered.
@Lukew It seems to me that was a failing in the spec, then.
If you build a web platform feature but that feature is not in the host OS, then you cannot expect it to work for those users. And if the spec writers are not campaigning to have it added, then, well, they dropped the ball.
Add comment