Använd inte ramar
Använd i första hand serverbaserade tekniker för att infoga innehåll i sidor. Använd inte ramar (frames) för att utforma webbplatsen. Det orsakar nämligen en rad problem med användbarhet och tillgänglighet.
Rekommendationer för att infoga innehållLänk hit
- Använd i första hand serverbaserade tekniker.
- Komplettera eventuellt med klientscript (Ajax).
- Undvik iframes, eller kompensera för nackdelarna.
- Använd inte ramar (frames).
Ibland är det bättre att infoga innehåll dynamiskt än att kopieraLänk hit
Hämta gärna innehåll dynamiskt, direkt från källan, när användaren besöker sidan, om det fungerar med hänsyn till driftsäkerhet, intergitetsskydd, prestanda med mera. För innehåll som förändras ofta eller har interaktiva delar är en dynamisk koppling ofta den enda möjligheten, utöver en vanlig länk till källan. Men även för relativt statisk information kan det vara en bra lösning i jämförelse med att kopiera innehållet när sidan skapas, eftersom det blir enklare att hålla innehållet konsekvent och uppdaterat.
Det finns många sätt att infoga innehåll från olika källor i den html-kod som utgör en webbsida.
Infoga helst på serversidanLänk hit
Sammanfoga i första hand på serversidan. Då blir resultatet, ur webbläsarens perspektiv, nämligen likvärdigt med vilken HTML-sida som helst. Att sammanfoga innehåll från olika källor är en av de viktigaste funktionerna med ett webbpubliceringsverktyg (CMS).
Redan på 1990-talet användes server-side includes (SSI) för att till exempel kunna återanvända sidhuvud och navigeringsmeny. Senare har en mängd tekniska lösningar utvecklats, som kan infoga lokalt eller externt, statiskt eller dynamiskt innehåll, till exempel Java beans, PHP include, ASP.NET user controls och portlets.
Komplettera eventuellt med klientscriptLänk hit
Det går också att låta webbläsaren sammanfoga innehållet. Fördelen är att det ofta går enkelt och snabbt. Oftast räcker det med att kopiera in en kort snutt HTML-kod med adressen till källan, vilket ni ofta kan göra utan hjälp av en programmerare. Det påverkar inte heller belastningen på servern.
För webbapplikationer med intensiv interaktion (kallas ibland rich internet applications – RIA) är det ofta lämpligt att låta webbläsaren, snarare än servern, sköta den dynamiska uppdateringen av innehållet på sidan. Framförallt används då Javascript (AJAX) för att dynamiskt kommunicera med servern. Läs mer om detta i R93 Använd Javascript för att öka tillgängligheten – inte tvärtom.
Använd inte ramarLänk hit
Den första tekniska lösningen för infogning på klientsidan var ramar (frames). De användes ofta för navigation och sidhuvud när webben var ung. Men de är en dålig lösning, eftersom ramar orsakar en rad användbarhets- och tillgänglighetsproblem. Ramar gör att det blir
- svårt eller omöjligt att spara bokmärken i webbläsare
- svårt eller omöjligt att skicka en länk till en sida via e-post eller dela i sociala medier
- svårt eller omöjligt att kommunicera en länkadress i tryck
- svårare att skapa en webbplats som indexeras och hittas av sökmotorer på ett optimalt sätt
- svårare att hantera besökare som kommer till webbplatsen via sökmotorer
- svårare att använda webbplatsen för användare med skärmläsare eller textwebbläsare
- svårare för användaren att skriva ut webbplatsens innehåll.
Iframes
En något nyare, men närbesläktad teknik är iframes. En iframe kan beskrivas som ett rektangulärt hål i en webbsida, inuti vilket en annan webbsida visas. I några fall är detta den enda framkomliga vägen, och därför vill vi inte helt döma ut alternativet. Men om du överväger iframes så tänk på följande:
- I princip alla problemen med ramar gäller även iframes. Några av dem går delvis att kompensera för med script. Till exempel kan adressfältet uppdateras vid interaktion inom ramen på det sättet.
- Iframes är ofta svåra att hantera på mobilen. Till exempel är det inte uppenbart för användaren om rullning och zoomning gäller ramen eller omgivningen. Och det är svårt att ge ramen rätt storlek i alla typer av enheter. Ska din webbplats kunna användas med olika skärmstorlek så kanske du behöver skapa flera alternativa storlekar på ramen.
- Sökmotorer räknar innehållets värde till den inramade sidan eller webbplatsen, inte till din sida. Om de överhuvudtaget hittar innehållet.
- Det är inte troligt att innehåll som ligger i en iframe går att hitta med webbplatsens egen sökfunktion, om du inte anpassar den särskilt för detta.
MätbarhetLänk hit
Använd en webbläsare som inte har stöd för ramar, till exempel Lynx, och kontrollera att innehållet ändå är nåbart och begripligt.
Opera ger också möjlighet att enkelt stänga av stöd för ramar och iframes.
Kommentarer till denna riktlinje
Kommentarer (6)
Hej hopp!
Om man har hemsidor med frames, hur gör man för att bli av med dem? Jag antar att hela sidan måste göras om från grunden. Jag kan inget annat än att göra hemsidor med frames. Tekniken är minst 25 år gammal.
Du behöver titta på ett lämpligt språk på serversidan, till exempel PHP för mindre tillämpningar, Java eller C#.NET för mer komplexa applikationer.
Hej, jag har en kontakt m en leverantör som säger sig leverera iframes enligt WCAG 2.1. Jag har svårt att få ihop den här riktlinjen med det, men kan det stämma? Och är det i så fall ok att använda?
Att bygga en webbplats med frames i dag kan nog knappast räknas som acceptabelt. Många använder fortfarande tjänster som bäddas in med iframes, så det får väl anses godtagbart.
Hej, kan man uppfylla WCAG 2.1 trots att man har iFrames på sin webbplats/tjänst? Jag får inte riktigt ihop vad som gäller.
Det finns inget i WCAG 2.1 som specifikt förbjuder iframes. Förr kunde iframes orsaka tangentbordsfällor, då det inte gick att navigera ut ur en iframe via tangentbordet i vissa webbläsare. Nu verkar det i alla fungera i alla moderna webbläsare. Jag känner inte till några utestående tillgänglighetsproblem som berör iframes i dag. HTML 5 har ju tagit
iframe
-elementet till nåders igen, så inte ens kriterium 4.1.1 torde bli underkänt.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.