Introduction
This is the all•Access podcast Access & Allies. My name is Rowan; I’m the co-Founder of All Access and a web accessibility auditor for the government of British Columbia’s Digital Government team.
The goal of Access & Allies is to attempt to break down any digital accessibility topic under the sun to answer any and all of your questions around making digital tools more accessible. Thanks for tuning in, and if you prefer to read along, make sure to find this episode’s transcript in the notes — along with any resources I mention.
Now, let’s get started with today’s topic: Make digitally accessible web forms!
WCAG Standards
To talk about accessible forms, we first need to isolate the Web Content Accessibility Guidelines’ relevant success criteria. Then we can discuss how to meet them.
If you’re new to the podcast or don’t know what these are, the Web Content Accessibility Guidelines, or WCAG, are the international standard for web accessibility. We are now using version 2.2, which has 86 success criteria in total. Each criteria is assigned a level which may be A, double A, or triple A, which indicate the level of priority these should take in making your web content accessible. A is the bare minimum must-haves of accessible content, whereas triple A is top tier. Double A is the standard for most organizations and government institutions.
I’m going to list each success criteria by name and explain what each one means, and you will be able to find each criteria listed in the notes next to it’s success criteria code.
1.3.1 Info and Relationships (A)
The first standard to meet is Info and Relationships which is an A-level standard, meaning it’s a must. This states, “Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.”
The “What to do” section under “Understanding” this success criterion says you want to use code to reinforce relationships and information conveyed through presentation.
Code you might specifically want to use in this case is “fieldset” to group related inputs, and “legend” to label sections of the form and provide context for non-sighted users.
1.3.5 Identify Input Purpose (AA)
Next is Identify Input Purpose which is a double A criteria. the WCAG states “The purpose of each input field collecting information about the user can be programmatically determined when:
The input field serves a purpose identified in the Input Purposes for user interface components section” (which I’ll link in the notes section); and
“The content is implemented using technologies with support for identifying the expected meaning for form input data.”The “What to do section” breaks it down: Use code to indicate the purpose of common inputs, where technology allows. This makes it easier to fill out the form for some individuals with cognitive disabilities, such as recall issues and dyslexia, as examples.
The input type attribute is important here, as is the autocomplete attribute.
And not only does the autocomplete attribute help people with memory issues and other disabilities, but it’s a huge time saver for everyone in general.
1.4.1 Use of Colour (A)
Use of Colour is next on our list and it is an A-level success criterion. It states “Colour is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.”
Meaning, don’t just use colour to distinguish information. Use additional methods such as shape, text, or iconography in addition to colour. This is especially important for colour blind users as many people see colour in different ways. If you have red text to indicate important information, make sure to add a symbol next to it as well. Many forms indicate important text with an asterix and put “must respond” in brackets or something like that, and explain the significance of the asterix at the top of the form.
2.5.2 Pointer Cancellation (A)
Next up, Pointer Cancellation, an A-level criterion. This one is technically difficult to understand through what the WCAG has written, so to paraphrase what they have, a user should be able to abort triggering an action by moving away from a button before releasing the key, and/or they should have the option to undo any mistakes or go backwards without losing progress.
This allows anyone to make it easier to recover from an action they didn’t mean to do. Most people, if not all, can relate to this one. Nothing is more frustrating that realising you input the wrong information on the previous screen, going back and realising everything you did is lost.
But more than that, it’s essential for people with motor control issues and certain cognitive disabilities.
3.2.2 On Input (A)
Next is On Input which is an A-level criterion. It states, “Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behaviour before using the component.”
The WCAG breaks this down as, “Forewarn users if their context will change based on their input.” An example of this might be indicating if selecting a certain response will populate an additional following question. Another example is separate fields for each section of a phone number, where the focus automatically moves to the next field when one is completed. Explaining each of these changes in context to the user before they engage with the content is important for people with reading and intellectual disabilities, as well as people who struggle with interpreting visual cues and people with low vision.
3.3.1 Error Identification (A)
The next success criterion is Error Identification, a level-A criterion. It is that, “If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.”
What this means is that any errors that come up must be clearly defined for users so they know how to fix the issue. It’s important to keep in mind not only our audience members with cognitive disabilities here, but our non-sighted users as well. When you’re creating these error notifications, make sure they are in a location and format that is accessible to screen readers. I’ve come across forms during audits where error notifications act as pop ups in the top right corner, then they disappear (which, by the way, doesn’t meet criterion Timing Adjustable) and anyone relying on a screen reader has no idea why their form isn’t announcing the next step.
2.2.1 Keyboard (A), 2.1.2 No Keyboard Trap (A), and 1.3.1 Meaningful Sequence (A)
There are three success criteria here that I find often go together and they are all A-level criteria.
The first is: Keyboard. It is one that’s really simple but often goes overlooked on web forms. When you are navigating the form with just a keyboard using the tab keys, can you navigate through everything intuitively without any special timings or unexpected keystrokes?
The second is No Keyboard Trap. If you are selecting a radial button or find yourself in a dropdown menu, can you navigate out of these selections and onto the next question with the tab or enter keys? Or do you get stuck?
The third is Meaningful Sequence. Are you able to navigate the form with your keyboard and/or with a screen reader in the order as intended? Or do you jump around?
Other criteria to keep in mind
These are the main criteria to keep in mind when creating web forms. However, it’s important to meet all your other standards that might apply as well, such as Focus Not Obscured (Minimum) where no content should be covered by other author-created content. Or Enough Contrast (Minimum) where you’re maintaining the proper colour contrast ratio of 4.5:1 in most cases. Focus Visible is also really important on any interactive element so users can see where they are at all times.
Takeaways
The main takeaways here are:
Is everything perceivable to the user, regardless of if they are using assistive technology or what that technology might be?
- Does everything function as it should?
- And is enough context provided, both through the interface and the metadata?
- Basically, as always, it all boils down to POUR: Perceivable, Operable, Understandable, and Robust.
Conclusion
Thank you for listening to this episode of Access & Allies on how to make forms accessible. I hope this has provided you with some new information, or at least confirmed some old knowledge. A lot of businesses out there make forms and wonder why they aren’t getting as many responses as they should be. Well, sometimes the proof is in the pudding, and it’s important to test out your forms using different methods before sending it out to the masses. Because if you can’t navigate your content in different ways, neither can others.
If you’re still wondering about form accessibility, feel free to check out the resources provided in the notes section. And if you have any questions or comments, please feel free to reach out at info@allaccess.dev or through LinkedIn.
Want your site assessed for accessibility, or looking for consultation on your site plan? Make sure to reach out about that as well — we want to know how we can support you.
It’s been fun talking at you and until next time on Access & Allies.
