Every creator landing page I scan has the same six issues sitting on the signup form. Not five. Not seven. Six, almost every single time. The platforms differ. The themes differ. The newsletter topics range from indie video games to enterprise data engineering to homesteading. The signup form, the part that is supposed to convert a casual reader into a subscriber, fails the same way over and over.

I scanned 14 creator newsletter pages last week. Four were on Kit (formerly ConvertKit), four on Beehiiv, three on Substack, and three on Ghost. I pulled the URLs from the recent issues of two creator-economy roundups so the sample skews toward writers who have at least crossed the “I take this seriously” threshold. I ran each page through axe-core 4.11 against WCAG 2.1 AA and 2.2 AA, then walked through every page with VoiceOver on macOS and NVDA on Windows.

Thirteen of the fourteen pages had at least four of the six issues below. Three pages had all six.

Here is what keeps coming up, what specifically breaks, and what a creator without a developer can change today.

1. Placeholder-only labels on the email field

The email input on most creator landing pages has a placeholder that says “Your email” or “Enter email address” and nothing else. No <label> element. No aria-label. No visible text above or beside the input that says what to type.

This is the single most common signup-form failure I see, and it appears on the default templates for Kit, Beehiiv, and Substack. The Ghost themes I scanned were better — Casper and Source both render a real label by default — but the moment a creator picks a custom theme from the marketplace, the label tends to disappear again.

Why it matters: the moment a visitor starts typing, the placeholder vanishes. A subscriber who tabbed away to check their email address in another tab returns to a blank field with no name. A subscriber using screen magnification cannot scroll back up to recover the prompt because there is no prompt to recover. A screen reader user gets inconsistent announcements depending on the browser-and-screen-reader pair; the WAI-ARIA spec does not require any browser to expose placeholder as the accessible name, and several do not.

The fix on Kit and Beehiiv is a toggle in the form editor labeled “Show field label” — turn it on. On Substack, where you cannot edit the embedded form, prefer the standalone subscribe page (yourname.substack.com/subscribe) over the in-line embed and add a sentence above it that names what you are asking for. On Ghost, edit the theme’s signup partial to wrap the input in a <label for="email">Email address</label> if your theme strips it out.

2. The submit button just says “Subscribe”

Every form on every platform has a submit button. On 11 of the 14 pages I scanned, the button text was a single word: “Subscribe.” On two it was “Sign up.” On one it was “Join.”

By itself this is fine for a sighted user reading the form in context. The headline above says “Join my Tuesday newsletter on indie game design” and the button below says “Subscribe” — the brain stitches it together.

The problem is that screen-reader users frequently navigate by listing all the buttons or all the form controls on a page, out of context. When NVDA’s elements list shows fifteen buttons all named “Subscribe” across the various opt-ins on a page, or “Sign up” on a long sales page that includes both the newsletter and a paid course, the user has no way to tell them apart.

The fix is to make the button text more specific or to add an aria-label that disambiguates it. “Subscribe to the Tuesday newsletter” is clearer than “Subscribe.” If the visible text needs to stay short for design reasons, set aria-label="Subscribe to the Tuesday newsletter on indie game design" on the button so the accessible name is unambiguous out of context. On Kit and Beehiiv, the button text field accepts longer copy than the default suggests; you do not have to keep it at one word.

3. No visible focus ring on the submit button

This one is hidden in plain sight. On 9 of 14 pages, the submit button had outline: none in the CSS reset and no replacement focus style. A keyboard-only visitor pressing Tab to reach the form sees the focus arrive at the email field (usually with a default browser ring), then disappear when focus moves to the button.

A keyboard user with a motor disability tabbing through the page now has no idea where they are. They might press Enter and submit a half-empty form. They might tab past the button entirely without realizing they were ever on it. WCAG 2.4.7 (Focus Visible) at Level AA explicitly requires that the keyboard focus indicator be visible.

The fix is a single CSS rule. On Kit and Beehiiv, paste it into the Custom CSS panel:

button:focus-visible,
input[type="submit"]:focus-visible {
  outline: 3px solid #0a4d8c;
  outline-offset: 2px;
}

Pick a color that has at least 3:1 contrast against both the button background and the page background. Test with WebAIM’s contrast checker. On Ghost, add the same CSS to your theme’s screen.css or the asset that loads global styles. On Substack you cannot inject CSS into the embed, but the standalone subscribe page (which I would link to anyway) shows the browser default focus ring, which is enough.

4. The “I agree to receive emails” checkbox is unreachable by keyboard

Several Kit and Beehiiv pages I scanned had a GDPR consent checkbox below the email field. Three of those pages had the checkbox styled as a custom box (a span with a CSS background image standing in for the native input), with the underlying <input type="checkbox"> either hidden via display: none or sitting outside the tab order entirely.

When the native checkbox is display: none, the browser does not give it a tab stop, does not focus it, and does not let a keyboard user toggle it. The visible custom box can be clicked with a mouse, but a keyboard-only visitor reaches the email field, tabs once more, and lands on the submit button — the checkbox is invisible to them.

This is a regulatory-and-accessibility double failure. GDPR requires affirmative consent, which a user who cannot interact with the checkbox cannot provide. WCAG 2.1.1 (Keyboard) requires every functionality of a page to be operable through a keyboard interface.

The fix is to use the native checkbox with CSS that styles it visually rather than hiding it. The simplest approach is to keep the native input visible at all times and style its border, background, and check mark with accent-color (supported in all modern browsers). On Kit, the form template engine exposes the checkbox class names; you can override them in Custom CSS without removing the input. On Beehiiv, the consent checkbox in the embedded form is already a real input; only third-party page builders that wrap the form tend to break it.

If you are not a developer and your platform’s consent checkbox looks fine to you, ask one person to try subscribing using only the keyboard (no mouse, no trackpad). If they cannot reach the checkbox with Tab, you have this issue.

5. The “Thanks for subscribing” confirmation is silent for screen readers

When a visitor submits the form, the page either redirects to a thank-you page or shows an inline “Thanks for subscribing — please check your email” message that replaces the form. On 12 of the 14 pages I scanned, the inline confirmation appeared with no announcement to the screen reader. The form quietly disappeared, the confirmation text quietly appeared, and a screen reader user heard nothing.

To a sighted user this is fine because the visual change is obvious. To a blind subscriber the page just goes silent. They do not know if the form submitted. They might press Enter again. They might walk away assuming the site is broken.

The fix is to wrap the confirmation message in a live region so the screen reader announces it on appearance:

<div role="status" aria-live="polite">
  Thanks for subscribing! Please check your email to confirm.
</div>

role="status" with aria-live="polite" is the right combination for a non-urgent status message. The screen reader will speak the message at the next pause without interrupting whatever it is currently announcing.

On Kit you can edit the success message HTML in the form designer and add the role and aria-live attributes; the platform passes them through. Beehiiv and Substack do not expose this, which is worth filing as a feature request. On Ghost, edit the form partial in your theme.

6. The hero photo behind the headline kills contrast

This is a landing-page issue more than a signup-form one, but it always lives directly above the form and it always affects whether someone can read the offer at all. Most creator landing pages I scanned use a hero photograph as the background, with the newsletter headline laid over it in white or near-white text.

Without an explicit overlay, the contrast ratio shifts depending on which part of the photo sits behind a given letter. The “T” in “Tuesday” might land on a dark patch and pass WCAG 1.4.3 with 8:1; the “y” four characters later might land on a sky and fail at 1.6:1. Across the headline, the average contrast is somewhere below 4.5:1 and the worst characters are illegible.

The fix is a dark overlay between the photo and the text. In CSS:

.hero {
  background:
    linear-gradient(rgba(0, 0, 0, 0.5), rgba(0, 0, 0, 0.5)),
    url("/hero.jpg");
}

Most platform editors expose this as a slider labeled “Overlay” with an opacity value. Set it to 40-60% for white text on a busy photo. Take a screenshot of the published page and run it through Stark’s image contrast checker (or just zoom in on the lightest pixels behind your headline) to confirm 4.5:1 or better across the entire headline.

If the photo is busy enough that no overlay value works, swap to a flat-color hero background and put the photo elsewhere on the page. A landing page that converts is one a low-vision visitor in sunlight on their phone can actually read.

What this means for you

If you publish a newsletter and you have a public signup landing page, you almost certainly have at least four of these six issues right now. None of them are difficult to fix. None of them require a developer. All six show up in scanner output (axe-core, WAVE, Lighthouse) within seconds of running them on your URL, so you do not need to take anyone’s word for whether your page passes.

The issues compound. A landing page with placeholder-only labels, a generic “Subscribe” button, no focus ring, a broken consent checkbox, a silent confirmation, and a contrast-failing hero is not slightly inaccessible. It is a page that several large categories of visitors cannot complete without giving up. Some of those visitors are exactly the kind of subscriber a creator wants — patient enough to read a long newsletter, willing to hit reply, the highest-quality cohort.

Fix the labels first (Issue 1), then the focus ring (Issue 3), then the confirmation announcement (Issue 5). Those three changes alone will move the page from “pages a screen-reader user gives up on” to “pages a screen-reader user can subscribe to without a fight.” The other three are quick follow-ups for the next time you touch the page.

Related Reading

• Accessible Forms Guide: 12 Patterns That Actually Work
• Accessible Email Marketing: A Practical Guide
• Color Contrast: Why Your Brand Colors Probably Fail (and How to Fix Them)

---

We’re building a simple accessibility checker for non-developers — no DevTools, no jargon. Join our waitlist to get early access.