Besökarens internetanslutning bryts medan ditt formulär laddas. Ett tillägg i Chrome förstör ditt JavaScript. En äldre webbläsare stöder inte det JavaScript du använder. Besökarens skärmläsare kan inte navigera i ditt formulär eftersom etiketterna är dolda med CSS.
Formulär är kritiska vägar. Användare måste kunna skicka in dem. Formuläret får inte bara gå sönder. Progressiv förbättring är principen att bygga formulär som fungerar överallt och sedan lägga till förbättringar för webbläsare som klarar dem.
Den här artikeln går igenom hur du bygger formulär som försämras på ett snyggt sätt, fungerar utan JavaScript och förblir tillgängliga för alla.
Vad är progressiv förbättring?
Progressiv förbättring innebär att du börjar med ett enkelt, fungerande formulär som fungerar i de äldsta webbläsarna och utan JavaScript och sedan lägger förbättringar ovanpå för moderna webbläsare. Lager 1 (HTML) ger ett enkelt formulär med inmatningsfält, etiketter och en skicka-knapp som inte kräver JavaScript och fungerar överallt. Lager 2 (CSS) formger formuläret med färger, avstånd och layout, så att formuläret fortfarande fungerar om CSS inte laddas, även om det då bara ser illa ut. Lager 3 (JavaScript) lägger till validering i realtid, mjuka animationer och inskick via AJAX, så att formuläret fortfarande fungerar om JavaScript fallerar och då bara skickas på traditionellt sätt. Om något lager fallerar får användaren ändå ett fungerande formulär. Det är robusthet.
Grunden: HTML som fungerar
Börja med semantisk HTML med rätt etiketter, fieldset och legend-element. Ett grundformulär ser ut så här: <form action="/submit" method="POST"> <label for="email">E-post</label> <input type="email" id="email" name="email" required> <label for="message">Meddelande</label> <textarea id="message" name="message" required></textarea> <button type="submit">Skicka</button> </form>. Det här formuläret fungerar utan JavaScript, utan CSS, i gamla webbläsare, med skärmläsare och med tangentbordsnavigering. Det är din grund. Ta aldrig bort element från DOM och ersätt dem med element som JavaScript renderar, för om JavaScript fallerar går formuläret sönder. Behåll den semantiska HTML-koden.
Snygg försämring med CSS
Lägg CSS-förbättringar ovanpå HTML. Formge formuläret snyggt. Men om CSS fallerar ska formuläret ändå fungera.
Dölj inte etiketter med CSS och lita på platshållare, eftersom CSS ibland inte laddas och skärmläsare behöver etiketter i HTML. Använd inte CSS för att dölja markeringar för obligatoriska fält, för om din egen "obligatorisk-stjärna" inte laddas kan användare inte se vilka fält som är obligatoriska. Använd HTML-attributet required i stället. Undvik att dölja etiketten visuellt och visa en platshållare i stället med label { display: none; } och input::placeholder { content: 'E-post'; }. Behåll i stället etiketten i HTML och formge den som du vill med label { font-weight: bold; color: #333; }.
JavaScript-förbättringar som försämras snyggt
Lägg till förbättringar med JavaScript, men bara om formuläret redan fungerar. Använd funktionsdetektering för att kontrollera om webbläsaren stöder det du behöver med if (window._blocked_) { // Använd _blocked_ för inskick via AJAX } else { // Formuläret skickas traditionellt }. Anta inte att funktioner finns. Anta att de kanske inte gör det. Detektera först.
Validering i realtid med reservlösning
Använd HTML-validering som grund med <input type="email" required> så att webbläsaren validerar vid inskick. Lägg sedan till JavaScript-validering som körs i realtid med input.addEventListener('blur', () => { if (!isValid(input.value)) { input.classList.add('invalid'); showError(input, 'Ogiltig e-postadress'); } });. Den visar fel medan användaren skriver, och om JavaScript fallerar fungerar webbläsarens inbyggda validering ändå. Användaren får fördelen av återkoppling i realtid, och om JavaScript fallerar får hen återkoppling från webbläsaren vid inskick. Valideringen sker i båda fallen.
Inskick via AJAX med traditionell reservlösning
Bygg ett traditionellt formulär som skickas till servern, avbryt sedan inskicket och använd AJAX i stället med form.addEventListener('submit', async (e) => { e.preventDefault(); const response = await _blocked_('/submit', { method: 'POST', body: new FormData(form) }); if (response.ok) { showMessage('Klart'); } });. Om JavaScript fallerar körs aldrig preventDefault, formuläret skickas på traditionellt sätt och användaren får en sidomladdning i stället för en mjuk användarupplevelse. Men formuläret fungerar.
Tillgänglighet som progressiv förbättring
Tillgänglighet är ingen extra funktion. Det är grunden. Bygg tillgängliga formulär.
Etiketter måste kopplas till inmatningsfält med attributen for och id. Inte data-attribut, inte aria-labels som kan missas. Riktiga etiketter.
<label for="email">E-post</label>
<input id="email">
Använd semantiska HTML-element (fieldset, legend, button, input). Inte div-element som formgetts för att se ut som knappar.
Tangentbordsnavigering måste fungera. Tabba genom alla fält. Skift+Tab för att gå tillbaka. Enter för att skicka in. Mellanslag för att växla kryssrutor. Det fungerar som standard med semantisk HTML. Förstör det inte med JavaScript.
När grunderna fungerar kan du lägga till ARIA-etiketter för skärmläsare. Lägg till fokusmarkeringar för tangentbordsanvändare. Men det här är förbättringar ovanpå tillgänglig HTML.
Testa robusthet
Testa ditt formulär med JavaScript avstängt. Stäng av JavaScript i webbläsaren och försök skicka in. Om formuläret går sönder är det inte robust.
Testa med långsamma nätverk. Strypa din anslutning till 2G. Om formuläret tar en evighet att ladda lämnar besökare med dålig anslutning sidan.
Testa med äldre webbläsare. Använd en tjänst för test i flera webbläsare för att testa i IE 11 (om du fortfarande behöver det). Se vilka funktioner som inte stöds.
Testa med skärmläsare. Använd en skärmläsare för Windows eller den inbyggda skärmläsaren på Mac. Lyssna på hur formuläret läses upp. Om det inte ger någon mening för en skärmläsare bör du åtgärda det.
Testa enbart med tangentbord. Använd inte mus. Kan du navigera i formuläret? Kan du skicka in det?
Funktionsdetektering, inte webbläsardetektering
Kontrollera inte specifika webbläsare. Kontrollera funktioner i stället för att använda webbläsardetektering som if (navigator.userAgent.includes('Chrome')) { /* använd _blocked_ */ }. Använd i stället funktionsdetektering som if (window._blocked_) { /* använd _blocked_ */ }. Funktionsdetektering är mer pålitlig eftersom en webbläsaruppdatering som lägger till stöd för _blocked_ fungerar med din kod, men webbläsardetektering gör det inte.
Så bygger WEMASY robusta formulär
WEMASY-formulär bygger på principerna för progressiv förbättring: de fungerar utan JavaScript, har etiketter och semantisk HTML på plats och har valfria förbättringar med JavaScript, så att äldre webbläsare får ett fungerande formulär och moderna webbläsare får mjuka interaktioner.
Se funktionerna för robusthet i din WEMASY-plan.