Lukas Cornille

On September 14th, <a href="https://www.inthepocket.com/blog/in-the-pocket-signed-the-digital-inclusion-charter">In The Pocket signed the Digital Inclusion Charter</a>
to underline our commitment to fighting digital exclusion. I'll explain how
this can be applied to handling form submissions in this post.
In the example, which can be found on <a href="https://github.com/inthepocket/accessible-forms">GitHub</a>,
a user can fill in their name and email address, which will be validated in
Remix when submitting the form. There are two states on the form. The first one
will occur if there are validation errors, and the second is a toast message
which will appear and disappear when the user has successfully submitted the
form.
First up, want to see a demo? 
Just head over to this <a href="https://stackblitz.com/github/inthepocket/accessible-forms">StackBlitz</a>
app, click the &quot;Open in New Window&quot; in the header and enable VoiceOver.
<h2>Native browser behaviour</h2>
<img src="https://inthepocket.dev/img/2022-03-25-accessible-forms/native-browser-validation.png" alt="native browser validation" />
Before I started coding specifically towards React/Remix, I first had a look at
how native browser validation behaves. If we look at the screenshot above,
we'll notice that browsers validate input fields one by one. If we have an
error in a particular input field, that input field will be focused, and an
unstyled (and rather ugly) browser popover will be displayed with an error
message.
This is important because we should take the native browser behaviour as a base
for our validation when we want to create something custom. In addition, users
expect UI to be consistent, making it easier to navigate a page.
<h2>Custom validation</h2>
Because we're always striving toward spectacular UI and UX, we decided to
implement the following improvements towards this form:
<ul>
<li>Validate the entire form when submitting the form.</li>
<li>Show all validation errors in a styled error message underneath the input.</li>
<li>When there are no validation errors, display a success message.</li>
</ul>
Validating the entire form is easily done thanks to Remix's action function and
<a href="https://www.npmjs.com/package/yup">Yup</a>. All I had to do was create a function
that validates our form data based on the validation schema and return each
error. The specific code isn't present here because it would bloat the post,
so again another incentive to have a look at the <a href="https://github.com/inthepocket/accessible-forms">GitHub repo</a> 😊.
We created a span element for each input element and bound our error messages
to show the validation errors in a styled error message. This leaves us with
this beautiful validated form.
<img src="https://inthepocket.dev/img/2022-03-25-accessible-forms/custom-validation.png" alt="custom validation" />
<h2>Accessibility</h2>
Now that we have a beautiful UI, thanks to custom validation, let's improve the
UX by implementing the best features of native browser behaviour and making it
accessible thanks to the use of some aria attributes.
After reading the <a href="https://www.w3.org/WAI/tutorials/forms/">Web Accessible Initiative</a>
tutorial regarding forms we can make our forms accessible by using the
following code:
<pre class="language-tsx"><code class="language-tsx">const Index = () => { const { toastRef, showToast } = useToast(); const actionData = useActionData(); const { formRef } = useAccessibleForm({ hasErrors: actionData?.hasErrors, errors: actionData?.errors, showToast, }); return ( &lt;main> &lt;Toast role="alert" aria-live="polite" /> &lt;Form method="post" aria-label="Personal information form" noValidate> &lt;div className="form-group"> &lt;label htmlFor="first-name">First name&lt;/label> &lt;input type="text" id="first-name" name="firstName" aria-required aria-describedby="first-name-error" /> &lt;span id="first-name-error" aria-hidden> {actionData?.errors?.firstName} &lt;/span> &lt;/div> &lt;/Form> &lt;/main> ); };</code></pre>
Three things help to make this form accessible.
First up, a toast component has an alert role and an aria-live attribute.
The alert role is used to communicate an important and usually time-sensitive
message to the user. Seeing as form validation is quite important, this
attribute fits perfectly! However, as the <a href="https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/alert_role">docs</a>
state, the alert role also causes aria-live to be set with the value
&quot;assertive&quot;, interrupting the user's screen reader. To prevent this, we set the
aria-live attribute to &quot;polite&quot;.
Second, when the form contains errors, the <code>useAccessibleForm()</code> hook will:
<ul>
<li>generate all errors,</li>
<li>create a human-readable error message,</li>
<li>call the <code>showToast()</code> function with this error message.</li>
</ul>
Because the error messages are shown underneath the input fields, we don't have
to show the toast. However, the screenreader will still read this out thanks to
the aria-live attribute.
Last, to bring everything together, we're hiding the error message for the
screenreader space. To add the relationship between the input field and the
error message, we can use the aria-described by attribute, which will ensure
the error message will be read out after the user navigates to the input field.
As you can see, we were able to make the web a better place for people using a
screenreader with little effort. We can do plenty of other things to improve
accessibility, and usually, it comes down to our mindset. I hope this was
useful, and you'll probably see some more in the future!
<a href="https://www.inthepocket.com/blog/how-to-make-your-forms-accessible">Original blogpost</a>
<a href="https://github.com/inthepocket/accessible-forms">GitHub repo</a>

On September 14th, In The Pocket signed the Digital Inclusion Charter to underline our commitment in fighting digital exclusion. In this post I&#39;ll explain how this can be applied to handling form submissions.

Building accessible forms

Remain up to date in the continuously evolving technology landscape. The ITP Tech Radar reflects our current view on software engineering technologies.

Remix

Why do we assess this technology?

Related technologies

Next.js

Articles

Building accessible forms