Använd Javascript för att öka tillgängligheten – inte tvärtom
Javascript ger ofta en god användbarhet, och kan bidra till ökad tillgänglighet och effektivitet. Men det finns användare som inte kan eller vill använda Javascript. Se därför till att det går att använda webbplatsens viktigaste funktioner även utan Javascript, och följ riktlinjer för tillgänglig Javascript.
Rekommendationer om JavascriptLänk hit
- Använd gärna Javascript, men se till att även de som inte använder Javascript kan använda de viktigaste funktionerna. Följ principen om progressiv förbättring, det vill säga bygg först all funktionalitet som vanlig html. Använd sedan Javascript som ett förhöjande tillägg.
- Se upp så att Javascript inte gör webbplatsen otillgänglig. Denna riktlinje ger flera råd som du bör tänka på om du använder Javascript.
- I undantagsfall kan faktorer utanför din kontroll göra att besökare måste använda Javascript. Upplys då användaren om att Javascript krävs för att använda tjänsten.
- Om vissa användare utestängs på grund av att de saknar Javascript kan ni eventuellt ha skyldighet att erbjuda fullgoda alternativ. Detta gäller särskilt myndigheter.
Använd gärna JavascriptLänk hit
Med hjälp av script kan bearbetningen av information på webben fördelas på ett effektivt sätt mellan webbläsare och webbserver. Tack vare script kan webbsidor göras snabbare och smidigare, till exempel med sökförslag (se R112. Ge ordförslag vid sökning och inmatning) eller genom att bara den information som visas för ögonblicket behöver laddas ner, istället för hela sidor. Script bidrar därför ofta till ökad tillgänglighet och användbarhet. Javascript är standardspråket för script som körs i webbläsaren och det finns ett stort utbud av färdig Javascriptkod som webbutvecklare kan använda som halvfabrikat. Detta sparar tid även vid utveckling.
Men alla besökare använder inte Javascript. Vissa äldre webbläsare och hjälpmedel saknar stöd för Javascript, och vissa användare och arbetsplatser väljer att stänga av eller blockera script. Anledningen kan vara till exempel integritets- eller säkerhetsskäl, för att slippa reklam eller för att man inte vill eller kan uppgradera sin utrustning.
Grundprincipen bör därför vara att tillämpa principen om ”progressiv förbättring”, vilket innebär att man bygger tjänster som i sina grundläggande delar fungerar utan Javascript och samtidigt ger mervärde för de användare som har stöd för script.
Det betyder inte att allt måste fungera likadant utan Javascript, men allt som finns och kan nås ska fungera. En besökare med fullt stöd för Javascript kanske får möjlighet att bläddra och klicka i en kalender vid inmatning av datum, medan en besökare utan Javascript får en textruta och information om önskat datumformat. (I html5 kan kalenderinmatning erbjudas utan Javascript, men inte i tidigare html-versioner.) Ett annat exempel: Utan Javascript kan en länk leda till att besökaren kommer till en ny sida med nytt innehåll, men med stöd för AJAX görs samma länk om så att innehållet infogas i befintlig sida.
En grundrekommendation är att undvika att använda script för funktioner som redan finns i webbläsare eller fungerar lika bra utan script. Navigationslänkar bör t.ex. vara just länkar, och inte andra sorters objekt med onclick-event.
I undantagsfall kan det finnas faktorer som står utanför er kontroll som gör att webbplatsen behöver ställa Javascript som ett krav. Till exempel har det funnits exempel på e-legitimationslösningar som kräver Javascript och som måste användas av vissa myndigheter. Ett annat exempel är när nödvändig funktionalitet av ekonomiska eller tekniska skäl endast går att realisera med Javascript (till exempel direktmanipulering av kartvyer) eller där säkerhetskrav gör det olämpligt att skicka information över nätet till servern. I sådana fall bör användare informeras om att Javascript krävs för att använda tjänsten. I vissa fall kan det innebära en skyldighet att erbjuda fullgoda alternativ, till exempel utgående från diskrimineringslagen.
Tänk på detta om ni använder scriptLänk hit
Gör det möjligt att använda de viktigaste funktionerna även utan tillgång till script. Om webbplatsen fungerar sämre utan script, informera om detta i anslutning till berörd funktionen eller under avdelningen ”Om webbplatsen”.
Om du använder script för visuella effekter som förmedlar information till användarna, tänk på att förmedla samma information till användare som inte kan se innehållet.
Undvik att göra funktioner som kräver en viss typ av inmatningsenhet. Ett exempel är funktioner som kräver att användaren med musen drar och släpper objekt. Funktioner ska utformas så att de fungerar att använda med flera typer av inmatningsenheter.
Förlita dig aldrig enbart på scriptbaserade valideringsfunktioner i formulär. Det måste gå att skicka in ett formulär utan script. Information som användare lämnar måste valideras på serversidan, inte minst av säkerhetsskäl.
Undvik webbläsarspecifik funktionalitet. Använd etablerade standarder som W3C:s dokumentobjektmodell (DOM). Ett sätt att undvika problem kan vara att använda något av de färdiga bibliotek som finns. Många av dessa är öppen källkod och är redan testade på ett stort antal webbläsare.
Gör det möjligt att skapa länkar till information på din webbplats. Om du använder script för att dynamiskt uppdatera sidan med information måste det vara möjligt att referera till den i andra sammanhang, exempelvis genom vanliga länkar. Observera att det går att med hjälp av script dynamiskt ändra på den adress som visas i adressfältet. Detta kan användas för att även efter interaktion göra det möjligt att använda adressfältets innehåll som referens.
Med detta arbetssätt kan Javascript göra mycket för att förbättra användarupplevelsen, utan att stänga användare ute i onödan.
Se upp så att Javascript inte gör webbplatsen otillgänglig
Beroende på hur Javascript används kan tillgängligheten på en webbplats påverkas. Många Javascriptbibliotek innehåller funktioner som gör det enkelt att skapa nya typer av gränssnittselement som skjutreglage eller ytor som uppdateras dynamiskt. Då dessa inte är en del av html-specifikationen, utan är uppbyggda av andra typer av element, finns det inget standardiserat sätt för hjälpmedel att tolka dem.
Detta kan ställa till problem för vissa användare. En person med synskada kanske missar att information uppdaterats dynamiskt, och en person med rörelsehinder kanske inte kan använda skjutreglaget om det inte går att styra med tangentbordet.
W3C har publicerat ramverket WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications), som är en specifikation för hur sådana gränssnittselement ska tolkas och utformas.
Stödet för WAI-ARIA är inte riktigt 100% ännu, men när du använder Javascript på webbplatsen bör du även tillämpa relevanta delar av WAI-ARIA.
ReferenserLänk hit
- Vilka är det som inte använder Javascript, och varför?
- Om progressiv förbättring (progressive enhancement) från den brittiska regeringen.
- En djupare diskussion hos W3C om att låta webbplatsen fungera både med och utan Javascript.
- På till exempel http://jster.net/ och http://javascripting.com/ kan man hitta tusentals Javascriptbibliotek. Observera att kvaliteten varierar stort.
- Introduktion till WAI-ARIA från W3C.
ExempelLänk hit
Daniel Malls Progressively Enhanced Stock Table är en bra illustration av progressiv förbättring. På sin blogg beskriver han (under rubriken ”Case study”) hur aktiekurser levereras som en html-tabell och sedan förbättras presentationen med javascript.
Återvinningssajten SyndAttKasta är byggd med progressiv förbättring. Den fungerar bra med och utan både css och javascript, men är smidigare med.
Kartfunktionen på Örebro kommuns webbplats använder script för att uppdatera adressfältet när användaren navigerar i kartan. Det gör att adressfältets innehåll kan användas för att referera just det användaren ser på kartan.
MätbarhetLänk hit
Stäng av Javascript i webbläsaren och kontrollera att allt innehåll är åtkomligt, att alla användargränssnittskomponenter går att använda och att e-tjänster fungerar.
Om ni använder WAI-ARIA kan många av funktionerna testas med en skärmläsare som t.ex. NVDA eller Jaws.
TerminologiLänk hit
Ordet script (eng. script) betyder manus. Ett script består, precis som teatermanus, framför allt av instruktioner om hur innehållet ska presenteras. Men ibland används script även för att tillföra nytt innehåll och funktionalitet. Idag är nästan alla script som körs i webbläsaren skrivna med språket Javascript.
Javascript har under benämningen ECMAScript blivit en internationell standard genom ISO.
Ajax står för Asynchronous Javascript and XML och är ett samlingsnamn för ett antal olika tekniker som kan användas för att bygga webbapplikationer med större interaktivitet än traditionella webbapplikationer.
Progressiv förbättring heter på engelska progressive enhancement, och är relaterat till principen om icke-störande (unobtrusive) programmering samt ”graceful degradation” vilket är en sorts omvänd progressiv förbättring: När någon kapacitet skalas av (t.ex. Javascript) ska detta hanteras på ett smidigt (förlåtande) sätt.
Kommentarer till denna riktlinje
Kommentarer (30)
Eftersom användandet av JavaScript bara ökar (med ramverk som jQuery och även mobila motsvarigheter), hur realistiskt är detta krav? Om det är någon som har bra tips på källor för hur man implementerar detta så mottas det tacksamt.
Som jag fattat det fungerar jquery så att om man inte har stöd för skript får man ändå funktionaliteten men inte lika snyggt.
JQuery är bara ett ramverk för javascript så att funktionalitet i största möjliga mån fungerar på samma sätt i alla läsare som stödjer javascript. Det löser alltså inte det du beskriver Björn. För att utveckla en webbplats som ska klara sig utan javascriptstöd måste man utforma funktionalitet så att den inte är javascript beroende och endast använda javascipt för att öka användarupplevelsen.
Utan javascript påslaget får besökaren en sämre upplevelse men ändå samma information. Det är den viktigaste aspekten. Det är alltid en utmaning att utveckla webbplatser som ska kunna köras utan javascript men det går absolut. Det bästa är att utveckla den utan stöd först och sedan lägga på javascript funktionalitet i efterhand för de funktioner som ökar användarupplevelsen.
Jens, ja om jag förstår dig rätt var det det jag försökte säga. Men du har rätt i att det inte är jquery som löser det utan det ser man till i den bakomliggande html-koden. Bra förtydligande.
Html5 kommer som tur är mer och mer men att inte tillåta javascript är som att säga att 10 brödskivor om dagen skall man äta eller att vi skall alla i Sverige borsta tänderna på samma gång.
Och vilka mobila enheter kör inte javascript? Ni använder javascript själva : Webbplatsen använder javascript exempelvis för att visa bildspel. Ja har ett förslag . Gå tillbaka till bläck och fjäderpenna och postryttare.
August, vi säger absolut inte att man inte ska använda skript. Denna skrivning är rätt tydig på det området:
"Observera att den här riktlinjen inte på något sätt ska tolkas som ett förbud mot att använda JavaScript. Tvärtom! JavaScript kan, rätt använt, öka både prestanda och användbarhet högst avsevärt för majoriteten av besökarna."
Vad vi säger är att webbplatsen måste fungera utan skript också.
Hej! Jag tycker den här riktlinjen har blivit onödigt hård. Avsaknaden av javaskript är mycket låg och korrekt implementerat fungerar det utmärkt i flera hjälpmedel. WCAG 2 har en hel del material om hur man uppfyller standarden med javaskript. Ett första steg kunde vara att sänka prioriteten från prio 1 och udner tiden fundera på en omformulering?
Hej Martn,
Jag förstår inte vad du menar? Vi säger verkligen inte att man inte får använd skript. Vad vi säger är att om man använder skript ska man göra det på rätt sätt. Vad är det du tycker är onödigt hårt? Om man gör fel utestängs viss grupper helt och det är väldigt allvarligt.
Den här riktlinjen är väldigt viktig, men ignoreras tyvärr av många som inte förstår problemet.
Jag surfar ofta via mobil eller olika linux-varianter och det är tyvärr mer regel än undantag att javascript-beroenden gör webbplatser oanvändbara. För det mesta är det helt i onödan, dvs javscripten bara duplicerar funktionalitet som lika gärna kunde skrivas i vanlig html.
T.o.m. en del myndigheter missar detta – se bara på "minameddelanden.se" som påstår att javascript är nödvändigt för inloggning med e-legitimation, medan pensionsmyndigheten glatt loggar in användare utan skriptstöd… 🙂
Att påstå att Ajax mm gör en sida snabbare är en sanning med modifikation. Det är helt beroende av vilken uppkoppling du har. Med 3G och hackiga/sega linor gör Ajax oftast att en sida tar längre tid att få fram/använda.
Håller också med om det märkliga att denna sida kräver skript för vissa funktioner…
Hallå Erik,
Ja vi håller med dig om att den är väldigt viktig. Tyvärr missförstår många innebörden av den och tror vi säger att man aldrig får använda skript, det är olyckligt, trots att jag tycker vi är väldigt tydliga på den punkten.
Spännande att pensionsmyndigheten inte kräver skript för eleg. Vi har letat efter en lösning på det problemet så tack för tipset. Om Ajax gör en sida snabbar beror inte bara på uppkopplingen utan vilka manuella moment det ersätter men visst, det är absolut en fråga som inte alltid har ett givet svar. Det är viktigt att man gör individuella bedömningar i de enskilda fallen.
Var kräver vi webbriktlinjer.se skript? Vi kanske har missat något?
Jag får nog ta tillbaka det om beroenden, ni verkar ha städat bort det som fanns i beta-versionen. Ursäkta – och bra! På e-delegationen.se finns en del t.ex. i form av s.k. ”delningslänkar”, men det är ju inte något kritiskt.
Skatteverket och Försäkringskassan har åtminstone förut hanterat e-legitimationer utan skriptstöd.
Ja intense debate som används för kommentarerna krävde skript i betaversionen men vi arbetade bort det till den skarpa siten.
När det gäller edelegationen.se så är vi medvetna om att dela-funktionen inte är helt bra. Det saknas till exempel alt-texter på bilderna för de olika tjänsterna och det beror på att det är bakgrundsbilder eller bilder inlagda med css (kommer inte ihåg vilket just nu) och då kan man inte lägga in alt-texter på dem. Det är inte bra men eftersom det var svårt att åtgärda och inte är en kritisk funktionalitet lät vi det vara.
Ska kolla upp detta med eid utan skript. Tror många är nyfikna på det. Sedan kommer det en mängd nya aktörer i och med den federation som elegitimationsnämnden arbetar med som kommer komplicera situationen.
PS Jag har försökt få reda på mer om hur man får igång bank-id utan skript men i alla fall skatteverket hävdar att de alltid krävt skript. Har du mer information?
Vad jag vet så kräver samtliga säkerhetsappar som bankerna utvecklat att javascript är påslaget i webbläsaren. Det är fallet oavsett om man använder gammal OSIF inloggning eller ny federerad SAML inloggning. Kanske (får vi hoppas) så blir det ändring i och med Svensk e-legitimation införande under nästa år.
Vanligt BankID kräver idag skript. Inloggning med mobilt BankID kan fungera utan och likaså e-legitimation från Telia (mha NetID).
Som Jens skriver får vi hoppas att bankerna tänker till och tar bort onödiga beroenden framöver.
Det är sant att BankID kräver skript, men jag har åtminstone tidigare i år loggat in hos Skatteverket utan skriptstöd dels med e-leg från Telia (NetID) och dels med mobilt BankID. Sedan de bytte till en extern leverantör av inloggningstjänsten kräver även e-leg från Telia skript.
Intressant, tackar för informationen!
Som Erik påpekar så ignoreras detta ofta av de som inte förstår, eller vill förstå, problemet.
Det handlar om att göra information tillgänglig för så många som möjligt.
Förutom de typer av webläsare, exempelvis för synskadade, som inte ens stödjer javascript så finns det dom som väljer att aktivt slå av javascript av olika anledningar. Inte minst av integritetsskäl.
Som alltid finns det undantag, spel- och film-sajter kan tjäna som exempel. Att tänka själv och använda sunt förnuft brukar räcka långt.
Tyvärr så är det alldeles för få som tar sig tiden att verkligen tänka till när det gäller användarvänlighet.
Jag håller med dig. Om man bara tänker till går det mesta att lösa. När jag körde pc hade jag skript avslaget och godkände det när jag hade ett behov.
Säger som jag såg någon klok webbutvecklare skriva. Vad är det ni vill ha webbsidor eller webbapplikationer.
Jag vet att det är bekymmersamt med hjälpmedel för synskadade m.m. men man kanske borde ta en titt på hur dessa verktyg fungerar. Det finns kanske hjälpmedel som skulle kunna klara av kod som körs på klienten (javascript)
Varför man skulle stänga av JavaScript av integritetsskäl är för mig helt obegripligt. Vad är det i ett programmeringsspråk som är hotar integriteten?
När det gäller vilka klienter de synskadade har så måste vi förhålla oss till verkligheten och inte önskningar om hur vi vill att det ska vara. Verkligheten är att många landsting inte uppgraderar till nya versioner, användarna få sitta med den version de fått rätt många år. En del användning av skript är helt ok för klienter och andra är det inte. Vår grundrekommendation är att webbplatsen/tjänsten ska fungera utan skript och att man sedan kan använda skript för att göra den mer lättanvänd.
En koppling mellan skript och integritet är annonstjänster. Dessa kan med hjälp av skript logga en hel del om dig som användare och i kombination med cookies kan de kartlägga hur du rör dig på internet om de lyckas placera sin annonser på tillräckligt många webbplatser.
En fråga, vad finns det för nackdelar med att skapa en webb som fungerar utan skript och sedan lägga på skript för att göra den med lättanvänd?
Frågan handlar inte om ”webbsidor” eller ”webbapplikationer”, utan om att erbjuda fungerande, webbaserade tjänster.
Ang. integritet så kan man med javascript – i synnerhet om man även kan jobba med Flash och Java – enkelt kartlägga surfvanor och intressen hos en besökare. Det är även lättare att ta sig in i en dator om du först kan identifiera den mha javascript. Många uppdateringar för webbläsare handlar också om säkerhetsproblem relaterat till javascript-motorn.
En viktig skillnad mellan html och javascript är också att html-tolken inte kraschar när den stöter på något obekant. Det gör den betydligt stabilare än en javascript-konstruktion.
Måste bara få tipsa om en sida hos W3C som ger utmärkta tips om dels hur man kodar bra JavaScript med avseende på det som den här artikeln handlar om och även bra förklaringar om varför det behövs. Se (http://www.w3.org/wiki/The_principles_of_unobtrusive_JavaScript)!
Arbetsutskottet för vägledningen för webbutveckling har tagit fram ett utkast till ny lydelse av riktlinjen om Javascript.
Se webbriktlinjer.se/utkast-javascript/
Förutom att strukturen på texten är ändrad enligt samma mall som resten av riktlinjerna har vi modifierat innehållet en del. Vi håller fast vid grundprincipen om progressiv förbättring, men vill samtidigt uppmuntra till användande av Javascript, och dessutom stimulera användandet av WAI-ARIA för ökad tillgänglighet i webbapplikationer. I undantagsfall ger den föreslagna formuleringen även utrymme för att frångå grundprincipen.
Vad tycker du?
Är det en rimlig balans?
Vad behöver förtydligas?
Vi önskar synpunkter på utkastet. Använd gärna detta kommentarsfält, eller någon av kontaktvägarna i sidfoten.
Vi tackar för feedback. Riktlinjen är nu uppdaterad.
Är den här riktlinjen fortfarande aktuell?
Det har ju hänt en hel del på den här fronten sedan 2016…
Har det hänt något som garanterar att alla JavaScript alltid laddar utan fel för alla användare?
Universell utformning (en version som fungerar för alla) är i stort sett alltid bättre än särlösningar. Det är inte svårare att bygga enligt principen progressiv förbättring. Man behöver bara lära sig att tänka i rätt ordning.
Ojojoj. Man får verkligen hoppas att den här riktlinjen går rakt i papperskorgen i år. Hela tillgänglighetsramverket behöver arbetas om från grunden. Man måste sätta rimliga gränser för incidensen i de fallstudier man väljer att ta med. Exkluderar man 1 av 5 är det kanske för mycket, men 1 av hundra måste vara ok. Dessutom anser jag att självpåtagna begränsningar, som att medvetet deaktivera javascript i sin webbläsare eller vägra uppgradera sin utrustning, måste diskvalificera studien direkt.
Vi sväljer ju betydligt allvarligare grejer, som till exempel medborgare utan tillgång till internet.
Kostnaden som anpassningarna innebär för normalanvändaren i form av försvårande för massan, måste också läggas till utvecklingskostnaderna innan eventuell nytta beräknas. Någonstans på kurvan skär vi ju kostnaden för att anställa människor som åker runt och hjälper de som har svårt att använda systemen.
Intentionen med den här riktlinjen är att uppmana till användningen av javascript så länge det sker utan att användarens upplevelse påverkas negativt på grund av mindre välskriven kod.
Som Tommy Olsson skriver i en tidigare kommentar så kan man aldrig garantera att JavaScript alltid laddar utan fel. Det går att dra ut den här diskussionen till att handla om vilka krav på alternativa lösningar som kan krävas av den organisation som driver en webbplats. I förlängningen bör det så klart finnas lösningar som garanterar att användaren kan genomföra en uppgift även om hela webbplatsen är ur funktion, t.ex. att kunna nå organisationen på telefon eller på annat sätt.
Skriv kommentar
Funktionen för att skriva kommentarer använder kakor. Läs mer om kakorna. Enbart förstapartskakor används. Vill du inte godkänna kakor så kan du ställa in din webbläsare att blockera dem. Funktionen går ändå att använda men den kommer då att ställa vissa frågor om och om igen, och kan inte förhandsvisa dina kommentarer.
För att kunna erbjuda denna funktion behöver vi lagra de uppgifter som du själv skriver in (namn, e-post, eventuell webbadress och själva kommentaren) samt IP-nummer. Den rättsliga grunden är samtycke och informationen ligger kvar så länge DIGG bedömer att den tillför förståelse för riktlinjen, eller tills du begär att den raderas. Läs mer om DIGGs behandling av personuppgifter.