3 ms·

WAI's APG patterns exist to document how ARIA attributes should work, they don't advocate for them to be used in place HTML elements. They also don't test to co

by extra88 5mo ago

WAI's APG patterns exist to document how ARIA attributes should work, they don't advocate for them to be used in place HTML elements. They also don't test to confirm that they actually work in browsers or with assistive technologies (some specific patterns are fine). For web developers, they're helpful for documenting expected keyboard interaction support and other norms. Are you still coding to support Internet Explorer? All browsers have supported details/summary since an Edge switched to Chromium in 2020. https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/details https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

stefan_lec 5mo ago
Details/summary had quirky/inconsistent handling by screen readers for quite a while after it reached full browser adoption, unfortunately. Not even sure if they’ve fixed it here in 2026, honestly. https://www.scottohara.me/blog/2022/09/12/details-summary.html https://www.scottohara.me/blog/2022/09/12/details-summary.ht... While it’s good to use well-implemented semantic elements when possible, there are still plenty of places where either the built-in browser behavior isn’t actually very accessible (like native form validation), or where you just can’t avoid it (using aria-disabled instead of disabled for submit buttons, setting aria-pressed for toggle switches, setting aria-expanded for buttons that trigger modals, situations where you need aria-hidden/sr-only, etc). Though once popovers and the invoker command api hit baseline widely available, we’ll be able to drop some of that.
- extra88 5mo ago
  I think popover and invoker commands with polyfills are already the way to go. The polyfills are small (and if you only want to use the "show-modal" invoker, it's like 10 lines to feature detect and polyfills just that). Many good uses of popover really needs anchor positioning. There's a polyfill for that as well but it's not small.
  - fluffybucktsnek 5mo ago
    It should polyfills are basically a no-go for no-JS sites.

by extra88 5mo ago

stefan_lec 5mo ago

Details/summary had quirky/inconsistent handling by screen readers for quite a while after it reached full browser adoption, unfortunately. Not even sure if they’ve fixed it here in 2026, honestly. https://www.scottohara.me/blog/2022/09/12/details-summary.html https://www.scottohara.me/blog/2022/09/12/details-summary.ht... While it’s good to use well-implemented semantic elements when possible, there are still plenty of places where either the built-in browser behavior isn’t actually very accessible (like native form validation), or where you just can’t avoid it (using aria-disabled instead of disabled for submit buttons, setting aria-pressed for toggle switches, setting aria-expanded for buttons that trigger modals, situations where you need aria-hidden/sr-only, etc). Though once popovers and the invoker command api hit baseline widely available, we’ll be able to drop some of that.

extra88 5mo ago
I think popover and invoker commands with polyfills are already the way to go. The polyfills are small (and if you only want to use the "show-modal" invoker, it's like 10 lines to feature detect and polyfills just that). Many good uses of popover really needs anchor positioning. There's a polyfill for that as well but it's not small.
- fluffybucktsnek 5mo ago
  It should polyfills are basically a no-go for no-JS sites.