d5DetectabilityOperational debt — how invisible misuse is to your safety net
Closest to 'specialist tool catches it' (d5). The detection_hints.tools list includes axe, lighthouse, and wave — all specialist accessibility and audit tools. Missing labels, wrong input types, and accessibility violations are not caught by a compiler or default linter, but are reliably flagged by these specialist tools when run deliberately.
e3EffortRemediation debt — work required to fix once spotted
Closest to 'simple parameterised fix' (e3). The quick_fix is to swap custom JS widgets or mis-typed inputs for native HTML elements. This is a small, localised refactor — replacing a div-based dropdown with a select, or adding a label — confined to individual components rather than spanning the whole codebase.
b3BurdenStructural debt — long-term weight of choosing wrong
Closest to 'localised tax' (b3). The applies_to scope is web contexts only, and the burden is per-form or per-component. Each form that uses incorrect structure imposes a tax on that component (extra JS to recreate accessibility, maintenance of custom widgets), but it doesn't structurally constrain unrelated parts of the codebase.
t7TrapCognitive debt — how counter-intuitive correct behaviour is
Closest to 'serious trap' (t7). The misconception field explicitly states that HTML5 form validation is believed to remove the need for server-side validation — a dangerous belief that contradicts security fundamentals. Client-side validation can be trivially bypassed via raw HTTP requests or disabling JS, but many competent developers coming from a frontend-first background assume the browser enforces the constraint end-to-end. This contradicts how similar concepts (e.g. required attributes) appear to work at first glance.
About DEBT scoring →
scored by claude-sonnet-4-6 · 2026-05-08 · reviewed by human
Also Known As
HTML form elementsform validation HTMLinput types
TL;DR
Native HTML form validation, input types, and accessibility patterns — using browser built-ins before reaching for JavaScript.
Explanation
HTML5 input types give free validation and mobile-optimised keyboards: email, tel, number, date, url, color. Constraint validation attributes: required, minlength, maxlength, pattern (regex), min, max, step. The browser validates on submit and shows native UI unless novalidate is added. For custom validation, use the Constraint Validation API: input.setCustomValidity('message'). Accessibility: always associate <label> with input via for/id or wrapping; use aria-describedby for hint text; aria-invalid='true' on failed fields; aria-live='polite' on error containers. Never rely solely on placeholder — it disappears on focus and has poor contrast. Server-side validation (PHP) is mandatory regardless of client validation — never trust the client.
Common Misconception
✗ HTML5 form validation removes the need for server-side validation. HTML5 validation improves UX but can be bypassed by disabling JavaScript or crafting raw HTTP requests. Server-side validation is always required for security; client-side validation is always optional for usability.
Why It Matters
Proper HTML form structure (labels, fieldsets, validation attributes) provides built-in accessibility and browser validation — missing these requires JavaScript to recreate what the browser offers for free.
Common Mistakes
Input without a label — placeholder is not a substitute; it disappears when the user types.
Not using the correct input type (email, tel, number) — loses browser-native validation and mobile keyboard.
Form submission via JavaScript without a fallback for disabled JS users.
Not using autocomplete attributes — browsers cannot autofill correctly without them.
Code Examples
✗ Vulnerable
<input type="text" placeholder="Enter your email">
<input type="text" id="pass">
💬 Input validation is commonly applied in HTML form contexts — this is loose contextual co-occurrence, not a hard dependency or active use. often_seen_in is the right weak verb here, better than the original 'leverages' since input validation doesn't build on HTML forms as a mechanism.
🤝 Adopt this term£79/year · your link shown here
Added15 Mar 2026
Edited22 Mar 2026
Views126
Curated in Warsaw under one editorial standard. 1,547 terms, single voice. About this reference →
FrontendfrontendThe frontend is the part of a website or application that users see and interact with directly in their browser—buttons, text, images, and forms.
Every user interaction starts at the frontend. Understanding this layer helps you build interfaces people actually want to use and debug issues that only appear in the browser.
💡 If you can see it or click it, it's frontend; if it stores data or makes decisions you shouldn't expose, that belongs on the backend.
HTMLfrontendThe markup language that defines the structure and meaning of web content — elements like <h1>, <p>, and <form> wrapped in angle-bracket tags.
HTML is the skeleton every other web technology hangs on. Using the right element gives you keyboard support, screen-reader announcements, and SEO for free; using <div> for everything means rebuilding all of that by hand in JavaScript.
💡 Before reaching for a <div>, ask: is there an element whose NAME says what this is? There usually is.
InputgeneralInput is any data that comes into your program from the outside world—typed text, clicked buttons, uploaded files, or information sent from other systems.
Understanding input is essential because most bugs and security vulnerabilities come from unexpected input. Every skill level requires thinking carefully about what data is coming in and whether it's safe to use.
💡 Treat every piece of input as potentially wrong, empty, or malicious until your code has explicitly checked it.
ValidationgeneralValidation is checking that data meets specific rules before your program uses it—like confirming an email has an @ symbol or a number falls within an expected range.
Every application accepts user input, and users make mistakes—or try to exploit your system. Validation is your first defense against corrupted data and security vulnerabilities at any scale.
💡 Always validate on the server, even if you already validated in the browser.
Use native form elements (input, select, textarea) over custom JS widgets where possible — they provide built-in accessibility, keyboard handling, and mobile keyboard types free
Custom dropdown built with div/span instead of select; custom checkbox built with div instead of input[type=checkbox]; form submittable without server-side validation