Tagged “form”

When asking users for numbers and dates, which HTML form elements should we use?

When asking the user for numeric information it might feel obvious to use the HTML input type meant for that purpose, namely number.

However the UK GDS wrote in 2020 that they had switched to using inputs of type text, with inputmode set to numeric. This was after conducting tests which had revealed a variety of usability and accessibility issues.

In the same article a reader questioned why GDS’s use of text inputs also extended to gathering dates (a subset of numbers) when there is a dedicated input type date for that purpose. GDS answered that there are accessibility and usability problems with browser implementations of <input type"date"> and linked to Hassell Inclusion’s 2019 article on date inputs as evidence.

I love the level of research and detail that the GDS and Hassell articles provide. But the notion of not using the HTML elements meant for the job annoys me. I’m also aware that smart developers like Jeremy Keith note that input type date now has wide browser support and are using it. (Update: it seems Jeremy has found some browser support issues too.)

It’s also worth reiterating that the Hassell article is from 2019 and the GDS one from 2020, and four or five years is a long time in browser support.

So what should we do, and how should we make the decision? I’m gonna circle back to this and update it with some answers soon, once I’ve worked them out.

Whitney Lewis covers four accessibility considerations for implementing forms: autofill, error messaging, date fields and auto-formatting fields.

I found the explanatations of the autocomplete attribute and the section on an accessible error message pattern particularly useful. The latter part felt similar to the good advice Adam Silver gives in his book Form Design Patterns.

In web-based products from e-commerce stores to email clients to accounting software you often find index pages where each item in a list (or row in a table) has a Delete option. This is often coded as a link… but it shouldn’t be.

I liked this comment by Rails developer Dan where he advises a fellow Rails developer that to create his Delete control he should use a form rather than a link, via Rails’s button_to method.

Dan mentions that in the past Rails UJS set an unsdesirable historical precedent by including a pattern of hijacking links for non-GET reqests.

But per the HTML standard, links are for navigation:

Hyperlinks… are links to other resources that… cause the user agent to navigate to those resources, e.g. to visit them in a browser or download them.

And as Dan goes on to say that’s why links make a GET request.

A GET request is a visit, it says “show me this” and it’s idempotent. When you make the same request it’ll show the same thing.

If on the other hand you want a control that performs an action (in this case request an entity to be deleted) then the appropriate HTML element is usually a button, and in this case a submit button within a form.

Relatedly, Jeremy Keith previously wrote about how to use request methods properly in his excellent post Get safe.

I enjoyed this two-part tutorial from Chris arising from his critique of a subscription form plugin which includes the entire React library to achieve what could be done with a lightweight HTML and vanilla JavaScript solution. Chris advocates a progressively-enhanced approach. Instead of rendering the form with JavaScript he renders it in HTML and argues that not only is there no need for the former approach – because forms natively work without JavaScript – but also it only introduces fragility where we could provide resilience.

Part one: Using a wrecking ball when a hammer would suffice

Part two: More HTML, less JavaScript

I also recreated the front-end parts in a codepen to help this sink in.

Lastly, as someone who always favours resilience over fragility I wanted to take a moment to consider the part that Chris didn’t cover – why JavaScript is required at all. I guess it’s because, being a plugin, this is intended for portability and you as author have decided you want the error and success messaging to be “white-labelled” on the consuming website rather than for the user to be taken to a separate website. You don’t know the context’s stack so to provide a universally-supported solution you use JavaScript to handle the messaging, which then means you need to use JS to orchestrate everything else – preventing default submission, validating, fetch-based submission and API response handling.