Required Fields and Form Instructions

I’ll work through the anti-slop checklist systematically before editing.

Video: Required Fields and Form Instructions

0. Archetype alignment: Fix-Focused Technical Article. The draft follows Failure → Criterion → Failure Taxonomy → Fixes → Test → Checklist correctly. Structure is sound.

1. Hook: Strong and specific. The CSS asterisk opening is tactile and form-specific. Keep.

2. Generic opener phrases: None found.

3. Passive voice: Several instances. “Instructions must appear in the HTML before the input element they describe” – passive but acceptable (actor is genuinely “the developer/HTML”). “A red asterisk rendered via a CSS ::before pseudo-element does not exist” – fine. Will flag weaker ones.

4. Filler sentences: A few. “Both are required under WCAG 3.3.2 when the format is non-obvious” restates what the previous sentence said. “This is the redundancy trap” section has one filler sentence.

5. Bullet-point overuse: The “Common scenarios” list under Form Instructions could become a tight paragraph. There are three lists total – review.

6. CTA: The end-of-article CTA is naturalised and has no exclamation marks or urgency language. The scanner placeholder [SCANNER DATA: % of scanned forms with CSS-only asterisk indicators] needs to be removed cleanly per the brief’s own instruction (flag, don’t invent). No standalone scanner-promo H2 section present.

7. Weasel stats: No unsourced stats found. Sources are properly attributed.

8. Structural balance: Sections are roughly proportional. The “Four Methods” section is the longest at ~400 words, appropriate for the comparison table. No flag needed.

9. Ending: The current ending is a soft CTA sentence. It trails slightly. Sharpen.

10. Distinctiveness: Opening is distinctive. Closing is generic. Fix.

11. Article shape: Reads as implementation-ready and technical. Good Fix-Focused shape.

12. Source/section repetition: No forbidden stats (WebAIM 94.8%, 51 errors) appear. No generic “six failures” section. Clean.

Magistus house style checks: – Em dashes present in several places. Replace with periods, commas, colons, or plain hyphens. – En dashes: not found. – “The fix is not to make the asterisk ‘bigger’ or ‘redder'” – slightly flip, keep. – Scanner data placeholder: remove and replace with a clean note that real data should be inserted. – Paragraph rhythm: several sections have same-length paragraphs. Vary.

---

A red asterisk marks your required field. It looks correct. A developer reviewed it. But that asterisk lives in a CSS ::before rule. It does not exist in the accessibility tree. A screen reader user tabs to the field, hears only the field label, and has no idea a response is mandatory until the form rejects their submission.

That is a WCAG 3.3.2 Level A failure. Level A is the minimum baseline, not an advanced target. Under ADA Title III, according to ADA.gov’s guidance on web accessibility, there is no government-mandated compliance deadline for private businesses. Enforcement is lawsuit-driven, and courts consistently apply WCAG 2.1 AA as the de facto standard. A CSS asterisk that passes visual QA fails that standard completely.

---

What WCAG 3.3.2 Actually Requires (and Why Level A Matters)

WCAG Success Criterion 3.3.2 (Labels or Instructions) requires that when user input is expected, you provide labels or instructions. Level A is the floor. Every site must meet it regardless of size, budget, or industry.

The criterion has two parts. First, every input needs a label. Second, where the format or constraints are non-obvious, you need to provide instructions before the user reaches the field. A password field requiring at least one number and one symbol must say so before the user types, not in an error message after submission fails.

The programmatic part is what most implementations miss. A visible label is not enough. The label must be connected to the input in the HTML so that assistive technology can read it. A field with a text label sitting nearby but not linked via for/id or aria-labelledby is a silent failure: it looks right, it tests wrong.

WCAG 3.3.2 did not change between WCAG 2.1 and WCAG 2.2. If your forms passed this criterion in 2019, the standard has not moved. The failures that exist today were always failures.

---

Three Required-Field Failures That Pass Visual Review

These three patterns appear in audits constantly. They look fine in a browser. They fail the moment a screen reader enters the picture.

Failure 1: The CSS asterisk trap

A red asterisk rendered via a CSS ::before pseudo-element does not exist in the Browser Accessibility Tree and DevTools. The asterisk is in your stylesheet, not in the HTML content that assistive technology reads. Screen reader users hear no indication that the field is required. The fix is not to make the asterisk bigger or redder. Add a programmatic signal that actually exists in the document.

Failure 2: Placeholder text used as an instruction or label

A placeholder like "Enter your email address" disappears the moment the user starts typing. It is not reliably announced as a form instruction by all screen readers. It cannot carry the “required” signal. Placeholder misuse is a distinct failure from a missing label. A field can have a visible label and still fail if its format instructions only appear as placeholder text. The two failures have different fixes and must not be conflated.

Failure 3: Missing required attribute or aria-required

A field that is visually marked as required but lacks a programmatic signal in the HTML will never announce “required” when a screen reader focuses on it. Developers sometimes assume the asterisk or the word “required” in a nearby paragraph is sufficient. It is not. The HTML must tell assistive technology that this field is mandatory. A CSS class named .required is not the same as the HTML required attribute.

---

How to Mark Required Fields Correctly: Four Methods Compared

Here are the verified approaches, from most universally reliable to most context-specific.

1. Add “required” or “(required)” to the label text

Put the word directly inside the <label> element: First name (required). No additional ARIA attribute is needed. Every screen reader, in every browser, will read it. This is the safest choice for any standard HTML form.

2. Use the native HTML required attribute

Adding required to an <input> element tells the browser to announce “required” when focus lands on the field and blocks form submission until the field is filled. It works without any CSS. The limitation: sighted users will not see any visual change unless you add CSS to style required fields. Use it alongside a visible indicator. The attribute handles assistive technology; your CSS handles sighted users.

3. Use aria-required="true"

This is correct for custom UI components that cannot use a native <input>, such as custom date pickers, multi-select dropdowns built from <div> elements, or star-rating widgets. It tells assistive technology that the field is required without relying on native HTML form behavior.

Here is the critical trap: do not use both required and aria-required="true" on the same element. Most modern screen readers will announce “required” twice on the same field when both attributes are present. This is the redundancy trap. Choose one. For standard HTML inputs, use the native required attribute. For custom components, use aria-required="true".

4. Use an asterisk with a form-level explanation

An asterisk alone is never sufficient. If you use asterisks, include a note above the form, before any inputs, explaining the convention (“Fields marked * are required”). The asterisk must be in the HTML content, not generated by CSS. And if the required attribute or aria-required is already present, wrap the asterisk in aria-hidden="true" to prevent double-announcement.

Method	Screen Readers	Sighted Users	Blocks Submission	Use When
Label text “required”	✓	✓	✗	Always safe; always compliant
HTML required	✓	✗ (without CSS)	✓	Standard HTML form inputs
aria-required="true"	✓	✗	✗	Only for interactive elements that cannot use a standard HTML input, such as custom date pickers or multi-select dropdowns
Asterisk alone	✗	✓	✗	Never use as sole indicator

---

Form Instructions: The Placement Rule Most Sites Get Wrong

Form instructions are not the same as field labels. A label names the field. An instruction tells the user what kind of input is expected. Both are required under WCAG 3.3.2 when the format is non-obvious.

Instructions must appear in the HTML before the input element they describe. Not inside a tooltip that appears on focus. Not below the field. Not only in an error message after submission fails. A user who needs to know that a date field requires MM/DD/YYYY format must know that before they type, not after they fail. That is the placement rule, and it is an actionable constraint, not a stylistic preference.

The scenarios that most commonly require instructions are date fields (specify the expected format), password fields (state character requirements before the user creates a password), phone number fields (specify whether an area code is required), and forms with a mix of required and optional fields (a note at the top explaining the convention).

Placeholder text cannot carry these instructions. Placeholders disappear on input and are not reliably announced as instructions by all screen readers. A format hint that only lives in a placeholder is inaccessible.

Patient intake forms and appointment booking forms are a high-risk context for this failure. For more on that, see Website Accessibility for Medical Practices: Patient Access and ADA Risk.

---

Compliance Exposure: ADA, EAA, and Section 508

Under ADA Title III, private businesses have no government-mandated compliance deadline for web accessibility. Enforcement is lawsuit-driven. Courts apply WCAG 2.1 AA. Contact forms and checkout forms, the forms most likely to have required-field failures, appear frequently in complaints. Online ordering forms at restaurants are a common target. See Restaurant Website Accessibility: Menus, Reservations, and Online Ordering for where these failures cause direct business harm.

The European Accessibility Act (EAA) adds a harder deadline. According to the European Commission, the EAA came into force on June 28, 2025. It applies to any business with 10 or more employees or €2M or more in turnover that sells products or services into EU markets. Required field marking is audited under EN 301 549, which references WCAG 2.1 AA. If your business serves EU customers and your forms have not been reviewed since June 2025, you are already behind.

Section 508 applies to federal agencies and federally funded organizations. The current standard is WCAG 2.0 Level AA. If your organization has a federal contract or receives federal funding, required-field failures are a procurement issue, not a best-practice gap. Section 508 is covered in its own guide. The key point here is that it is a third distinct enforcement mechanism, not a synonym for the ADA.

This article is for general informational purposes and is not legal advice.

---

How to Test Required Field Accessibility in Five Steps

Step 1: Keyboard tab test. Tab through your form using only the keyboard. When focus lands on a required field, listen for the browser or screen reader to announce “required.” If you hear only the field label with no required indication, the programmatic signal is missing.

Step 2: CSS-off test. Disable styles in your browser (most developer tools allow this in one click). Confirm that required indicators, asterisks and the word “required,” still appear. If they disappear when CSS is off, they exist only as CSS-generated content and are invisible to assistive technology.

Step 3: Screen reader announcement check. Open NVDA (Windows) or VoiceOver (Mac/iOS) and navigate your form. Required fields must be announced as required before you interact with them. If the screen reader reads only the label and then “edit text” with no required signal, the field is failing.

Step 4: Color-only check. Switch your display to grayscale. If the only required-field indicator disappears or becomes indistinguishable, you are also failing WCAG 1.4.1 (Use of Color) in addition to 3.3.2.

Step 5: Automated scan. Run your forms through a free website accessibility checker to surface missing aria-required attributes, unlabeled inputs, and unassociated instructions automatically. Automated scanning catches the attribute-level failures quickly. Manual testing catches the judgment-level failures the scanner cannot evaluate.

---

Required Fields and Form Instructions Checklist

Use this as a quick audit reference or share it with your development team before a form goes live.

• Every required field has “required” or “(required)” in its visible label, OR a form-level note above the form clearly explains which fields are mandatory before any inputs appear.
• Every mandatory input has either the HTML required attribute or aria-required="true" present in the source. A CSS class or a visual asterisk alone does not count.
• If asterisks are used, a plain-text explanation appears before the first input in the form. Do not assume universal knowledge of the convention.
• CSS-generated asterisks (::before pseudo-elements) are not the sole required indicator. They do not exist in the accessibility tree and are invisible to screen readers.
• The required attribute and aria-required="true" are not used simultaneously on the same element. That combination causes double-announcement on most modern screen readers.
• All format instructions (date formats, password rules, phone number conventions) appear in the HTML before the relevant input field, not in tooltips, not below the field, and not only in error messages.
• In forms with a mix of required and optional fields, either the required fields are individually labeled or the optional fields are individually labeled. Do not leave it to assumption.
• Error messages after a failed submission restate which field is required and what input format is expected, not just “please fix the errors above.”

---

If you have worked through this list and identified potential failures in your own forms, run a free website accessibility checker to surface missing required-field attributes, unlabeled inputs, and unassociated instructions across your site before doing manual testing.