Creating a Form for Screen Reader Accessibility

Web accessibility is becoming more and more important these days. If you are not used to implementing web accessibility, it sounds difficult. In reality, making website accessible takes only a little bit of effort and knowledge. HTML 5 supports a lot of accessibility functionality if you use the correct tags and follow the standard best practice.

Web accessibility is a large topic to cover. In this post, let’s focus on screen reader accessibility for forms.

Before we start

There are two Google Chrome plugins that I recommend to install.

Axe is a free chrome extension for web accessibility testing. It scans your page and report back with accessibility issues. Scanning any website and checking the issues will teach you a lot about accessibility.

ChromeVox classic extension is a free screen reader that you can use on Chrome. I am recommending this because it is free and probably just good enough to start with. However, ChromeVox does behave differently from the real screen readers out there. If the screen reader experience is critical for your website, I would insist on getting the real screen reader and test your site with it.

Tips

(1) Provide extra information with invisible paragraph

You can provide extra information with invisible paragraph. This can be achieved by adding a class name with styling to hide the paragraph as below. In this way, screen reader will read out the extra information.

(2) Use aria-required attribute for required input fields

When your input field is required, setting the aria-required attribute to true will make screen reader to say the field is required. Having only the required attribute in the input field will not screen reader to indicate the field is required.

(3) Carefully consider what you put in the place holder

The screen reader will read the placeholder value as ‘hint: enter your first name’. For example, when you put first name as the placeholder value, the screen reader will read out as ‘first name hint: first name’. The extra information is redundant. Unless you have something more to add, placeholder value may not be needed.

(4) Do not use display none to customise radio or checkbox input

If your input has display: none, the screen reader will ignore it. We often customise our radio or checkbox input with CSS by hiding the default browser input. Hide the default input by using sr-only class described in (1).

(5) Be aware of redundant ARIA attributes

Role is not needed for input field with correct type (example here). When you use input with type=”checkbox” as in the example, role=”checkbox” is redundant.

The same goes for aria-checked attribute. For radio or checkbox input, we don’t need to explicitly assign value to aria-checked by JavaScript if the input field has the type specified. Screen reader will read if the input is checked or not.

(6) Use HTML5 semantic elements instead of div or span

This applies not only for a screen-reader accessible form. It applies to web accessibility as well as HTML best practice. Instead of using div, use HTML5 semantic element wherever you can. For example, using the nav tag instead of div with class=”nav”. Sticking to the best HTML5 practice will make website accessible.

(7) Test the site with a screen reader

Accessibility testing tools like axe is nice. But, it pays off to invest in a real screen reader for testing. Unless you use the real one, you will never know what the experience is like on your website.

Example

I made an example (Accessibility Form Example) where I implemented the tips presented in this post. Forms can be switched between screen reader friendly version and not so friendly version. It is not perfect, but is a good start for you to get started with screen reader accessibility. The source code is here if you are interested. It is build as a SAP with TypeScript.

Resources

Google’s web fundamentals is a good resource for anything related to front-end development. It offers a extensive section on web accessibility. This is the best place to get started. If you want to be a web accessibility expert, Deque University offers online training. The website also has a heaps of resources about accessibility.

Here are the references I used for this post.

Front-End
TypeScript: type aliases to check type equality

This post is to analyse how the type equality check by using type aliases proposed by Matt Pocock in his twitter post. These type aliases allow us to elegantly express type equality checks in unit tests. All we need to do is to pass the output and expected types in …

Front-End
Fixing it.only type error in Jest

If you are getting a type error with it.only in Jest, it could be due to incorrect TypeScript typings or incompatible versions of Jest and TypeScript. To resolve this issue, you can try the following steps: Make sure you have the latest versions of Jest and its TypeScript typings installed …

Front-End
yup conditional validation example

Here’s an example of a Yup validation logic where the first input field is optional but, if filled, it must contain only alphabetic characters, and the second input field is required: import * as Yup from “yup”; const validationSchema = Yup.object().shape({ firstField: Yup.string().matches(/^[A-Za-z]*$/, { message: “First field must contain only …