The many languages of front-end development
I have been working on a series of web forms lately. At the end of many days, I often had not made much actual progress, but my brain felt like a fried vegetable anyway.
While I was working on a feature today, a multilingual text input component, I realized why: I have been juggling a lot of languages this whole time.
Languages#
First, there is HTML and the elements that comprise a simple form: <form>, <label>, <input> and <button>. There are of course more than those to choose from for specific tasks, like <fieldset> if you need to group related input fields. Also, there are a couple of attributes to consider, for example id, type , required and autocomplete for inputs. There is for as one way to associate a label with an input and create what is called the "accessible name" for the input.
ARIA (sometimes even WAI-ARIA, an acronym for "Web Accessibility Initiative – Accessible Rich Internet Applications") certainly feels like its own language that is also expressed via HTML attributes. ARIA should only be used when HTML alone does not convey enough meaning or information by itself. aria-describedby is a great way to to associate instructions with an input field, so that assistive software can pick up on the connection. A screenreader like NVDA could then read out the instructions when the associated input is focused. aria-invalid="true" can be used to communicate that a certain input field cannot be accepted because it is in an invalid state – for example, because an input value is required, but the field was left empty.
To communicate the same invalid state visually, CSS comes to play. A warning icon or different graphical distinction should be used to highlight which field is in need of attention. And that's not the only thing CSS is used for; every HTML element is shaped and positioned just so with CSS to achieve a clear and consistent overall form presentation.
For more elaborate form components, there's JavaScript (JS) and Progressive Enhancement. The aria-invalid="true" from earlier might have been added with JS – when focus moved out of a required field left empty – to trigger an immediate feedback. JS is also useful to conditionally reveal form fields that are only necessary if a certain answer was given earlier. "Are you a front-end developer?" If yes, display the follow-up question "Do you work on the front or the back of the front-end – or both?".
That's four languages already: HTML, ARIA, CSS and JavaScript. But it's 2021, right? We're a bit more sophisticated these days and usually use a templating language instead of writing HTML directly. In my case, that's Twig. Twig is marketed as "the flexible, fast, and secure template engine for PHP" and has powerful features that HTML is sadly lacking. I really like it – but it is another language to be learned, with its own quirks to handle.
Twig was conceived for Symfony, which apparently is both "a set of reusable PHP components" and "a PHP framework for web projects". In our projects, business logic, field type configuration and actual composition of forms and fields mostly happens in PHP, so I have to speak PHP as well. At least enough to understand the equivalent of the useful phrases every tourist picks up quickly in a foreign county: "Sí", "Nein", "Deux baguettes, s'il vous plait!", "Dimanakah tandas?" and the ever useful "How do I customize the error message for this particular form input constraint?".
Dialects#
Now there are six languages: HTML, ARIA, CSS, JavaScript, Twig and PHP. But wait! I haven't mentioned dialects yet. Yes, dialects. Because even with all the fantastic standardization and specification work that's been done, there are still differences in how these languages are processed. WebKit, the browser engine that powers Apple's Safari browser, requires a bit of extra finesse, sorry, CSS to customize the look of certain form elements. Microsoft's Internet Explorer used to be the same, but it was replaced by Edge and its dialect is slowly becoming extinct.
All browsers combine HTML, ARIA and CSS to generate the so-called accessibility tree and pass it on to the operating system's accessibility API (details vary slightly between platforms), which is then exposed to assistive software. Different assistive software takes the exposed information and uses it in different ways – or doesn't. Remember aria-invalid="true"? It's widely supported and safe to use! Expect it doesn't work if it is used on a <select> and if the assistive software is VoiceOver in Safari on iOS. Maybe. I haven't actually tested this myself, I'm using a11ysupport.io, which lists this as unsupported on Nov 19, 2021. In any case, there are lots of nuances to be aware of when you try out your hard-learned HTML and ARIA skills in the real world. It's a bit like Chinese dialects in Hongkong: speaking Mandarin is definitely a good start, but Cantonese will supposedly get you further.
Last but not least, there's standard Twig and there's this special world of magic (not in the good way) Twig functions and blocks that is Symfony Form Themes.
It's okay to feel exhausted#
So. Six languages, with dialects. I don't actually know how to count the dialects, as it'd be excessive to multiply each browser engine (WebKit, Chromium, Gecko) with HTML, ARIA and CSS and then multiply the result again with each assistive software.
But thanks to my languages epiphany I certainly feel less inadequate at the end of this day.