5 ms·

> In that case it would be great if the HTMX documentation included worked examples and guidance for how to do this. You can refer to the WAI-ARIA standards.

> In that case it would be great if the HTMX documentation included worked examples and guidance for how to do this. You can refer to the WAI-ARIA standards. > Leaving accessibility up the end developer feels like a genuine missed opportunity. This doesn't compute for me. What would HTMX even provide? It's a set of attributes that extend the behavior of form submission to other elements and all request methods. > HTMX or jQuery or React/Vue These aren't the same kinds of tools. They address fundamentally different things. Handling ARIA automatically for you isn't in scope for any of them.

simonw 2y ago
Referring to the ARIA standards doesn't help me answer the more important question: will what I'm doing work in screen readers or not? 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. HTMX actively encourages that pattern, so I'd love to see the project also embrace helping developers do The Right Thing with regards to the accessibility of that pattern.
- ossobuco 2y ago
  > will what I'm doing work in screen readers or not? Why not try it? But also, why wouldn't it?
  - robin_reala 2y ago
    Pointing at the ARIA spec as a way of writing code that’ll work with all assistive tech is like pointing at the HTML and CSS specs circa 2005 and saying that following them will make your site work in all browsers.
  - xg15 2y ago
    Try in which screen reader?
    - flomo 2y ago
      iOS has a good one.
    - yawaramin 2y ago
      The ones you want to support. htmx unfortunately can't tell you what that is.
- 1propionyl 2y ago
  > 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.
- omnimus 2y ago
  I think what they are trying to say is that it has very little to do with htmx or react of whatever framework. None of it can handle accessibility automagically. Its like asking if it can write html for you - its different problem and a skill. But skills in accessibility apply to all frameworks.
- deleted 2y ago
  [deleted]
- seanwilson 2y ago
  > 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 More generally, I often see people calling others "lazy" for not making websites accessible, but I personally found it hard to get my head around the WCAG recommendations, and I work with designers/developers all the time that don't know how to follow the WCAG recommendations even when you point them to documents and tutorials. It's like nobody wants to admit it's difficult, and that's not even getting into screen readers still having many inconsistencies for basic UI patterns. There are some sites that try to document what works and doesn't in different screen readers (e.g. https://a11ysupport.io/tests/ https://a11ysupport.io/tests/), but even then it's still not easy knowing what to do and I don't know of an authoritative up-to-date site.
  - 1propionyl 2y ago
    > I work with designers/developers all the time that don't know how to follow the WCAG recommendations even when you point them to documents and tutorials. > It's like nobody wants to admit it's difficult, and that's not even getting into screen readers still having many inconsistencies for basic UI patterns. Accessibility IS hard. It feels sometimes like nearly everyone involved thinks they'll just read a few good blog posts and know how to make sites accessible. Then the struggle is due to not having read good enough blog posts. Everyone wants a quick "fix" to a lack of education. Nothing replaces familiarizing one's self with primary source specifications, and most crucially, spending significant time trying out real screen readers.
deleted 2y ago
[deleted]
skrebbel 2y ago
> > In that case it would be great if the HTMX documentation included worked examples and guidance for how to do this. > You can refer to the WAI-ARIA standards. Every time someone asks for concrete a11y advice for concrete situations, some joker refers them to WAI-ARIA. This is ridiculous! That document is extremely hard to parse, and it offers absolutely no guidance wrt which parts matter the most, or, say, how the various real screen readers used in the wild behave. Please stop doing this. Accessibility is hard to get right! Making people feel like they're idiots for trying is very unhelpful.
- agumonkey 2y ago
  This makes me think that we all need this tutorial to get rapidly on par and ready to read the whole spec
- gadflyinyoureye 2y ago
  I’m not in a good place to check but what the various AI tools recommend?
- lelandfe 2y ago
  And then you get to WAI-ARIA's practical examples and they have a yellow warning intoning "not intended for production environments" and there "may be support gaps" in assistive technology: https://www.w3.org/WAI/ARIA/apg/patterns/combobox/examples/combobox-select-only/ https://www.w3.org/WAI/ARIA/apg/patterns/combobox/examples/c... I think everyone's afraid of getting sued.
- 1propionyl 2y ago
  > That document is extremely hard to parse, and it offers absolutely no guidance wrt which parts matter the most, or, say, how the various real screen readers used in the wild behave. No, but it does enumerate what is available which is the starting point for figuring out what is relevant to your use case. If you want tutorials or guides relevant to your particular use case you can seek those out, but to understand them you will need familiarity with the set of available attributes and where they are or are not permitted. Many (most?) tutorials online have flagrant violations of the specification. We need better ones that actually emphasize understanding WAI-ARIA and not cowboy markup recipe books. > Please, stop doing this. No, I will not stop telling people to familiarize themselves with the primary reference material. Reading technical documentation and specifications relevant to a project is not an optional step. It is not complete in the ways you describe (actually testing real screen readers is crucial), but it is absolutely essential reading to begin with.

simonw 2y ago

Referring to the ARIA standards doesn't help me answer the more important question: will what I'm doing work in screen readers or not? 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. HTMX actively encourages that pattern, so I'd love to see the project also embrace helping developers do The Right Thing with regards to the accessibility of that pattern.

ossobuco 2y ago
> will what I'm doing work in screen readers or not? Why not try it? But also, why wouldn't it?
- robin_reala 2y ago
  Pointing at the ARIA spec as a way of writing code that’ll work with all assistive tech is like pointing at the HTML and CSS specs circa 2005 and saying that following them will make your site work in all browsers.
- xg15 2y ago
  Try in which screen reader?
  - flomo 2y ago
    iOS has a good one.
  - yawaramin 2y ago
    The ones you want to support. htmx unfortunately can't tell you what that is.
1propionyl 2y ago
> 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.
omnimus 2y ago
I think what they are trying to say is that it has very little to do with htmx or react of whatever framework. None of it can handle accessibility automagically. Its like asking if it can write html for you - its different problem and a skill. But skills in accessibility apply to all frameworks.
deleted 2y ago
[deleted]
seanwilson 2y ago
> 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 More generally, I often see people calling others "lazy" for not making websites accessible, but I personally found it hard to get my head around the WCAG recommendations, and I work with designers/developers all the time that don't know how to follow the WCAG recommendations even when you point them to documents and tutorials. It's like nobody wants to admit it's difficult, and that's not even getting into screen readers still having many inconsistencies for basic UI patterns. There are some sites that try to document what works and doesn't in different screen readers (e.g. https://a11ysupport.io/tests/ https://a11ysupport.io/tests/), but even then it's still not easy knowing what to do and I don't know of an authoritative up-to-date site.
- 1propionyl 2y ago
  > I work with designers/developers all the time that don't know how to follow the WCAG recommendations even when you point them to documents and tutorials. > It's like nobody wants to admit it's difficult, and that's not even getting into screen readers still having many inconsistencies for basic UI patterns. Accessibility IS hard. It feels sometimes like nearly everyone involved thinks they'll just read a few good blog posts and know how to make sites accessible. Then the struggle is due to not having read good enough blog posts. Everyone wants a quick "fix" to a lack of education. Nothing replaces familiarizing one's self with primary source specifications, and most crucially, spending significant time trying out real screen readers.

deleted 2y ago

[deleted]

skrebbel 2y ago

> > In that case it would be great if the HTMX documentation included worked examples and guidance for how to do this. > You can refer to the WAI-ARIA standards. Every time someone asks for concrete a11y advice for concrete situations, some joker refers them to WAI-ARIA. This is ridiculous! That document is extremely hard to parse, and it offers absolutely no guidance wrt which parts matter the most, or, say, how the various real screen readers used in the wild behave. Please stop doing this. Accessibility is hard to get right! Making people feel like they're idiots for trying is very unhelpful.

agumonkey 2y ago
This makes me think that we all need this tutorial to get rapidly on par and ready to read the whole spec
gadflyinyoureye 2y ago
I’m not in a good place to check but what the various AI tools recommend?
lelandfe 2y ago
And then you get to WAI-ARIA's practical examples and they have a yellow warning intoning "not intended for production environments" and there "may be support gaps" in assistive technology: https://www.w3.org/WAI/ARIA/apg/patterns/combobox/examples/combobox-select-only/ https://www.w3.org/WAI/ARIA/apg/patterns/combobox/examples/c... I think everyone's afraid of getting sued.
1propionyl 2y ago
> That document is extremely hard to parse, and it offers absolutely no guidance wrt which parts matter the most, or, say, how the various real screen readers used in the wild behave. No, but it does enumerate what is available which is the starting point for figuring out what is relevant to your use case. If you want tutorials or guides relevant to your particular use case you can seek those out, but to understand them you will need familiarity with the set of available attributes and where they are or are not permitted. Many (most?) tutorials online have flagrant violations of the specification. We need better ones that actually emphasize understanding WAI-ARIA and not cowboy markup recipe books. > Please, stop doing this. No, I will not stop telling people to familiarize themselves with the primary reference material. Reading technical documentation and specifications relevant to a project is not an optional step. It is not complete in the ways you describe (actually testing real screen readers is crucial), but it is absolutely essential reading to begin with.