fix #20: radio role to hint at arrow keys for screen reader users

[hchiam]

fix #20: radio role to hint at arrow keys for screen reader users

also added demo (see video at the end of this PR description)

current game-menu demo on web.dev:

says "New Game, button 1 of 5" because the buttons are wrapped in a <ul> list:

edited version of that game-menu demo to show the bug:

says "New Game, button" (if the ul instead had to be a <div>), not indicating to screen reader users that the buttons are "semantically linked" to each other:

/demo in this proposed PR:

says "New Game, radio button" at 0:05: (https://github.com/argyleink/roving-ux/issues/20#issuecomment-2185307640)

https://github.com/argyleink/roving-ux/assets/18131787/c6228cf7-769d-404b-bad0-258343f5ee2a

[argyleink]

dang, i'm not sure radio hints is correct here. while it maps well to the keyboard arrow experience it's ultimately not a selection mechanism being implemented, it's focusgroup roving behavior. i think what's needed here is UI feedback and not necessarily a semantic hint/change.

the goal: users should be notified they they're entering a focusgroup somehow, that way they dont have to explore to find that the keyboard arrows move you around and we could also share that hitting tab again will pop you out. this might be easyish for screen readers since we could add a label or hint somewhere for the screen reader to surface, but it's harder for sighted users and we need a hint or prompt somewhere that shows like one time, when they first enter the focusgroup? maybe it's like a one time toast? the toast could also be an output element which will get read to screen readers. thoughts?

thanks for lookin into improving this!

[hchiam]

yeah, i'm guessing you're thinking of a toast with aria-live, which makes sense towards helping everyone. hmw notify all users that they're entering a focusgroup, and also notify about tab vs arrows? i did some brainstorming:

i have concerns with handling translations, and bloat/forcing a choice of toast library on devs, and whether it'll play well inside projects that already have their own toast/aria-live/translation managers.

1) a possible option to explore might be to add a custom toast (don't import a library), and let css/js visually hide the toast from mobile users, and expose the toast text to devs for translation/styling. we can't really use an icon to avoid translations because screen readers will need text to announce anyways

2) another option could be to add the focusgroup attribute? my understanding is focusgroup isn't natively supported right now. i remember googling and seeing a polyfill for focusgroup but i haven't tried it and wouldn't know which to recommend. we'd still need a toast, but if focusgroup makes screen readers automatically communicate to users in their own language, then the toast could be simplified to an icon.

[argyleink]

i have concerns with handling translations, and bloat/forcing a choice of toast library on devs, and whether it'll play well inside projects that already have their own toast/aria-live/translation managers.

definitely scope creep and UX disconcerting, i agree, thanks for articulating that here

focusgroup

i've been following this in OpenUI because of the overlap with this library as well as the hope that it'll do everything this lib does and more. turns out the latter is true, it will do everything this lib does and more, much much more. this problem space is very difficult and heavily exposed how naive this library is. BUT, that being said, it also currently hasnt articulated any of this UX like we're talking about now: this idea on training or aiding users in how to navigate focus group like spaces. there's definitely an education gap that users will need in order to effectively use roving ux patterns.

This could just be out of scope for this library to solve. It could just leave it to authors using this library to articulate to their users?

this library will eventually deprecate itself in favor of focusgroup

[hchiam]

sounds good! either way, closing this pr