Your email field loses its label when you type. Here is the HTML fix.

Patch — Sat, 26 Sep 2026 04:31:41 +0000

Written with AI assistance. The example was tested in Chromium as described below.

Your form says "Email address" until someone starts typing. Then the words disappear. If those words are a placeholder, add a visible label rather than trying to keep the placeholder on screen.

This is the starting point:

<input type="email" placeholder="Email address">

A placeholder can show an example. It should not be the only visible instruction. Some browser and assistive technology combinations may use it as a fallback name, but that does not make it a persistent label.

Here is the replacement:

<label for="email">Email address</label>
<input
  id="email"
  name="email"
  type="email"
  autocomplete="email"
  placeholder="you@example.com"
  aria-describedby="email-help"
>
<p id="email-help">We will send your receipt here.</p>

The label's for matches the input's id. That connects the two. Clicking the label focuses the field. The visible label stays after you type.

The name is the key used when a form submits the value. It does not create a visible label. The autocomplete value tells the browser what kind of saved information belongs here. The help paragraph is connected by aria-describedby; it is extra context, not the field's name.

You can remove the placeholder entirely. The label still works. If you repeat this field on the same page, give each input a unique id and update its label's for and any description references.

Check the change

I loaded that replacement in Chromium and checked three things:

Clicking "Email address" made the input the active element.
The input's labels.length was 1.
A role query found the textbox by the exact accessible name "Email address". It still did after entering a sample address.

You can repeat the first check by clicking the label and typing. The text should go into its field. Then tab through your real form and confirm that you can see where focus is.

This test does not certify a form as accessible. It does not test a screen reader, error messages, contrast, server validation or submission. Those need separate checks. This change fixes one specific problem: the field no longer loses its visible label when someone types.

A clean HTML checklist is not a launch certificate

Patch — Wed, 23 Sep 2026 06:36:28 +0000

AI assistance was used to write this article.

This is a practical note from Patch about the limitations of our free checker, not an accessibility certification.

A checklist is useful when its claims are smaller than its evidence. Paste a page's source into a static HTML checker and it can notice an empty title or repeated IDs. It cannot tell you that a payment button works, that a menu can be used with a keyboard, or that a customer understands the offer.

Here are three distinctions worth keeping in a launch review.

1. An absent attribute is not an evaluation of its content

<img src="workshop.jpg" alt="image">

This has an alt attribute. That doesn't mean its description is useful. Conversely, alt="" can be correct for a decorative image. A useful static finding is “this image has no alt attribute,” followed by a request to consider its purpose. “Your images are accessible” is not supported by the same check.

2. A suspicious link is not necessarily a broken link

<a href="#">Open details</a>

This deserves inspection. It may be unfinished navigation, or a script may handle it. The next step is to check what it does and whether the chosen element fits that action. A static checker shouldn't pretend it has activated the control or tested its destination.

A live request has its own uncertainty: a bot-blocking response is not proof that the link fails for a visitor. Record the observation, then reproduce it before calling it a defect.

3. Recognizing a label is not testing the whole experience

<label for="email">Email address</label>
<input id="email" type="email" autocomplete="email">

This gives a simple form field a visible label with an explicit association. It doesn't prove that validation errors are announced, focus remains usable, or submission succeeds. Those require interaction. An approximate name check must also admit that it doesn't implement the full accessible-name algorithm.

A useful report separates observation from inference

For each finding, record the page, the check performed, what you actually observed, the expected behavior, and a practical next step. Say what wasn't tested. Don't turn a count of warnings into a percentage of “readiness.”

I built Patch's free browser-only checker for that first, deliberately limited pass: https://patchlaunch.com/. Pasted HTML stays in the browser. You can also inspect its small JavaScript file at /check.js. A clean result means only that those static checks raised no flags.