Accessibility review: six fictional snippets (WCAG 2.2 AA)

Scope and assumptions: I reviewed only the markup and descriptions you gave me. The target is WCAG 2.2 AA. I assumed the form and modal belong to a key flow such as sign-up or settings. This is an engineering review, not a compliance statement.

Findings

A1. <div class="btn" onclick="save()">Save</div>: Blocker

• WCAG: 2.1.1 Keyboard, 4.1.2 Name, Role, Value. 2.4.7 Focus Visible is also at risk.
• Problem: A div is not focusable and has no button role. Keyboard and switch users can't reach it or activate it. Screen readers announce it as plain text.
• Affects: Keyboard, screen reader, voice control and switch users.
• Fix:

  <button type="button" class="btn" id="save">Save</button>
  

  Attach the handler with addEventListener. Keep a visible :focus-visible style.
• Verify: Tab to it, then press Enter and Space. A screen reader should announce "Save, button".

A2. <input placeholder="Email"> with no label: Serious

• WCAG: 1.3.1 Info and Relationships, 3.3.2 Labels or Instructions, 4.1.2. Also 1.3.5 Identify Input Purpose, and 1.4.3 if the placeholder color is pale.
• Problem: The placeholder is not a reliable accessible name. It disappears on input, often has low contrast, and is not consistently exposed. Voice-control users can't target the field by name.
• Affects: Screen reader, voice control, cognitive and low-vision users.
• Fix:

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

• Verify: Clicking the label focuses the input. The accessibility tree shows the name "Email". The placeholder contrast needs measuring if you keep it.

A3. Modal div with no focus handling and no Escape: Blocker

• WCAG: 2.1.1 Keyboard, 2.4.3 Focus Order, 4.1.2. Possibly 2.1.2 No Keyboard Trap, because focus can wander behind the overlay. 1.3.1 also applies if there is no dialog semantics.
• Problem: Focus stays on the trigger, so keyboard users tab through the page behind the modal. Screen readers don't know a dialog opened. There is no keyboard way to close it.
• Affects: Keyboard, screen reader and screen magnifier users.
• Fix:
  • Prefer the native element: <dialog> opened with showModal(). It handles the focus trap, inert background and Escape.
  • If you use a custom div, add role="dialog" aria-modal="true" aria-labelledby="dlg-title".
  • Move focus into the dialog on open, and keep it inside while open.
  • Close on Escape.
  • Make the background inert.
  • Return focus to the trigger on close.
  • Give the dialog a visible, labeled close button.
• Verify: Tab and Shift+Tab never leave the dialog. Escape closes it and focus returns to the trigger. A screen reader announces the dialog name on open.

A4. <button><svg>…</svg></button>: Serious

• WCAG: 1.1.1 Non-text Content, 4.1.2. Also 2.5.3 Label in Name if there is visible text, and 1.4.11 Non-text Contrast for the icon.
• Problem: The button has no accessible name. A screen reader says only "button". Voice control can't target it.
• Affects: Screen reader and voice control users.
• Fix:

  <button type="button" aria-label="Close">
    <svg aria-hidden="true" focusable="false">…</svg>
  </button>
  

  Visible text is better if there is room. If you add a tooltip, it must meet 1.4.13.
• Verify: The accessibility tree shows a name that describes the action. The icon has at least 3:1 contrast against its background. Check the target is at least 24×24 CSS px (2.5.8).

A5. Red "Invalid" text as the only error cue: Serious

• WCAG: 1.4.1 Use of Color, 3.3.1 Error Identification, 3.3.3 Error Suggestion, 4.1.3 Status Messages, 1.3.1. Also 1.4.3 for the red text.
• Problem: Users who are colorblind or low-vision, or who use a screen reader, may not notice the error or know which field it belongs to. "Invalid" doesn't say what to fix. Red on white often fails 4.5:1 depending on the shade, and I can't tell from the description.
• Affects: Colorblind, low-vision, screen reader and cognitive users.
• Fix:

  <input id="email" aria-invalid="true" aria-describedby="email-err">
  <p id="email-err"><svg aria-hidden="true">…</svg> Enter an email like [email protected]</p>
  

  • Add an icon and a specific message.
  • Give the field a non-color cue such as a thicker border.
  • Announce the error through a live region or by moving focus to an error summary on submit.
• Verify: View it in grayscale. A screen reader reads the error when the field is focused. Measure the text contrast.

A6. 80px sticky header on pages with long forms: Serious

• WCAG: 2.4.11 Focus Not Obscured (Minimum), new in 2.2. Also 1.4.10 Reflow and 1.4.4 Resize Text, because 80px of fixed height takes a large share of a short or zoomed viewport.
• Problem: When tabbing down a long form, focused fields can scroll under the header and be completely hidden. At 400% zoom the header may leave almost no room for content.
• Affects: Keyboard users, low-vision users who zoom, and mobile landscape users.
• Fix:

  html { scroll-padding-top: 96px; }  /* header height plus margin */
  :target, :focus { scroll-margin-top: 96px; }
  

  Also consider a shorter header, or making it non-sticky at small heights or high zoom:

  @media (max-height: 500px) { .site-header { position: static; } }
  

• Verify: Tab through the whole form and confirm no focused element is fully hidden. Test at 200% and 400% zoom (320px width).

What I could not check

• I didn't run any code, scanner, browser or screen reader. Everything above is from your description.
• I couldn't measure color contrast: the actual colors weren't given. This covers the red error text, the placeholder, icons and focus indicators.
• I couldn't judge the focus indicator, as no CSS was shown. I also couldn't check target sizes (2.5.8), zoom, reflow or text spacing.
• I haven't seen the rest of the page, so I couldn't assess headings, landmarks, lang, the page title, a skip link, form grouping or autocomplete beyond the email field.
• I can't tell whether the sticky header actually hides focus. That depends on scroll behavior and needs a live keyboard test.
• Whether the labels, icon names and error messages are meaningful needs human judgment.
• I didn't see the real save() flow, so I couldn't check status messages (4.1.3) or error prevention (3.3.4).

Top three fixes first

1. Replace the div button with a real <button> (A1).
2. Fix the modal: use <dialog> or add focus management, Escape, inert and focus return (A3).
3. Add real labels and accessible errors to the form: label the input, give the icon button a name, and make errors text and programmatically tied to the field (A2, A4, A5).

What was good

• You used a real <button> for the icon-only control, which is the right element. It only needs a name.
• Visible "Save" text exists on the clickable div, so the label is already there for the real button.