Austin Gil has kicked off the first in a five-part series about “HTML Forms Right” and to starts with semantics. It’s talking to the “we build our front-ends with JavaScript” crowd. The first block of code is an example of an Ajax form submission where the data submitted is gathered through the JavaScript API FormData.
Why is that so vital? Well, no <form> tag, no FormData. Why else use a form (aside from the Enter-key submission):
“But Austin, I’m building an SPA. Therefore if the user even sees the form, it means JavaScript MUST be enabled.” And you’d be right. Although, if it is an important form, you may want to consider supporting a no-JS world. The day may come that you want to implement SSR.
Server-Side Rendering (SSR) is going to get easier and easier to do as the benefits of it become more and more obvious. Google tells us a page that is client-side rendered has week-long-ish queue to get indexed and re-indexed on changes. Not to mention SSR is almost definitely going to be far faster to load.
Oscar Braunert’s Inclusive Inputs is a nice follow-up read as it begins with form HTML that is so close to being right, but is painfully not right. (Hint: it’s missing the label/input connection). Then he gets into interesting patterns like how to accessibly mark up required fields and fields with errors. Like:
<div class="form-group">
<label for="password">
Password
<span class="required" aria-hidden="true">*</span>
<span class="sr-only">required</span>
</label>
<input
type="password"
id="password"
name="password"
aria-describedby="desc_pw"
>
<p class="aside" id="desc_pw">Your password needs to have at least eight characters.</p>
</div>Amber Wilson gets into Accessible HTML elements with the twist of avoiding any ARIA usage at all:
You may be aware that ARIA roles are often used with HTML elements. I haven’t written about them here, as it’s good to see how HTML written without ARIA can still be accessible.
Shout out to <dl>.
Sarah Higley does get into ARIA in Roles and relationships, but she warns us to be very careful upfront:
[…] a budding accessibility practitioner might find themselves experimenting with more serious roles like
menu,listbox, or eventreegrid. These are tantalizing, powerful patterns that allow you to create experiences that are not supported by only vanilla HTML. Unfortunately, they are also brittle; even small mistakes in using these roles can take a user on a very bad trip.
Talk to your kids about ARIA before it’s too late.
Ideally, don’t use ARIA at all. But if the accessibility is screwed up to the point it can’t be fixed at the DOM level, Sarah gets into some tricks. For example, one uses role="presentation" to essentially remove an element’s default role (when it is in the way).
Speaking of ARIA and not using it unless you have to, one of the things you can do with ARIA is label controls. Adrian Roselli has thoughts on how best to do that:
Here is the priority I follow when assigning an accessible name to a control:
1. Native HTML techniques
2.aria-labelledbypointing at existing visible text
3. Visibly-hidden content that is still in the page
4.aria-label