AkashRajpurohit / howtoprofessionallysay

📖 A guide for your daily "professional" interactions

Home Page:https://howtoprofessionallysay.akashrajpurohit.com/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Introduce progressive enhancement on top of static semantic HTML document structure

myfonj opened this issue · comments

Is your feature request related to a problem? Please describe.
Expanding question is currently reliant on JavaScript. With JavaScript disabled, there is no way to read the answers. (Besides sifting through source code.)

Describe the solution you'd like
Page should be served as accessible static HTML document with both question and answers accessible straight away. Only the "filter" feature should be client-side progressive enhancement not present in the static payload. The "reveal" feature could be done either using native <details><summary>Question</summary>Answer</details>[...] HTML structure with no need of client-side scripting, or with static description list (<dl><div><dt>Question</dt><dd>Answer</dd></div>[...]</dl>) progressively enhanced to interactive button toggle ("accordion") structures similar to current one.

Describe alternatives you've considered
"Robust" alternative with true answer reveal without client-side JavaScript would require either server-side scripting, presumably stateful (what seems a bit over-engineered, but perhaps Vercel could do that in meaningful manner?), or CSS label&checkbox hack (what is not optimal from accessibility perspective and has similar issues to JavaScript-only approach).

Additional context
Must praise otherwise quite accessible approach; current version works well with keyboard. Haven't tested screen readers but seeing reasonable aria attributes gives hope it was thought-out. Inline SVGs should be hidden from the tree, though.

The site is pretty much a static export of the nextjs app, but as you correctly mentioned, currently with JavaScript disabled, I think you solution you have suggested makes sense, currently I am using the Disclosure component from headlessui and we can use the as prop to update which HTML DOM element the button should render as.

It might require some styling changes as well but it should do the work. What are your thoughts?

Also happy to help you if you want to work on this and open an PR for it 😄

PS: thanks for the suggestion about removing inline svgs for screen readers, will fix that soon.

@AkashRajpurohit why do you need expanding at all? Why not display everything on the load?
I (personally) don't like the idea about clicking, instead of just reading

I agree with the point of clicking each item to read about it, the user journey is definitely not very smooth. Not really sure why I opt-ed for this method initially, but I would be happy to rework the UX to make it better.
Please share your thoughts /designs if you come across any which can be better suited here. @syabro

The default behavior is now open so all the cards would be open by default and user doesn't have to click to expand each, however the user may still close a card by clicking on it.