A comment form is one of the few places on a page where a reader has to type, submit, and read back a result. That makes it a good test of whether your site actually works for people using a keyboard or a screen reader. If the form fails, you lose voices you never hear from, and you may fall short of the Web Content Accessibility Guidelines (WCAG) that many organizations are expected to meet.
Here is a concrete checklist for the discussion section, grouped by the WCAG principles: perceivable, operable, understandable, and robust.
Labels and structure
Every input needs a real label tied to it with a matching id, not just placeholder text. Placeholders disappear when someone starts typing and are often too low-contrast to read. A visible label that stays put is the safest choice.
- Name and email fields carry explicit labels, so a screen reader announces what each field is for.
- The comment textarea has its own label, and any character count or formatting note is linked with aria-describedby so it is read out with the field.
- Headings follow a logical order. The discussion section usually sits under an h2, and individual comment metadata does not hijack the heading outline.
Keyboard operation
Try your comment section with the mouse unplugged. You should be able to reach the text field, reply buttons, reaction buttons, and submit control using Tab, and activate them with Enter or Space. Nothing should trap focus, and nothing that a mouse can do should be off-limits to the keyboard.
Reactions are a common trouble spot. A like or heart button that only responds to a click leaves keyboard users out. Buttons should be real button elements with an accessible name such as "Like this comment" rather than an unlabeled icon.
Threaded replies raise focus questions too. When someone opens a reply box, focus should move into it, and after posting, focus should land somewhere sensible so the person is not dropped back at the top of the page with no idea what happened.
Contrast, motion and text size
WCAG asks for a contrast ratio of at least 4.5:1 for normal text. Timestamps, author names and helper text are the usual offenders because they are often styled in light gray. Check them against the background, in both light and dark themes if you offer both.
Let text reflow when someone zooms to 200 percent. Fixed-height comment boxes that clip content, or layouts that require horizontal scrolling when enlarged, both fail here. Avoid animations that cannot be paused, and respect the reduced-motion preference for any transitions.
Clear errors and feedback
When a submission fails validation, say what went wrong in text, near the field, not with color alone. "Email is not valid" beats a red border that a color-blind reader cannot perceive. When a comment posts successfully or enters a moderation queue, announce that in a way assistive technology can catch, using a live region so the update is spoken without a page reload.
A good rule: if a sighted mouse user gets confirmation, a screen-reader user should get the same confirmation, at the same moment, in words.
Robust markup
Use native HTML elements before reaching for ARIA. A button element is understood everywhere; a div dressed up with role attributes and click handlers is fragile. Where ARIA is genuinely needed, such as marking the comment list as a live region or grouping a reply thread, apply it sparingly and test it, because wrong ARIA is worse than none.
How Gabden approaches this
Gabden's widget is built with labeled fields, real buttons, a sensible focus order, and status messages that assistive technology can read. Because the embed keys each thread to the page's canonical URL and renders standard form controls, it inherits your page's language and structure rather than fighting it. The light and dark themes are designed with contrast in mind, and you can adjust presets to fit your own palette.
Accessibility is not a one-time audit. Re-test after theme changes and keep the checklist above handy. If you want to see the markup in place, you can create a free site and drop the embed onto a test page, or read the setup notes in the docs.
Join the discussion