re: A JavaScript-Free Frontend VIEW POST

TOP OF THREAD FULL DISCUSSION
re: "...if I have a in a form but it is display: none, does it lose it's value to someone who needs accessibility features..." If you set display: no...

but you REALLY should just be biting the bullet and using a <button> + javascript for toggling. Honestly, the amount of extra JS you need to do it is so tiny that there's really no excuse for it.

Agreed. I really appreciate the intent of this post, and that modal hack is clever, but for the reasons already pointed out, I don't think it's worth it. And the JS is extremely simple, e.g.:

elButton.addEventListener('click', () => {
    elModal.classList.toggle('show');
});

That said, I'm totally behind the spirit of his post -- just don't think extremes are necessary.

Still trying to figure out where to draw the line with my specific approaches (I strongly support accessibility). If we were all building native apps we wouldn't even have to suffer through this miserable dilemma. What needs to be asked is:

  1. Why are we trying to build apps on HTML, a medium that was originally designed for hyper*text*? Would a completely new medium be better suited for the task? (Hint: yes)
  2. If we're collectively agreeing that the language of the web is now to be used for executable programs and interfaces, then why is the HTML spec so far behind in supporting common UI tasks like this?

I made your label+checkbox hack more accessible. Works fine with a screen reader / keyboard (tried on MacOS Safari with Voiceover).

<label for="toggleControl" style="cursor: pointer;">
  <button id="toggleButton">Click Me</button>
</label>
#toggleButton { pointer-events: none; }

But still it seems a bit of overkill as already pointed out when you can do it in a few lines of js.

As for hidden text for screen readers you can use a sr-only class.

code of conduct - report abuse