5 ms·

Handling ARIA attributes is out of scope for HTMX. It is your responsibility to include ARIA attributes on the HTML you return and swap/transclude. As for hand

Handling ARIA attributes is out of scope for HTMX. It is your responsibility to include ARIA attributes on the HTML you return and swap/transclude. As for handling dynamic content for screen readers, focus management is already a thing, and is in the scope of browser standards and the HTML your backend returns. As before, it's your responsibility to manage this. HTMX will neither help you nor get in your way. HTMX merely extends hypertext functionality to its (mostly) natural conclusion. It is not a component library, or a framework for building components, or a site building framework, or... You can use other tools to enhance and audit accessibility, but their use is orthogonal to HTMX. I think web developers in general are very used to frameworks abstracting a ton of complexity, but HTMX is not a framework so much as a standardized set of tools for specific low level problems, it is not a one stop shop.

simonw 2y ago
In that case it would be great if the HTMX documentation included worked examples and guidance for how to do this. Leaving accessibility up to the end developer feels like a genuine missed opportunity for me here. One of the great things about NOT using a JavaScript library is that you can rely on the browser's default accessibility features for forms and links. Those benefits are the thing I care most about when considering HTMX or jQuery or React or Vue or similar.
- 1propionyl 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. > 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
- yawaramin 2y ago
  > it would be great if the HTMX documentation included worked examples and guidance for how to do this. The htmx documentation does include examples with accessibility guidance. Eg https://htmx.org/examples/bulk-update/ https://htmx.org/examples/bulk-update/ > The server will bulk-update the statuses based on the values of the checkboxes. We respond with a small toast message about the update to inform the user, and use ARIA to politely announce the update for accessibility. If you check the Server Requests panel it also shows the responses and the ARIA attribute they include. EDIT: I've submitted a PR to fix the notification toast announcement, with this the screen reader announces the notification correctly: https://github.com/bigskysoftware/htmx/pull/3112 https://github.com/bigskysoftware/htmx/pull/3112 The key is to mark all live regions statically before doing any htmx requests, then injecting the response HTML inside those regions. Then they are announced by the screen reader. This is nothing special to htmx of course; every app needs to work the same way.

simonw 2y ago

In that case it would be great if the HTMX documentation included worked examples and guidance for how to do this. Leaving accessibility up to the end developer feels like a genuine missed opportunity for me here. One of the great things about NOT using a JavaScript library is that you can rely on the browser's default accessibility features for forms and links. Those benefits are the thing I care most about when considering HTMX or jQuery or React or Vue or similar.

1propionyl 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. > 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
yawaramin 2y ago
> it would be great if the HTMX documentation included worked examples and guidance for how to do this. The htmx documentation does include examples with accessibility guidance. Eg https://htmx.org/examples/bulk-update/ https://htmx.org/examples/bulk-update/ > The server will bulk-update the statuses based on the values of the checkboxes. We respond with a small toast message about the update to inform the user, and use ARIA to politely announce the update for accessibility. If you check the Server Requests panel it also shows the responses and the ARIA attribute they include. EDIT: I've submitted a PR to fix the notification toast announcement, with this the screen reader announces the notification correctly: https://github.com/bigskysoftware/htmx/pull/3112 https://github.com/bigskysoftware/htmx/pull/3112 The key is to mark all live regions statically before doing any htmx requests, then injecting the response HTML inside those regions. Then they are announced by the screen reader. This is nothing special to htmx of course; every app needs to work the same way.