Riktlinje nr 93 Prio 1
Gör inte webbplatsen beroende av JavaScript
Se till att webbplatsen eller e-tjänsten fungerar utan stöd för JavaScript.
Innehåll
Om denna riktlinje Länk hit
- Prioritet: 1
- Principer: Tillgänglig
- Roller/arbetsuppgifter: Tillgänglighet
- När i utvecklingsprocessen?:
Se till att webbplatsen eller e-tjänsten fungerar utan stöd för JavaScript.
Alla användare har inte stöd för JavaScript. Många mobila enheter saknar sådant stöd, medan vissa arbetsplatser blockerar JavaScript i sina brandväggar av säkerhetsskäl.
Andra användare väljer att stänga av JavaScript, antingen av säkerhetsskäl eller för att slippa reklam (rörliga bilder kan göra en webbplats näst intill oanvändbar för människor med vissa kognitiva funktionsnedsättningar).
Dynamiska förändringar i innehållet upptäcks inte alltid av hjälpmedel som skärmläsare, varför användaren inte görs uppmärksam på att något har hänt.
Genom att tillämpa principen om ”progressiv förbättring” är det möjligt att med ett minimum av extraarbete bygga tjänster som fungerar utan JavaScript och samtidigt ger mervärde för användare som har stöd för skript.
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.
I undantagsfall kan JavaScript krävas för att nödvändig funktionalitet överhuvudtaget ska fungera, t.ex. e-ID. I dessa fall ska användaren upplysas om att JavaScript krävs för att använda tjänsten.
Saker att ta hänsyn till när du använder skript i din webbplats/applikationLänk hit
Tänk på att göra det möjligt att använda funktioner utan tillgång till skript. Det måste gå att använda funktionerna, men kanske på ett mer grundläggande sätt, även utan skript. Användare som inte har stöd för skript i sin utrustning kan i vissa fall behöva information om att webbplatsen/funktionen fungerar sämre utan skript. Den presenteras lämpligen i anslutning till funktionen eller under avdelningen ”Om webbplatsen”.
- Undvik att använda skript för funktioner som redan finns i webbläsare eller fungerar lika bra utan skript. Några exempel:
- Navigationslänkar (görs enklast som vanliga länkar).
- Utskriftsfunktion (använd webbläsarens inbyggda funktioner för utskrift i kombination med en stilmall för utskrift).
- Om du använder skript för visuella effekter som förmedlar information till användarna bör du tänka på att samma information måste förmedlas 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å skriptbaserade valideringsfunktioner i formulär. Det måste gå att skicka in ett formulär utan skript. Information inlämnad av användare måste valideras på serversidan. Validering av informationen på serversidan bidrar också till skydd från attacker mot databaser.
- 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 skript 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.
Under förutsättning att ovanstående är uppfyllt kan JavaScript göra mycket för att förbättra användarupplevelsen. Inte minst gäller detta den teknik som kallas Ajax, och där JavaScript ingår som en del. 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.
Några kännetecken för Ajax:
- Snabbare webbsidor, där bara den information som visas för ögonblicket behöver laddas ner.
- Formulär som föreslår fortsättningar på det användaren börjar skriva.
- Inzoomning från överblicksbild till detaljer – användbart för kartor och för att göra statistik pedagogisk.
JavaScript och tillgänglighetLänk hit
Beroende på hur JavaScript används kan tillgängligheten på en webbplats påverkas. Många JavaScript-bibliotek innehåller funktioner som gör det enkelt att skapa nya typer av gränssnittselement som till exempel 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.
Därför kan sådan funktionalitet ställa till problem för vissa användare. En synskadad kanske missar att information uppdaterats dynamiskt och en rörelsehindrad kanske inte kan använda skjutreglaget om det inte går att styra med tangentbordet.
W3C arbetar med ett ramverk, WAI-ARIA (Accessible Rich Internet Applications Suite), i vilket man skapat en specifikation för hur sådana gränssnittselement ska tolkas och utformas. Detta kräver dock att användarna är utrustade med moderna versioner av såväl webbläsare som hjälpmedel för att det ska fungera. Hjälpmedel som programvara för talstöd kan vara dyra att uppgradera och därför saknar många användare möjligheten att arbeta i gränssnitt som är baserade på JavaScript, även om de följer riktlinjerna i WAI-ARIA.
Om du ändå bestämmer dig för att använda JavaScript i gränssnittet bör du säkerställa att det går att använda för så många som möjligt genom att testa med användare och olika typer av hjälpmedel.
MätbarhetLänk hit
Stäng av JavaScript i webbläsaren och verifiera att allt innehåll är åtkomligt, att alla användargränssnittskomponenter går att använda och att e-tjänsten fungerar.
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.
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?