re: A JavaScript-Free Frontend VIEW POST

VIEW PARENT COMMENT VIEW FULL DISCUSSION
 

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 :)

code of conduct - report abuse