Jetpack Subscribe form and popup accessibility.

[bacoords]

During an accessibility audit on a website recently, we came up with a few issues related to the Jetpack subscribe form and subscriber popup. Some of the color contrast issues were fixable with CSS and short of adding more color options to the blocks, I'm not sure they're as fixable.

This is a high level summary, and I couldn't find existing issues, so just wanted to get the feedback documented for you:

Global popup modal issues (scroll‑triggered Jetpack subscribe)

• The popup is rendered as a plain <div> instead of a semantic <dialog> (or an element with role="dialog"), and:
  • It does not receive keyboard focus when it opens. Focus remains on the underlying page content.
  • Keyboard users must tab through all page content to eventually reach the popup controls.
  • Focus is not trapped inside the popup; users can continue tabbing to content “behind” the popup.
  • Escape key behavior is not managed: closing and returning focus to the point of origin is not handled.
• The dialog is not properly named or labeled:
  • No accessible name using aria-label or aria-labelledby (e.g., tied to the popup heading).
• Likely WCAG impact:
  • 2.1.1 Keyboard
  • 2.4.3 Focus Order
  • 2.4.7 Focus Visible
  • 3.2.2 On Input (if scroll‑triggered/auto popup is considered an unexpected change of context)
  • 4.1.2 Name, Role, Value

Expected behavior:

• Use a native <dialog> element where possible, or an element with role="dialog" plus:
  • An accessible name (aria‑label / aria‑labelledby).
  • aria-modal="true".
  • On open: move focus into the dialog (typically the heading or first control).
  • Trap focus until the dialog is dismissed.
  • On close: restore focus to a logical point (usually the control/position that triggered the popup or where the user was in the reading order).

Logged‑in email field behavior in header subscribe form

• When a user is logged in, the email input in the subscription form:
  • Is disabled but still visible with a prefilled value.
  • Sets the opacity to 0.5 but then overrides theme colors via color: currentColor, which inherits the site’s light text color on a dark background. In some contexts this resulted in:
    • Poor color contrast.
    • In one case, the text being effectively unreadable against the background.
• Because the field is disabled:
  • Keyboard focus skips the input entirely and lands directly on the “Subscribe” button.
  • The button has no indication of which email address will be subscribed, so the user has no assurance what will actually be submitted.
• Placeholder + label:
  • There is a visually hidden label and also placeholder text that repeats the same phrase, which can result in redundant announcements for screen reader users.

Concerns / WCAG:

• 1.4.3 Contrast (Minimum) / 1.4.11 Non‑text Contrast (for disabled state styling).
• 3.3.2 Labels or Instructions (user cannot easily tell what email will be submitted).
• Potential confusion for AT users due to redundant label + placeholder.

Suggested improvements:

• Avoid disabling the email field entirely for logged‑in users:
  • Pre‑fill it with the logged‑in email but leave it editable, so users can change it if they want a different subscription address.
• If it must remain disabled:
  • Ensure sufficient color contrast for the disabled state.
  • Announce the email being used from the Subscribe button (e.g., via aria-label="Subscribe [email@example.com]" or an adjacent, programmatically associated description).
• Avoid duplicating the same text in both label and placeholder; use placeholder for brief guidance, not for labeling.