jgarber,
@jgarber@mastodon.cc avatar

New to add to your collection: <aria-collapsible>

Generate progressively-enhanced collapsible regions using States and Properties.

💻 Code: https://github.com/jgarber623/aria-collapsible

🧩 Demo: https://jgarber623.github.io/aria-collapsible/example/

📦 Package: https://www.npmjs.com/package/@jgarber/aria-collapsible

aardrian,
@aardrian@toot.cafe avatar

@jgarber Two questions:

  1. This does not do any focus management, right?

  2. The item (or items, since you are feeding it two IDs) the disclosure trigger toggles are not enforced as immediate adjacent following siblings in the DOM, right?

jgarber,
@jgarber@mastodon.cc avatar

@aardrian Thanks for the questions!

  1. No, no focus management. Though, any focusable elements within the controlled region become focusable once the region is expanded.

  2. No, there’s no enforcement that controlled regions must be adjacent following siblings.

Are either or both of those a concern? Should the component behave differently?

jgarber,
@jgarber@mastodon.cc avatar

@aardrian Regarding source order, your excellent disclosure widgets post¹ recommends that disclosed regions immediately follow the associated control.

The <aria-collapsible> demo page runs afoul of that with the “Toggle Notes” control and region. Maybe the “Toggle Notes” example should be changed?

¹ https://adrianroselli.com/2020/05/disclosure-widgets.html

aardrian,
@aardrian@toot.cafe avatar

@jgarber Maybe which example should be changed?

jgarber,
@jgarber@mastodon.cc avatar

@aardrian Sorry, updated for clarity:

> Maybe the “Toggle Notes” example should be changed?

Changed such that the control is followed in source order by the disclosed regions.

aardrian,
@aardrian@toot.cafe avatar

@jgarber Ah, your example. Gotcha.

Without focus management, then yeah. Which does not mean I am right. But from testing, that is safest. And focus management is risky.

Coach authors to do the same. You can direct them to my post if they balk.

If they choose to extend it, then they should be told the risks.

jgarber,
@jgarber@mastodon.cc avatar

@aardrian Thanks! I appreciate your feedback and expertise. Adjusting my example and updating the docs with guidance is now on my to-do list.

I’m also thinking about dispatching an event when the component’s state changes. Authors using the component could listen for the event and do focus management, etc. based on circumstance and best practices.

That might allow for accessible use with multiple regions in non-consecutive source order? Maybe as an announcement using live regions?

aardrian,
@aardrian@toot.cafe avatar

@jgarber At the risk of you taking this the wrong way, sure, dispatch an event, but do not suggest either the navigation (multiple regions or not) nor live regions.

You need to understand how those are exposed to users and how they can mess with users.

So unless you are running tests with daily SR users across a few SR/browser combos, maybe no.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • accessibility
  • DreamBathrooms
  • everett
  • InstantRegret
  • magazineikmin
  • thenastyranch
  • rosin
  • GTA5RPClips
  • Durango
  • Youngstown
  • slotface
  • khanakhh
  • kavyap
  • ngwrru68w68
  • tacticalgear
  • JUstTest
  • osvaldo12
  • tester
  • cubers
  • cisconetworking
  • mdbf
  • ethstaker
  • modclub
  • Leos
  • anitta
  • normalnudes
  • megavids
  • provamag3
  • lostlight
  • All magazines