5 ms·

> I feel completely starved of information here. I care about accessibility. I want to build a web page where clicking on a tab refreshes a subset of that page.

> I feel completely starved of information here. I care about accessibility. I want to build a web page where clicking on a tab refreshes a subset of that page... and I still can't find a really good guide on how to do that in a way that works in screen readers, that's accompanied by a video (ideally multiple videos, one for each common screen reader) showing the experience I can expect my users to have from that pattern. I completely agree that this is a pain point. In general, high quality documentation is lacking. I am not however convinced that this is a problem that can be automated and abstracted away. Neither am I convinced that it's one we should necessarily try to hide. It won't win me any favors but I think the issue here is simply an endemic skill and knowledge gap. Shifts in culture via higher educational curricula and stated quality attribute priorities within companies will do more good here than anything else. Accessibility is a quality that needs to be built in from the start. The good news is that provided your HTML is sane and not a mess of class tagged DIVs, or you're building a pretty straightforward document-like navigation/content/etc site, you really only need to declare attributes to handle the places you do something unusual. The defaults are generally correct. Much of this "unusual" behavior that needs special treatment is within custom components (e.g. a custom date selector widget with plenty of invisible divs used for layout of the calendar days can be inscrutable to a screen reader without hinting) and is the responsibility of component library or framework producers. Some issues here run deeper, like properly correlating ARIA attributes in shadow and light DOM. But that being the case, such component libraries aren't even necessarily suitable for many sites (either too complex, or make too many mismatching assumptions). The bulk of the remaining accessibility attribute slinging that needs to happen has to do with the overall site layout (especially reactive layouts). I don't know of any framework that will handle this for you in a satisfying way for anything sufficiently sui generis. I think the tough but true answer here is "the people building the site should have at least skimmed the WAI-ARIA standard, and be using an auditing tool, and know what to be thinking about as they design the site from the start".

nindalf 2y ago
Everyone needs to read this spec and then live and breathe its tenets … sure. This reminds me of the time when we fixed the footguns with C by making everyone into better developers. That guy is asking you if replacing a part of the html with some other html alerts screen readers to the change. It’s a reasonable question and you could share what you know about how screen readers react when this replacement happens. You could write some documentation on how to alert them, some best practices to follow. Instead you say read the fucking manual, as if that helps. You put on a veneer of caring for accessibility but it seems you care about the “purity” of htmx more.
- throwitaway1123 2y ago
  Agreed. Frontend frameworks often do spend a lot of time thinking about the accessibility concerns associated with client side routing, so it's not absurd to consider this question in scope for a frontend library that handles DOM updates. See for instance this 2019 study by Gatsby: https://www.gatsbyjs.com/blog/2019-07-11-user-testing-accessible-client-routing/ https://www.gatsbyjs.com/blog/2019-07-11-user-testing-access... Or even the modern Next docs on route announcements: https://nextjs.org/docs/architecture/accessibility#route-announcements https://nextjs.org/docs/architecture/accessibility#route-ann... Some of this will have to be bespoke work done on a per-site basis, but I'm not sure I'm comfortable with the idea of completely punting this responsibility to developers using htmx, even if it does make philosophical sense to say "this is scope creep", because ultimately users with disabilities will end up being the ones whose experience on the web is sacrificed on this altar of ideological purity.
- yawaramin 2y ago
  > That guy is asking you if replacing a part of the html with some other html alerts screen readers to the change....It’s a reasonable question Of course it is, but it's like asking if using React.js will prevent SQL injection attacks. They are orthogonal things. Making screen readers announce things is controlled by the HTML you write, not by htmx.
  - nindalf 2y ago
    You're wrong, and in a pretty obvious way. It's actually like asking what a database library will do to prevent SQL injection attacks. And the answer is simple - "don't do string interpolation yourself, instead use the `(?, ?)` syntax". If you use that the SQL escaping will be taken care of automatically by the library. If the database library said something idiotic like "read the spec and implement your own SQL escaping logic" it would be a dereliction of duty. Make no mistake, a frontend library like htmx has a responsibility to not break the front end from an accessibility perspective. If existing screenreaders break when you replace HTML then the htmx approach is broken and htmx needs to address that.
    - 2y ago
simonw 2y ago
"It won't win me any favors but I think the issue here is simply an endemic skill and knowledge gap." My problem with that is that, as you can hopefully see, I am very motivated to learn how to do this... and yet I have not managed to learn it. "Learn how to do it" only works if there are clear and obvious resources we can point people to that will help them learn what the need to learn. The ARIA spec is not that. This also feels like an inherently solvable problem, which is why I always take any opportunity to put it in front of people that might feel incentivized to help solve it.
- 1propionyl 2y ago
  Oh yes, I can see :) And yes, I agree it is not the clear and obvious resource we can point people. We DO need better "guide" format documentation, rather than dry technical reference. Nearly everything I've seen online is in very poor shape or outright wrong. I share your feeling that it is solvable, and I also hope that people will help solve it. But I'm sure of one thing: the people who write that documentation will be familiar with the specifications and refer to them (among other sources) while writing. An "Accessibility Book" (like sections of the Python and Django docs, or the Rustonomicon for unsafe Rust) would be a fantastic resource and I hope someone writes it.
- yawaramin 2y ago
  > "Learn how to do it" only works if there are clear and obvious resources we can point people to that will help them learn what the need to learn. There are. Start with MDN. There is no more clear and obvious resource than this: https://developer.mozilla.org/en-US/docs/Web/Accessibility https://developer.mozilla.org/en-US/docs/Web/Accessibility There was a time when I didn't know anything about web accessibility. But I learned by reading, trying out small experiments, and using a screen reader to check my work. If I can do it, you can certainly do it. After a while you face issues like 'Why isn't the screen reader announcing the dynamic content update', you search for solutions, and you come across incredibly helpful content like this: https://tetralogical.com/blog/2024/05/01/why-are-my-live-regions-not-working/ https://tetralogical.com/blog/2024/05/01/why-are-my-live-reg... > This also feels like an inherently solvable problem It shouldn't, especially if you don't know anything about web accessibility. It's hubris to think that something we know nothing about should already have been solved, why hasn't it? Is everyone else just an idiot? No, of course not. It's a complex and nuanced problem. Not the basics like always put an `alt` attribute in your `img` tag, those things are easy. But when you insert dynamic updates with JavaScript into the mix, it gets more complex.

nindalf 2y ago

Everyone needs to read this spec and then live and breathe its tenets … sure. This reminds me of the time when we fixed the footguns with C by making everyone into better developers. That guy is asking you if replacing a part of the html with some other html alerts screen readers to the change. It’s a reasonable question and you could share what you know about how screen readers react when this replacement happens. You could write some documentation on how to alert them, some best practices to follow. Instead you say read the fucking manual, as if that helps. You put on a veneer of caring for accessibility but it seems you care about the “purity” of htmx more.

throwitaway1123 2y ago
Agreed. Frontend frameworks often do spend a lot of time thinking about the accessibility concerns associated with client side routing, so it's not absurd to consider this question in scope for a frontend library that handles DOM updates. See for instance this 2019 study by Gatsby: https://www.gatsbyjs.com/blog/2019-07-11-user-testing-accessible-client-routing/ https://www.gatsbyjs.com/blog/2019-07-11-user-testing-access... Or even the modern Next docs on route announcements: https://nextjs.org/docs/architecture/accessibility#route-announcements https://nextjs.org/docs/architecture/accessibility#route-ann... Some of this will have to be bespoke work done on a per-site basis, but I'm not sure I'm comfortable with the idea of completely punting this responsibility to developers using htmx, even if it does make philosophical sense to say "this is scope creep", because ultimately users with disabilities will end up being the ones whose experience on the web is sacrificed on this altar of ideological purity.
yawaramin 2y ago
> That guy is asking you if replacing a part of the html with some other html alerts screen readers to the change....It’s a reasonable question Of course it is, but it's like asking if using React.js will prevent SQL injection attacks. They are orthogonal things. Making screen readers announce things is controlled by the HTML you write, not by htmx.
- nindalf 2y ago
  You're wrong, and in a pretty obvious way. It's actually like asking what a database library will do to prevent SQL injection attacks. And the answer is simple - "don't do string interpolation yourself, instead use the `(?, ?)` syntax". If you use that the SQL escaping will be taken care of automatically by the library. If the database library said something idiotic like "read the spec and implement your own SQL escaping logic" it would be a dereliction of duty. Make no mistake, a frontend library like htmx has a responsibility to not break the front end from an accessibility perspective. If existing screenreaders break when you replace HTML then the htmx approach is broken and htmx needs to address that.
  - 2y ago

simonw 2y ago

"It won't win me any favors but I think the issue here is simply an endemic skill and knowledge gap." My problem with that is that, as you can hopefully see, I am very motivated to learn how to do this... and yet I have not managed to learn it. "Learn how to do it" only works if there are clear and obvious resources we can point people to that will help them learn what the need to learn. The ARIA spec is not that. This also feels like an inherently solvable problem, which is why I always take any opportunity to put it in front of people that might feel incentivized to help solve it.

1propionyl 2y ago
Oh yes, I can see :) And yes, I agree it is not the clear and obvious resource we can point people. We DO need better "guide" format documentation, rather than dry technical reference. Nearly everything I've seen online is in very poor shape or outright wrong. I share your feeling that it is solvable, and I also hope that people will help solve it. But I'm sure of one thing: the people who write that documentation will be familiar with the specifications and refer to them (among other sources) while writing. An "Accessibility Book" (like sections of the Python and Django docs, or the Rustonomicon for unsafe Rust) would be a fantastic resource and I hope someone writes it.
yawaramin 2y ago
> "Learn how to do it" only works if there are clear and obvious resources we can point people to that will help them learn what the need to learn. There are. Start with MDN. There is no more clear and obvious resource than this: https://developer.mozilla.org/en-US/docs/Web/Accessibility https://developer.mozilla.org/en-US/docs/Web/Accessibility There was a time when I didn't know anything about web accessibility. But I learned by reading, trying out small experiments, and using a screen reader to check my work. If I can do it, you can certainly do it. After a while you face issues like 'Why isn't the screen reader announcing the dynamic content update', you search for solutions, and you come across incredibly helpful content like this: https://tetralogical.com/blog/2024/05/01/why-are-my-live-regions-not-working/ https://tetralogical.com/blog/2024/05/01/why-are-my-live-reg... > This also feels like an inherently solvable problem It shouldn't, especially if you don't know anything about web accessibility. It's hubris to think that something we know nothing about should already have been solved, why hasn't it? Is everyone else just an idiot? No, of course not. It's a complex and nuanced problem. Not the basics like always put an `alt` attribute in your `img` tag, those things are easy. But when you insert dynamic updates with JavaScript into the mix, it gets more complex.