re: A JavaScript-Free Frontend VIEW POST


I really like the principles! <details>/<summary> in particular, I'm a big fan of them for collapsible sections.

I want to point out that for some interaction to be fully accessible to users, you might need JS. This is for the modal in particular. Modals have specific prescribed user interactions, outlined in the WAI-ARIA Authoring Practices. You need to enhance the focus management so that you focus the dialog (or the first interactable element, depending on what recommendation you follow). Using a checkbox and label to do that seems like an abuse of semantics.

One implementation of progressively enhanced dialog that I like is Github's details-dialog. It handles a number of interactions better than the plain version. And in case JS fails, the UI is operable by some users still (goals that I believe match yours :) ).

HTML is great at providing accessibility by default, but it does not mean that everything is best served without any JS. I think this is a big reason why the dialog element has not gained much traction outside of Chrome; there is behaviour that still is not clear without JS.

(* Speaking of HTML and labels, your forms are missing them. Many people consider that to be "cleaner", but it is simply inaccessible to many users. Not just Assistive Technlogy (AT) users, but also people who rely on translation services, cognitive disorders, and so on. I find that people will copy the examples that blog posts set out, so I would urge you to consider adding labels.)


On the topic of accessibility and

The ability to do the modal/checkbox trick above without it feeling like a hack and writing weird CSS.

I think that <details>/<summary> is a better element to enhance for these cases. I pointed out Github's implementation above, for its enhanced JS interaction, but I should also mention that its no-JS behaviour is better, because it is more navigable by keyboard. I tried the menu and settings on the site, and I was not able to reach them by keyboard. With details/summary, those would be in the tab order and announced with better roles.


Excellent points! Thank you for this awesome feedback.

Absolutely, the checkbox/label is definitely an abuse of semantics. Totally a hack that should not survive in the long term. However, look at the amount of code in the example from the example you sent. If you need a complex system with absolute control, then there is no problem with that. I do love the elegance and accessibility improvements of the <details> alternative you linked and will probably be migrating to that in the future. However, is it not a failing of the standard to not allow something without JavaScript whatsoever? Why was something like this never added to the standard?

<button for="my-dialog">Click Me</button>
<dialog id="my-dialog">Modal Here</dialog>

The open attribute, requiring JS, is totally missing the mark on behalf of W3C.

Unfortunately, like many other projects, accessibility typically lands at the bottom of the priority list. I am ashamed at how often this is the case and at how weak my accessibility knowledge is. Regarding the forms, I typically prefer using the placeholder as an input label. I realize this is not in the spirit of an accessible form, so how would you suggest improving it while keeping the same visual style? Use a <label> with position: absolute placed over top of the field? Is there a CSS trick for reliably hiding it when the field is filled so that it behaves just like placeholder?

By the way, if I have a <label> in a form but it is display: none, does it lose it's value to someone who needs accessibility features, or does the accessibility tech still benefit from the added semantics?


That code is 300 lines, well commented, straight from the authoring practices. That's not a big number at all, especially when the dilemma is between "inaccessible because we don't want scripts" and "accessible after scripts get here, and still operable without them".

Even with <details>, you still need to make sure that the full "modal" semantics are there, after scripts come in. This is what Github's implementation, in 200 lines :)

I understand that not having a lot of scripts is the point of the post, but I think the metric should not be the target. If the target is to provide a better experience for everyone, and you need the scripts to make it fully accessible, then I don't see a reason to skip them.

Especially when promoting it to people as something that offers a better user experience, something that they might copy verbatim, it is important to stress all use cases.

This has given me a lot of thoughts to write about progressive enhancement. I like the spirit of the post, I really do!

On the dialog spec

A big reason why the dialog element needs JS still, and has not gained much traction outside of Chrome, is that it's missing some important primitives. For example, we need primitives to render content "inert" and an element as "blocking" others. (See, for instance the inert attribute proposal)

I think the Authoring Practices go over the prescribed behaviour much better than I could.

Progress is being made, and in a way that I think will give us better tools to handle these interactions. And in any case, until then, why not enhance the markup with scripts? It is still operable without them, and serves users better with them.

Scott O'Hara has given a good overview of modal dialog accessibility, which might shed more light.

On form labels

By the way, if I have a in a form but it is display: none, does it lose it's value

Correct, it does not expose them. Also correct that placeholder does not get exposed.

This is for a good reason; imagine all the content on the web that is rendered with "adaptive design" practices. Large subtrees of applications get hidden conditionally with media queries, so the Assistive Technology (AT) user should not have to go through them.

There is a way to visually hide content without hiding it from AT. It is often used as a bandaid though, and it can confuse sighted AT users!

Form labels are not just for AT users. There is good research out there that they help fill rates and comprehension.

As you say, a placeholder disappears as soon as you start typing; the user can get lost, have to Ctrl+X Ctrl+V just to remember what they were typing etc. That can range from annoying to stressful.

(I know I said it a couple of times, but when promoting a practice that is better for the users in a post, having inaccessible examples goes counter to the point, and can propagate them. Accessibility is most often not about special skills, but about not removing the default semantics, like the labels).

I outlined my own gripes and suggestions about forms in a talk. Some sites omit labels, which renders forms untranslatable. As an immigrant, that can lock me out of sites, when the original intent was for the form to be clean and welcoming!

Another source I like is Adam Silver's Form Design patterns.

Material Design has a pattern of "floating" the label up when you start typing. At the end, you still need visual space to accommodate the label. That text also tends to be small (and worse sometimes, low-contrast), which ime renders a lot of the benefits of labels moot.

The fact that "no labels is more clean" is an assumption to be challenged, in the same spirit as the post. I want to see more of that :)


"...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: none, it will be hidden from screen readers, same as visual users. Same goes for visibility: hidden.

This is why your label + checkbox hack unfortunately needs to die--it will likely be completely inoperable to a keyboard user, and totally incoherent to a screen reader user.

Don't get me wrong, I love the spirit and goal of this post, 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.

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', () => {

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>
#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