In this episode, learn about the Web Content Accessibility Guidelines' Success Criteria that are most relevant to creating accessible web forms.
00:00 | Introduction
00:36 | WCAG Standards
01:32 | 1.3.1 Info and Relationships (A)
02:10 | 1.3.5 Identify Input Purpose (AA)
03:06 | 1.4.1 Use of Colour (A)
03:51 | 2.5.2 Pointer Cancellation (A)
04:35 | 3.2.2 On Input (A)
05:25 | 3.3.1 Error Identification (A)
06:16 | 2.2.1 Keyboard (A), 2.1.2 No Keyboard Trap (A), and 1.3.1 Meaningful Sequence (A)
06:59 | Other criteria to keep in mind
07:28 | Takeaways
07:50 | Conclusion
Twists & Turns | The Paul Dunlea Group
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!
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.
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.
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 “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.
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.
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.
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.
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.
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?
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.
The main takeaways here are:
Basically, as always, it all boils down to POUR: Perceivable, Operable, Understandable, and Robust.
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.