a11y

[bitifet]

We Should Make Accessibility More Accessible

Let’s use this thread to brainstorm and organize ideas about accessibility in the context of SmarkForm.

Accessibility can feel distant—especially when we don’t directly experience the barriers. Under time pressure, it’s easy for a11y to slide into the “later” pile. Most tools and frameworks add features but rarely lower the friction of doing the inclusive thing.

SmarkForm is not an accessibility framework and isn’t trying to be a definitive solution. Its goal isn’t to “handle” accessibility. But if it can quietly remove small points of friction—like linking things that function as labels, or letting a heading legitimately stand in for a label-like element when HTML doesn’t allow it—that’s a meaningful win. Native semantics first, subtle assists second, no lock‑in.

This thread is a lightweight space to:

• Capture motivations and principles (not deep implementation detail).
• Jot down ideas, links, and patterns worth exploring later.
• Note where “a tiny assist” could help busy developers do the right thing with zero extra effort.
• Call out things SmarkForm should explicitly avoid (overreach, noisy ARIA, fragile magic).

You’re welcome to drop in:

• Friction points you’ve seen (or caused!) when trying to keep forms inclusive.
• Tiny automation ideas that stay out of the way.
• Examples of when “help” becomes harm.
• Good references that make invisible barriers more visible.

Even if this becomes mostly a personal notebook for a while, that’s fine—it still helps shape sensible defaults.

Goal in one line: make the accessible path feel like the obvious, nearly effortless path—without pretending SmarkForm is “the solution.”

Contributions of any size are appreciated. 👋