Proposal: add configurable strictness for placeholder-only labels

[TyrGo]

Summary
Introduce an optional strictness configuration that lets users treat placeholder-only inputs and textareas as accessibility violations, even though axe-core seems to me to permit them by default.

Motivation
Some consumers rely on stricter labeling rules. As per MDN:

**The aria-placeholder is used in addition to, not instead of, a label. They have different purposes and different functionality. A label explains what kind of information is expected. Placeholder text provides a hint about the expected value.

Warning: Using a placeholder instead of a visible label harms accessibility and usability for many users including older users and users with cognitive, mobility, fine motor skill and vision impairments. Labels are better: they are always visible and they provide for a larger hit region to focus on the control. Placeholders have several drawbacks: they disappear when the control has any value including just white space, they can confuse users into thinking the value is pre-filled, and the default color has insufficient contrast.**

Proposed changes

• Add a strictness?: StrictnessOptions property to AccentedOptions, starting with a placeholderLabelsAreInsufficient flag.
• In accented.ts, use reference-counted axe.configure calls so enabling the flag disables non-empty-placeholder, and returning to normal re-enables it when no strict instances remain.
• Extend validate-options.ts to guard the strictness object and the new boolean field.
• Export StrictnessOptions so TypeScript consumers see the shape and defaults.
• Update documentation (api.mdx), changelog, and playground/dev app examples to mention the option.
• Add Playwright coverage in main.spec.ts verifying both default and strict behavior.
• Include a README snippet showing how to enable the stricter mode.

Extensibility
Modeling strictness as an object means future toggles can be added without breaking existing callers.

I’m happy to implement this if you agree with the general direction.

[pomerantsev]

@TyrGo thanks for the detailed proposal, and for offering help with implementation!

I completely agree that using placeholders as labels is a poor practice for multiple reasons.

I don't think, however, that Accented itself should be opinionated on what "strict" may mean for accessibility — we already have axe-core with its groups of rules, and further upstream we have the standards with WCAG levels, etc. I don't want to further complicate things. Which is why I'm not sure that the proposed strictness option is the way to go. For placeholders specifically, the reason axe-core doesn't consider placeholder-only accessible names to be an issue is likely because in its algorithm it refers to the HTML Accessibility API Mappings spec. See dequelabs/axe-core#4795 for example.

With that said, I realize that Accented could allow its users to pass options to axe.configure, which would enable much more granular control over checks and rules, including the ability to encode the behavior that you described, among many others.

Any thoughts on this alternative direction? Would that be valuable for you?

If so, would you like to draft what such an API addition or change may look like? For example, here are the questions that we should likely answer:

• Should it be an additive or a breaking API change?
• What options should we allow passing to axe.configure? I haven't looked closely at axe.configure yet (it seems to go quite deep), so I'm not sure what makes sense for Accented.
• How do we ensure that new options don't clash with whatever users currently pass as axeOptions.rules?