Digital forms serve many purposes, from capturing customer support questions to submitting job applications. And designating specific form fields as “required” helps ensure end users can successfully submit these forms. But this step is often overlooked, creating a frustrating user experience (UX), especially for people with various disabilities. Fortunately, you can avoid these scenarios and other content-related obstacles through clear communication. This blog compares HTML-5 required to ARIA-required methods to give you a path forward.
Let’s start by understanding what sets them apart.
What’s the Difference Between HTML Required and ARIA Required?
Unlike HTML, ARIA isn’t a programming language but a set of attributes you can add to HTML elements to increase accessibility. These attributes communicate to assistive technologies like screen readers used on websites and apps through modern browsers. To that end, the ARIA–required attributes show when end-user input is required to submit a form. By contrast, HTML 5-required attributes directly communicate with browsers to prevent them from accepting forms with one or more empty “required” fields.
Next, you’ll learn how AIRA and HTML work together.
How ARIA Relates to HTML Accessibility Standards
ARIA supports HTML (especially Java Script) to make content and apps more digitally accessible through assistive technologies. Like all digital tech, ARIA has varying degrees of compatibility with various browsers, operating systems, assistive technologies, and their respective versions. An outdated software version, for example, may not support a particular ARIA role.
Many end users who rely on assistive tech are also skeptical about software upgrades that may make it harder to interact with and engage in digital interfaces. That’s why semantic HTML is essential to support assistive technology, which this blog expounds on later. But it’s best to test your ARIA efforts with assistive technology, as browser emulators/ simulators and proxy assistive tech solutions can’t fully guarantee the desired UX functionality.
Avoiding Inaccessible Form Elements
Of course, some forms have only required fields, which you can address in your introductory content (“All fields required”). However, a mixture of required and optional fields is more typical, and you can distinguish the two categories in many ways. The problem is some of these approaches aren’t digitally accessible. An inaccessible example is using different colored labels to differentiate between required and optional fields. By just using colors, you alienate colorblind, visually impaired, and blind users who can’t distinguish different colors.
Another common approach is adding asterisks or icons for required fields, but only some screen readers recognize this method. How it’s inserted and whether it has alt text determines if an icon is readable for end users. While some may argue that an asterisk alone will suffice, many site creators want to communicate a field’s required status more clearly.
You’ve learned a lot, but how can you apply that knowledge? The proven tips in the following section are an excellent starting point.
Five Tips for Creating Accessible Forms Using HTML
Follow these proven tips to help meet HTML accessibility standards:
1. Integrate Semantic HTML
Semantic HTML uses tags (e.g., <header>, <article>, and <footer>) to describe content to end users. Non-semantic HTML tags, on the other hand (e.g., <div> and <span>), represent only visual elements. Semantic HTML is critical for accessibility because it makes it easier for assistive technologies like screen readers to decipher webpage content.
2. Provide Easy-To-Understand Labels
Labels help end users understand each form element’s purpose—so they need to be a straightforward description of the info they need to enter.
3. Use The Correct Form Inputs
HTML has numerous inputs for different data types, and using the correct one expedites and simplifies data input for end users. Examples include the “email” input that ensures valid email addresses and the “tel” input for telephone numbers.
4. Make Instructions Clear
Consider including a brief description or instructions for each form element to provide additional context and guidance. Also, provide feedback or error messages so end users can correct their mistakes.
5. Provide Keyboard Navigation
Ensure people can navigate your forms using only a keyboard. Ideally, end users can tab through forms intuitively and easily see each element they select.
One Piece of the Accessibility Puzzle
All website users have experienced frustrating error messages when filling out and submitting forms. And that’s just one of many examples that cause people to leave websites before they fully engage with a company’s products and services. These obstacles interrupt the UX for different ability levels and hurt website, app, and device performance, negatively impacting customer loyalty. The point is that digital inaccessibility is bad for business but even worse for people with disabilities. And it’s on executive decision-makers and their web development teams to eliminate unnecessary obstacles. Using HTML–required and AIRA–required methods correctly is just one essential piece of the inclusivity puzzle, but it’s certainly a step in the right direction.
Learn how UserWay can complete your accessibility puzzle now and in the future.
UserWay: Everything You Need for Digital Accessibility
Digital accessibility is at the core of UserWay’s mission, from AI-powered tools to industry-leading legal support and commission-driven partnership programs. Let an accessibility expert guide your next steps, or try our products and services today.
Answers to Common FAQs
What’s The Difference Between Semantic and Non-Semantic HTML?
Semantic HTML conveys the meaning of functionality elements, while non-semantic HTML only relates to appearance.
What Makes HTML 5 Digitally Accessible?
Content must be accessible from desktop computers (using a keyboard or mouse), screen-reader software, audio browsers, older-version browsers and computers, and mobile and touch-driven devices.
What Are the Best Practices for Required vs. ARIA-Required In Form Fields?
It depends on whether or not you use native elements. HTML tags like <button> create native features. By contrast, non-native variables like role=”button” define elements. So use “required” for things like first names, which use <input> in coding. On the other hand, add aria–required attributes to elements that use non-native information.
