
This unit welcomes you to the course and explains how it’s structured, what you can expect, and how to get the most out of it. I’ll point you to the key resources and downloads you’ll need so you can follow along in later units.
In this section, you’ll learn how to label fields, connect helpful descriptions and group related controls, so people know what information to provide.
In this unit, you’ll learn how to connect labels to form fields, explore ARIA alternatives and check your work with NVDA and the accessibility inspector.
In this unit, you’ll learn how to connect helpful instructions to form fields using aria-describedby, so screen reader users don’t miss important details.
"In person" or "Online" but what’s the question? In this unit, you’ll learn how to group related controls using fieldset and legend, giving screen reader users important shared context.
In this section summary we'll recap how clear labels, connected descriptions and grouped controls help people understand your forms and why these relationships need to work in the code, not just on screen.
In this section, you’ll learn how to enable autocomplete, clearly identify required fields and communicate character limits helping people enter information with less effort and fewer surprises.
In this unit, you’ll learn how to combine clear visible labels with required and aria-required to communicate which fields need completing.
In this unit, you’ll learn how to make limits clear upfront and use role="status" to announce the remaining character count to screen reader users without moving focus.
In this section summary we’ll recap how autocomplete, clearly identified required fields and accessible character counters help people complete forms with less effort, understand what’s expected and avoid preventable mistakes.
Mistakes happen, and good form validation should help people recover from them. In this section, you’ll learn how to provide clear inline feedback and useful error summaries so people can understand what went wrong, find the problem and fix it.
In this unit, you’ll learn how to identify invalid fields with aria-invalid and connect helpful error messages using aria-describedby. You’ll then check that errors are communicated and cleared correctly with NVDA and the accessibility inspector.
In this unit, you’ll learn how to create an error summary that brings problems together, moves focus to the summary region and provides links direct to the fields that need attention.
In this section summary we’ll recap how inline errors and error summaries work together to make problems easier to find, understand and correct.
Form controls can change as people move through a form, but those changes need to remain clear and predictable. In this section, you’ll learn better ways to handle disabled, read-only and hidden fields so people only encounter controls they can understand and use.
In this unit, you’ll learn why unavailable controls are often better removed and how to explain their availability with ordinary text.
Read-only fields can look interactive even when there’s nothing for the user to do. In this unit, you’ll learn when ordinary text is a better choice and how to remove unnecessary focus stops.
In this unit, you’ll learn why techniques such as opacity: 0 can create problems, how to use the hidden attribute instead, and how to check that fields appear in the accessibility tree only when they’re relevant.
Let’s bring it all together. Forms should only present controls when they’re relevant and usable. We’ll recap why ordinary text is often better than disabled or read-only fields, and how robust hiding techniques help keep keyboard and screen reader experiences clear and predictable.
You’ve made it! In this final section, we’ll look back at what you’ve learned from labelling and describing controls to validation, field states and testing with assistive technology. Bringing together the practical skills you can now take into your own projects.
Now it’s time to put what you’ve learned into practice. Use your own forms, design system components and the course CodePens to keep testing, experimenting and building confidence with accessible form patterns. The goal isn’t just to pass WCAG, it’s to make forms easier for people to understand, complete and recover from when things go wrong.
The course may be finished, but the conversation doesn’t have to stop here. In this final unit, you’ll find the best ways to stay in touch, ask questions, share what you’ve improved and keep building your accessibility knowledge after the course.
I’d love to hear what you thought of the course. In this final unit, you’ll find ways to share what worked, what could be improved and how the course could better support you in building and reviewing accessible forms.
You know how to build a form. But do you know what makes it accessible and how to check your work?
You can create fields, validate input and submit information successfully. Yet questions about accessibility can still leave you unsure what to do.
Is adding a label enough? How should instructions be connected to a field? How will someone using a screen reader discover an error? What happens when you disable a control or hide a group of questions?
This course is for web developers who need to understand accessibility and apply it to the forms they build.
It’s designed as an evergreen course, with the content updated as accessibility guidance, browser behaviour and development practices evolve.
Through focused explanations, demonstrations and practical coding examples, you’ll learn what to implement, why it matters and how to test the result. You’ll work with the HTML and JavaScript behind familiar form features and explore how your decisions affect people using a keyboard or screen reader.
Understand the decisions, not just the attributes
Knowing that an accessibility technique exists is different from knowing when and how to use it.
You might have seen examples using labels, ARIA attributes or error summaries without fully understanding the problem they solve. Copying the code does not necessarily help when your own form behaves differently.
This course connects each technique to its purpose. You’ll explore what users need, what the browser communicates to assistive technology, and how changes to your code affect that experience.
The aim is to help you make informed implementation decisions, rather than depending on snippets you cannot confidently explain or adapt.
What you’ll be able to do
Make fields and instructions easier to understand. Associate labels, descriptions and supporting information with form controls. Understand how a control receives its accessible name, the name assistive technology uses to identify it.
Give related controls the context they need. Group questions and choices so users can understand both the individual controls and their shared purpose.
Help people complete forms with fewer uncertainties. Use autocomplete, required-field indicators and character-limit information to communicate what is expected and support form completion.
Make validation errors easier to discover and correct. Build accessible inline validation and error summaries that explain what went wrong and help users reach the fields that need attention.
Handle form states with an understanding of their effects. Explore how disabled, read-only and hidden controls behave for keyboard and screen reader users and recognise when an implementation creates confusion or barriers.
See the problem. Change the code. Check the result.
You won’t only see a finished example and be told that it is accessible.
Each unit starts with a specific problem. We’ll explore how the form behaves, investigate what is going wrong and work through the changes needed to improve it.
Screen reader demonstrations let you hear how controls and information are presented. Browser accessibility tools let you inspect the accessibility tree—the information the browser exposes to assistive technology.
Then we’ll test the changed implementation so you can connect the code with an observable difference in behaviour.
This gives you a practical way to investigate your own forms, rather than relying on whether they look right.
Work with the examples yourself
Runnable CodePen examples let you move from watching a technique to trying it.
Follow along with the code, make changes and explore what happens. Return to the examples when you need a reminder or adapt the techniques to a form in your own project.
Lessons are short and focused. Work through the course in sequence to build your understanding, then revisit individual topics when you encounter a similar problem during development.
Focused on the work you do as a developer
Whether you’re building a new form, improving an existing one or responding to accessibility feedback, this course focuses on the implementation decisions you need to make.
Accessibility concepts are explained through familiar development tasks: labelling fields, adding instructions, validating input and managing the visibility and state of controls.
The focus is not simply on learning accessibility terminology. It is on understanding what that terminology means for the code you write and the experience it creates.
Learn from the accessibility expert
I’m Ross Mullen, an accessibility expert. I work with development teams dealing with the kinds of form accessibility problems covered in this course.
These lessons bring that practical experience into explanations, demonstrations and examples you can work through yourself.
My aim is to help you understand why a solution works, so you can apply that understanding when your next project does not look exactly like the course example.
Join the course and learn to build, improve and test accessible forms—with an understanding you can take into your own development work.