WCAG:s riktlinjer och riktpunkter

Översättningen av riktpunkterna är från 24-timmarswebben, med mindre justeringar för att få terminologin konsekvent med resten av boken. Riktlinjerna (alltså rubrikerna) är översatta av mig.

RIKTLINJE 1: Information i ljud, bilder och multimedia skall också finnas som text

WCAG 1.1 Se till att tillhandahålla ett textalternativ för varje element som inte är text (exempelvis via ”alt ”, ”longdesc”, eller i innehållet i elementet). Detta innefattar: Bilder, grafiska representationer av text (inklusive symboler), klickbara bilder , animeringar (exempelvis animerade GIF filer), appletprogram (applets) och andra program, bokstavsbilder (”ascii-art”), ramar (frames), bilder som används som listmarkörer, positioneringsbilder (spacers), grafiska knappar, ljud (som spelas med eller utan användarens inblandning), ljudfiler, ljudspår till video- och filmklipp, och video- och filmklipp.

Lång riktpunkt som i allt väsentligt betyder att det till bilder, ljud och multimedia också skall finnas text, som fyller samma funktion för användaren. Observera att tonvikten ligger vid funktion, inte vid att beskriva hur ljudet låter, bilden ser ut, etc.

Ta inte riktpunkter för bokstavlig, är det inte motiverat att ha någon text behöver man inte ha någon. Kom ihåg att syftet är att göra webbplatsen så tillgänglig som möjligt för alla användare, inte att till sista bokstaven följa en standard.

Motsvarande råd:

• alt & longdesc – texter för dem som inte ser bilder, sid 60.

• Gör det möjligt för den som inte kan se att ändå ta del av innehåll, funktion och upplevelse i visuell multimedia, sid 74.

• Gör det möjligt för den som inte kan höra att ändå ta del av innehåll i ljud , sid 75.

• Ge alternativ text för webbläsare som inte klarar ramar, sid 85.

• Ge områdena i en multiklickbar bild förklarande texter, sid 127.

• Om knappen görs av en bild, skall den ha alt-text, sid 261.

• Använd inte visuella tester för att skilja människa och maskin , sid 324.

• Ge en alternativ text för webbläsare som inte klarar javascript , sid 432.

I samma anda:

• title – hjälptexter, bonusinformation och tips, sid 62.

WCAG 1.2 Tillhandahåll extra textlänkar för varje aktivt område i en serverhanterad multiklickbar bild.

Det är numera sällsynt att använda serverbaserade bildkartor, så denna punkt är i det närmaste överspelad.

Se även WCAG 1.5 och 9.1

WCAG 1.3 Till dess att användarprogram kan läsa upp innehållet i ett textalternativ till en visuell presentation, skall du tillhandahålla en beskrivning i ljudform av den viktiga informationen i den visuella delen av en multimediepresentation.

Motsvarande råd: Gör det möjligt för den som inte kan se att ändå ta del av innehåll, funktion och upplevelse i visuell multimedia, sid 74.

WCAG 1.4 För varje tidsstyrd multimediepresentation (till exempel en film eller animering), synkronisera de alternativa presentationerna (till exempel textremsa eller ljudbeskrivning) med presentationen.

Motsvarande råd: Gör det möjligt för den som inte kan se att ändå ta del av innehåll, funktion och upplevelse i visuell multimedia, sid 74.

WCAG 1.5 Till dess att användarprogram kan läsa ut textalternativ till en multiklickbar bild, tillhandahåll extra textalternativ för varje aktivt område i en multiklickbar bild.

Motsvarande råd: Ge områdena i en multiklickbar bild förklarande texter , sid 127.

I samma anda som riktlinje 1:

(Under denna rubrik samlas råd som inte uttryckligen tas upp i WCAG, men som verkar för samma mål.)

• Använd inte visuella tester för att skilja människa och maskin , sid 324.

RIKTLINJE 2: Text och bilder skall vara begripliga även utan färg

WCAG 2.1 Se till att all information som visas med hjälp av färg också kan uppfattas utan färg, exempelvis genom placeringen i dokumentet eller med hjälp av märk-kodningen.

Motsvarande råd: Det får inte vara nödvändigt att kunna skilja mellan olika färger , sid 66.

WCAG 2.2 Se till att kombinationer av förgrunds- och bakgrundsfärger ger tillräckligt hög kontrast när de visas på en monokrom bildskärm, eller ses av en användare som har problem med färgseendet.

Numera finns knappt något behov av att ta hänsyn till svartvita skärmar. Däremot till färgblinda användare.

Motsvarande råd:

• Gör kontrasten mellan text och bakgrund tydlig, sid 66.

• Gör kontrasten i bilder tydlig, sid 66.

RIKTLINJE 3: Använd HTML för innehåll och format­mallar för utseende

WCAG 3.1 När ett lämpligt märk-kodspråk finns tillgängligt, använd hellre märk-kod än bilder för att visa information.

Motsvarande råd:

• Gör rubriken som text, sid 56.

• Gör menyer med text, inte med bilder, sid 130.

• Knapptext bör inte göras som bild, sid 261.

WCAG 3.2 Skapa dokument som kan valideras i formella programmeringskodningssystem.

Motsvarande råd:

• Följ HTML-standarden, sid 418.

• Validera HTML-koden , sid 420.

• Följ formatmallsstandarden, sid 424.

• Validera formatmallarna, sid 424.

WCAG 3.3 Använd formatmallar för att åstadkomma avsedd layout och presentation.

Motsvarande råd:

• Använd inte tabeller för layout, sid 249.

• Använd formatmallar , sid 423.

• Ge skärmläsare egna formatmallar, sid 425.

• Styr skärmläsarens röst med akustiska formatmallar, sid 425.

3.4 WCAG Använd relativa snarare än absoluta enheter i märk-kodningens attributvärden och i formatmallarnas egenskapsvärden.

Det finns flera missförstånd kring denna punkt. Vad den faktiskt säger är att skall undvika absoluta måttenheter som cm, mm, pt och pc . Istället bör relativa enheter användas, till exempel em och px . Eftersom praktiskt taget ingen använder absoluta enheter (annat än enstaka före detta pappersformgivare som vägrar överge pt (punkter) som mått för textstorlek), är detta en riktpunkt utan egentlig konsekvens.

Eller skulle åtminstone vara det, om det inte vore för det att Internet Explorer låter användaren styra storleken på text angiven med em, men inte på text angiven med px. Detta har fått många att dra den felaktiga (men förståeliga) slutsatsen att px är en absolut måttenhet.

Denna brist hos Internet Explorer är ett stort problem (se Textstorlek , sid 46, för ett mer djupgående resonemang kring detta, och förslag till lösningar). Det är dock inte ett problem som egentligen har med denna riktpunkt att göra.

Missförståndet kring px tillsammans med en alltför bokstavlig tolkning av den här riktpunkten gör att många tillgänglighetstester ger falsklarm även för lösningar som faktiskt ger användaren kontroll över textstorleken.

Motsvarande råd:

• Använd mått som ger användaren kontroll över textstorleken – och aldrig liten text , sid 48.

• Ge användaren färdiga alternativ att välja mellan, sid 48.

• Sidorna måste vara användbara även när användaren ställer in en större textstorlek , sid 49.

• Sidorna bör se bra ut även när användaren ställer in en större textstorlek , sid 50.

WCAG 3.5 Använd rubriknivåer för att ange dokumentstrukturen och använd dem för avsett ändamål.

Motsvarande råd: Använd HTML-element utifrån betydelse, sid 420.

WCAG 3.6 Märk-koda listor och listposter på rätt sätt.

Motsvarande råd:

• Använd listkod för att skapa listor, sid 242.

• Använd HTML-element utifrån betydelse, sid 420.

I samma anda:

• Avståndet mellan punkter skall vara större än radavståndet, sid 53.

WCAG 3.7 Märk-koda citat . Använd inte märk-koden QUOTE för att skapa formatteringseffekter, såsom indrag.

Riktpunken säger att citat skall märkas upp med <q> (i enhetlighet med HTML-standarden). Detta är ett orealistiskt råd, eftersom webbläsarbuggar gör att <q> överhuvudtaget inte bör användas.

Motsvarande råd: Använd HTML-element utifrån betydelse, sid 420.

I samma anda som riktlinje 3

• Använd ett lättläst typsnitt för den löpande texten, sid 51.

• Låt användaren själv ställa in typsnittet, sid 52.

• Ge användaren färdiga typsnittsalternativ att välja mellan , sid 53.

• Använd ett radavstånd som underlättar läsning, sid 53.

• Spaltbredd , sid 53.

• Lämna luft till höger och vänster om texten, sid 55.

• Låt inte knappar fungera som länkar eller länkar som knappar , sid 120.

• Låt ramen runt klickbara bilder vara kvar, sid 126.

• Använd HTML-element utifrån betydelse, sid 420.

• Använd inte HTML-text som symboler, pilar eller bilder, sid 421.

RIKTLINJE 4: Ange vilket språk som används

WCAG 4.1 Ange tydligt när det naturliga språket ändras i ett dokument, liksom i textmotsvarigheterna (till exempel bildtexter).

Denna riktpunkt hänger nära samman med WCAG 4.3 nedan. Medan 4.3 säger att dokumentets huvudspråk bör anges, säger denna punkt att det skall markeras i HTML-koden om någon del av innehållet är på ett annat språk.

Motsvarande råd: Markera i HTML-koden vilket språk som används, sid 422.

WCAG 4.2 Ange alltid vad en förkortning står för när den förekommer för första gången.

Motsvarande råd: Förklara förkortningar, sid 94.

WCAG 4.3 Ange det huvudsakliga naturliga språket i dokumentet.

Motsvarande råd: Markera i HTML-koden vilket språk som används, sid 422.

Det finns ett resonemang i standarden om att språket skall anges under den inledande uppkopplingen mellan användarens dator och webbservern, så att användarens webbläsare automatiskt kan hämta rätt språkversion. Jag har aldrig sett detta fungera i praktiken och tror inte det är realistiskt – se Använd inte automatiskt språkval, sid 105.

RIKTLINJE 5: Tabeller skall klara att omvandlas till löpande text

Tabeller utgör en särskild utmaning för den som använder skärmläsare. De har två dimensioner, medan skärmläsaren bara klarar att återge en. Därför behövs en mängd åtgärder för att trots detta göra dem överblickbara.

WCAG 5.1 I datatabeller, ange rad- och kolumnöverskrifter.

Motsvarande råd: Koppla datatabellens rader och kolumner till sina rubriker, sid 248.

WCAG 5.2 I datatabeller som har två eller flera logiska nivåer med rad- och kolumnöverskrifter, märk-koda så att dataceller och överskriftsceller knyts samman.

Motsvarande råd: Koppla datatabellens rader och kolumner till sina rubriker, sid 248.

I riktpunktens text rekommenderas att använda axis. Det skadar inte att göra det – men gör inte heller någon nytta, eftersom det inte finns någon webbläsare som stöder det.

WCAG 5.3 Använd inte tabeller för layout om inte tabellens innehåll blir begripligt när tabellen läses linjärt. Om innehållet inte är begripligt, tillhandahåll ett alternativ med motsvarande innehåll, (vilket kan vara en linjär version).

I en not till riktpunkten sägs att när det finns webbläsare som klarar av layout med hjälp av formatmallar, får inte längre tabeller användas för layout. Vi är nu nära den situationen – de flesta webbläsare klarar det, men inte med den lätthet och robusthet som man möjligen har rätt att kräva.

Min personliga tolkning är att det fortfarande är tillåtet att använda tabeller för layout. Andra menar att man måste använda formatmallar om man vill följa denna riktpunkt (vilket också sammanfaller med 24-timmars­webbens krav).

Motsvarande råd:

• Använd inte tabeller för layout, sid 249.

• Tabeller skall konstrueras så att de är begripliga även när de läses upp som löpande text , sid 247.

WCAG 5.4 Om en tabell används för layout, använd inte strukturmärk-koder för att åstadkomma visuell formatering.

Motsvarande råd:

• Använd inte tabeller för layout, sid 249 (tar upp vilka element som inte skall användas, när tabeller trots allt används för layout)

• Använd HTML-element utifrån betydelse, sid 420.

WCAG 5.5 Tillhandahåll sammanfattningar av tabeller.

Motsvarande råd:

• Ge datatabeller en etikett, sid 248.

• Ge datatabeller en sammanfattning, sid 248.

WCAG 5.6 Tillhandahåll förkortningar för tabellöverskrifter och rad- och kolumnhuvuden.

Motsvarande råd: Koppla datatabellens rader och kolumner till sina rubriker, sid 248.

RIKTLINJE 6: Även om användaren inte har senaste tekniken skall hon kunna läsa innehållet

WCAG 6.1 Strukturera dina dokument så de kan läsas utan formatmallar . Om till exempel ett HTML-dokument visas på skärmen utan att formatmallen används, skall det fortfarande vara möjligt att läsa dokumentet.

Motsvarande råd: Gör HTML-koden så den fungerar även utan formatmallar, sid 421.

WCAG 6.2 Se till att textalternativen till dynamiskt skapat innehåll uppdateras när det dynamiska innehållet ändras.

När det finns textalternativ till eller beskrivningar av innehållet i bilder, multimedia, javascript, ramar etc. måste alternativet hålls synkroniserat med originalet om detta ändrar sig.

Detta rör riktpunkter som WCAG 1.1, 1.3, 6.5 och 14.2.

WCAG 6.3 Se till att sidorna är användbara även om scriptprogram, appletprogram, och andra program är frånslagna eller inte stöds i webbläsaren. Om detta inte kan uppnås så tillhandahåll motsvarande information på en alternativ, tillgänglig sida.

Webbplatsen måste vara användbar även för dem med webbläsare utan javascript , Flash , Java, ActiveX och liknande tekniker.

Vad gäller javascript råder delade meningar om hur aktuell denna riktpunkt är. Det finns många tillgänglighetsmänniskor som menar att en webbplats som kräver javascript är otillgänglig. Men det finns också många andra som menar att denna punkt är överspelad. Mer om det i Använd javascript, och ge alternativa vägar till innehåll och funktion bara om det är rimligt enkelt, sid 427.

Det finns också anledning att skilja på skript och multimedia som måste fungera för att användaren skall kunna komma åt väsentlig information, och sådan som har ett mer dekorativt eller roande syfte.

Motsvarande råd:

• Multimedia skall vara lika tillgängligt som annat innehåll, sid 73.

• Mjuklanda användare som inte tar emot kakor, sid 326.

• Använd javascript, men gör information och funktion tillgängliga även på andra sätt , sid 427.

• Använd javascript endast till ickeväsentliga funktioner , sid 427.

• Använd inte javascript, sid 428.

• Använd händelsehanterare för att koppla javascript till länkar och formulär , sid 432.

• Ge en alternativ text för webbläsare som inte klarar javascript , sid 432.

• Gör webbplatsen så att den är användbar med alla webbläsare, sid 435.

WCAG 6.4 För scriptprogram och appletprogram, se till att de händelsehanterare som används är oberoende av vilken utrustning användaren utnyttjar.

Javascript och multimedia får inte göra några antaganden om vilken utrustning som används för att läsa webben. I praktiken handlar det om att man inte kan utgå från att användaren har en mus , utan måste utforma webbplatsen så den kan användas från tangentbordet .

Motsvarande råd:

• Använd inte javascript som förutsätter att användaren har mus, sid 429.

• Val­box­meny­er måste kunna användas utan mus, sid 141.

WCAG 6.5 Se till att dynamiskt genererat innehåll är tillgängligt, eller tillhandahåll en alternativ presentation eller sida.

Allt innehåll, även det som presenteras genom ramar eller genereras via skript, skall vara tillgängligt, antingen direkt eller genom att samma innehåll finns i någon annan form.

Motsvarande råd:

• Ändra inte innehåll på sidan utan att ge användaren en möjlighet att bli uppmärksammad på detta, sid 431.

• Ge en alternativ text för webbläsare som inte klarar javascript , sid 432.

• Ge alternativ text för webbläsare som inte klarar ramar, sid 85.

I samma anda som riktlinje 6

• Gör inga antaganden om skärmens eller fönstrets storlek, sid 81.

• Testa webbplatsen med de viktiga webbläsarna, sid 437.

RIKTLINJE 7: Ge användaren kontroll över hur saker ändras

WCAG 7.1 Till dess att användarprogram medger användaren att styra skärmflimmer , undvik funktioner som får skärmen att flimra.

Motsvarande råd: Använd inte blinkningar som kan utlösa epileptiska anfall, sid 71.

WCAG 7.2 Till dess att användarprogram medger att användaren kan styra blinkfrekvensen , undvik funktioner som får innehåll att blinka (det vill säga som förändrar presentationen regelbundet, till exempel genom att stänga av och slå på den).

Det går numera att stoppa uppspelningen av animerade bilder (så kallade animerade gifar) i många webbläsare genom att trycka på esc-knappen, eller att stänga av det helt, så i det avseendet är denna riktpunkt överspelad (vilket inte ändrar att det fortfarande inte är en bra idé att ha blinkande bilder på sidan).

För multimediepresentationer gäller att det måste finnas en möjlighet att stoppa dem.

De blinkande rörliga HTML-elementen <blink> och <marquee> tillhör inte standarden och skall inte användas.

Motsvarande råd:

• Undvik animationer intill text, sid 71.

• Starta inte multimediepresentationer automatiskt, sid 72.

• Ge användaren möjlighet att stoppa multimediepresentationer , sid 73.

• Följ HTML-standarden, sid 418.

WCAG 7.3 Till dess att användarprogram medger att användaren kan stoppa rörelser i innehållet, undvik animeringar.

Se WCAG 7.2.

WCAG 7.4 Till dess att användarprogrammen tillhandahåller möjligheter att avbryta automatiska uppdateringar , använd inte sidor som uppdaterar sig automatiskt.

Motsvarande råd: Låt användaren stänga av automatisk omladdning av sidor, sid 333. (Observera att detta råd inte bokstavstroget följer riktpunkten, eftersom det istället för att avråda från autouppdaterade sidor säger att användaren skall ha en kontroll över dem. Detta är en liberalare linje som är på väg in i nästa version av WCAG ¹⁸.)

WCAG 7.5 Till dess att användarprogram medger att användaren stänger av automatisk omdirigering, använd inte märk-kodningar som styr om sidor automatiskt. Använd i stället servern för att göra omdirigeringar av innehållet.

Motsvarande råd: Använd webbservern, inte meta-taggar, för att eftersända, sid 422.

I samma anda som riktlinje 7

• Släng inte kundvagnen bara för att användaren tar en paus, sid 397.

RIKTLINJE 8: Multimedia skall också ha ett tillgängligt gränssnitt

WCAG 8.1 Se till att program, som scriptprogram och appletprogram, har tillgängliga användargränssnitt eller kan användas tillsammans med stödtekniker för funktionshindrade.

Motsvarande råd:

• Multimedia skall vara lika tillgängligt som annat innehåll, sid 73.

• Använd inte javascript som förutsätter att användaren har mus, sid 429.

• Ändra inte innehåll på sidan utan att ge användaren en möjlighet att bli uppmärksammad på detta, sid 431.

• Flytta inte fokus , sid 431.

• Använd den standardiserade dokumentobjektmodellen , sid 432.

Se även riktpunkt WCAG 9.2, som ställer kravet på multimedia att den skall vara tillgänglig oavsett vilken utrustning användaren har, och WCAG 9.3 som i praktiken kräver samma sak av javascript, samt i riktlinjen WCAG 6 som kräver att användaren inte skall behöva ha senaste programmen för att kunna ta till sig innehållet.

RIKTLINJE 9: Webbplatsen skall vara tillgänglig oavsett vilken utrustning användaren har

En liten genomgång av vilken utrustning funktionshindrade kan ha för att surfa på webben finns i Webbläsare för funktionshindrade, sid 346.

WCAG 9.1 Tillhandahåll klienthanterade multiklickbara bilder istället för serverhanterade multiklickbara bilder, förutom i fall då de aktiva regionerna inte kan definieras som geometriska former.

Motsvarande råd: Lägg bildkartan på användarens dator, inte på servern, sid 126.

Se även WCAG 1.2.

WCAG 9.2 Se till att alla element som har egna användargränssnitt kan användas oberoende av användarens utrustning.

Motsvarande råd:

• Multimedia skall vara lika tillgängligt som annat innehåll, sid 73.

• Använd inte javascript som förutsätter att användaren har mus, sid 429.

• Gör PDF och andra dokument tillgängliga , sid 442.

Se även WCAG 8.1.

WCAG 9.3 Ange logiska händelsehanterare i stället för utrustningsberoende händelsehanterare i scriptprogram.

Även denna riktpunkt är egentligen ett specialfall av WCAG 8.1 – även javascript skall fungera oavsett utrustning, och detta inbegriper bland annat att låta bli händelsehanterare som bara fungerar med t.ex. mus.

Observera att även om denna riktpunkt bara har prioritet 2, så gäller den generellare – och sträng­are – WCAG 8.1 även för javascript.

Motsvarande råd:

• Rullgardinsmenyer på webben bör fungera som vanliga datormenyer, sid 138.

• Val­box­meny­er måste kunna användas utan mus, sid 141.

• Använd inte javascript som förutsätter att användaren har mus, sid 429.

WCAG 9.4 Skapa en logisk ordning i länkar, formulär, och objekt, så användaren kan stega (genom tabulering) mellan dem.

Motsvarande råd: Gör tabbordningen logisk och förutsebar, sid 230.

WCAG 9.5 Använd snabbvalstangenter för viktiga länkar (inklusive länkar i klienthanterade klickbara bilder), formulärknappar, och grupper av styrelement i formulär.

Eftersom snabbtangenter i webbläsaren och på webbsidan kolliderar, är det inte någon bra idé att försöka följa den här riktpunkten. Det finns dock några kortkommandon definierade i 24-timmarswebben som kan användas.

Motsvarande råd: Viktiga funktioner och sidor skall kunna nås med kortkommandon , sid 231.

I samma anda som riktlinje 9

• Gör inga antaganden om skärmens eller fönstrets storlek, sid 81.

• Gör inte den klickbara ytan för liten, sid 119.

• Låt användarna prenumerera på webbplatsen, sid 227.

• Separera navigationen från sidan, sid 374.

RIKTLINJE 10: Saker att tänka på i väntan på att webb­läsarna blir bättre

WCAG 10.1 Till dess att användarprogram medger att användaren slår av funktioner som automatiskt öppnar nya fönster från det aktiva fönstret, använd inte funktionalitet som förorsakar att menyer eller andra fönster öppnas automatiskt, och som ändrar det aktiva fönstret utan att informera användaren.

Även om det nu finns webbläsare där det är möjligt att hindra nya fönster från att öppnas, är de inte tillräckligt spridda för att ignorera denna riktpunkt.

Motsvarande råd:

• Undvik att öppna nya fönster, sid 329.

• Förvarna om att ett nytt fönster kommer att öppnas, och ge en tydlig väg tillbaka , sid 331.

WCAG 10.2 Till dess att användarprogram ger stöd för uttryckliga associationer mellan etiketter och formulärets styrelement, se till att etiketten blir korrekt placerad i formulär med implicit associerade etiketter.

Motsvarande råd: Koppla samman etikett och kontroll, sid 268.

WCAG 10.3 Till dess att användarprogram (inklusive stödtekniker för funktionshindrade) återger textkolumner (sida vid sida) korrekt, tillhandahåll ett linjärt alternativ (på den aktuella sidan, eller på någon annan sida) för alla tabeller som placerar text i parallella, radbrutna kolumner.

Denna behöver inte tas hänsyn till längre.

WCAG 10.4 Till dess att användarprogram kan hantera tomma styrelement korrekt, använd platshållare i tomma styrelement i redigeringsrutor och textområden.

Denna behöver inte tas hänsyn till längre.

WCAG 10.5 Till dess att användarprogram (inklusive stödtekniker för funktionshindrade) kan se till att näraliggande länkar visas tydligt, lägg in icke-länkade, utskrivbara tecken (som omges av mellanslag) mellan näraliggande länkar.

Denna behöver inte tas hänsyn till längre (men det är naturligtvis fortfarande en dålig idé att utforma länkar så att det inte är uppenbart var en slutar och nästa börjar). 24-timmarswebben rekommenderar dock att man fortfarande följer den.

RIKTLINJE 11: Använd W3C:s tekniker och riktlinjer

Detta tycker jag personligen är en problematisk riktlinje. Den andas mer organisationsegoism än omsorg om tillgängligheten.

Det är klart att ur W3C:s perspektiv så är det enklast om de får ta hand om allting och kan skapa en sammanhängande och genomtänkt struktur av standarder. Men i verkligheten har vi en snabb utveckling, och flera de facto-standarder har uppstått. Till exempel är det tveksamt om W3C:s multimediestandard SVG, med de svaga utvecklingsverktyg som finns för den, verkligen är en bättre teknik för tillgängligheten än Flash.

Men det är som sagt min åsikt. Vill du följa WCAG strikt så är det W3C-tekniker som gäller.

WCAG 11.1 Använd W3C:s tekniker när de kan användas och är lämpliga för det aktuella behovet. Använd den senaste versionen om den stöds.

Strävan att använda de senaste versionerna av standarder, och att överge de delar av standarden som är under avveckling, måste dock balanseras mot behovet av att stödja äldre webbläsare. Så får man till exempel räkna med att det kommer att dröja många år innan webbplatser kan göras enbart med den kommande standarden XHTML 2, eftersom denna kommer att skilja sig radikalt från dagens HTML.

Motsvarande råd:

• Följ HTML-standarden, sid 418.

• Använd den standardiserade dokumentobjektmodellen, sid 432.

• Använd formatmallar , sid 423.

• Använd HTML, inte PDF, sid 439.

WCAG 11.2 Undvik nedgraderade funktioner i W3C:s tekniker.

Motsvarande råd: Använd inte nedgraderade delar av HTML, sid 419.

WCAG 11.3 Tillhandahåll information så användare kan få dokument i enlighet med sina preferenser (till exempel språk, innehållstyp, etc).

När standarden skrevs trodde man mycket på så kallad content negotiation, det vill säga att inställningar i webbläsaren skulle berätta för webbservern både vilket språk användaren föredrar och om hon till exempel har några speciella tillgänglighetsbehov. I praktiken har det inte blivit så mycket av det. Man kan mycket väl följa den här riktpunkten, men räkna inte med att det gör någon större nytta. Se dock Använd inte automatiskt språkval, sid 105.

WCAG 11.4 När du, trots ansträngning, ändå inte kan skapa en tillgänglig sida, tillhandahåll en länk till en alternativ sida som använder teknik som specificerats av W3C, är tillgänglig för funktionshindrade, och har motsvarande information (eller funktion), och som uppdateras lika ofta som den ursprungliga (svårtillgängliga) sidan.

När standarden skrevs fanns det många webbplatser som hanterade handikapproblemen genom att göra en 'enbart text'-variant av webbplatsen. Denna textversion hade sedan en tendens att halka långt ner på prioriteringslistan hos de stressade webbredaktionerna och inte vara alls lika uppdaterad som den grafiska versionen. Därför är WCAG en avvisande ton gentemot speciella versioner för funktionshindrade.

Idag är läget ett annat. Webbplatser som görs med publiceringssystem kan ha olika versioner som alla uppdateras samtidigt och utan att det kräver någon extra arbetsinsats (annat än när webbplatsen skapas).

Samtidigt har tekniken gått framåt också på det sättet att det blivit mycket lättare att göra en version av webbplatsen som är tillgänglig för alla. Behovet av en speciell handikappversion har minskat väsentligt.

De flesta väljer numera att gå den senare vägen. Det känns trots allt trevligare att kunna ha en webbplats för alla, istället för att ha reservat för olika sorters användare. Men så länge man säkerställer att uppdateringen sköts är det inget fel med att lösa tillgänglighetsproblem genom att göra olika versioner av sidan.

RIKTLINJE 12: Gör det lätt för användaren att hitta på sidan

WCAG 12.1 Namnge varje ram för att underlätta ramidentifiering och navigation mellan dem.

Motsvarande råd: Döp ramarna , sid 84.

WCAG 12.2 Beskriv syftet med ramar och hur de förhåller sig till varandra, om detta inte självklart framgår av ramarnas titlar.

Motsvarande råd: Döp ramarna , sid 84.

WCAG 12.3 Dela upp stora informationsmassor i mer hanterliga grupper där det är naturligt och lämpligt.

Motsvarande råd:

• Gruppera och etikettera alternativen , sid 256.

• Gruppera och namnge formulärets delar, sid 273.

WCAG 12.4 Se till att styrelement i formulär är explicit kopplade till etiketterna.

Motsvarande råd: Koppla samman etikett och kontroll, sid 268.

Med tanke på att utformningen av formulär helt kan avgöra om en webbplats – speciellt en webbapplikation – är tillgänglig eller inte, har WCAG förvånande litet att säga om dem.

Se nedan för tips om andra sätt att göra formulär tillgängligare.

I samma anda som riktlinje 12

• Bädda med kringmaterial och luft i botten av sidan så att page down och ankare fungerar som ögat väntar sig, sid 80.

• Lägg viktigt innehåll ovanför vecket, sid 82.

• Gör sidorna enkla att skriva ut, sid 86.

• Gruppera menylänkar som hör samman, sid 129.

• Ge långa sidor en sid­inne­hålls­för­teck­ning , sid 230.

• Undvik att öppna nya fönster, sid 329.

• Formulera rubrikerna så att de är begripliga även när de läses fristående från den övriga texten, sid 95.

Tillgängligare utformning av formulär

• Gör tabbordningen logisk och förutsebar, sid 230.

• Knapptext bör inte göras som bild, sid 261.

• Etiketter och instruktioner, sid 268.

• När det blivit fel i formuläret, visa tydligt var och hjälp användaren göra rätt , sid 276.

• Koppla samman kontroll och felmeddelande, sid 277.

RIKTLINJE 13: Gör det lätt för användaren att navigera på webbplatsen

WCAG 13.1 Visa tydligt vart varje länk leder.

Motsvarande råd:

• Gör det tydligt vart länken leder, sid 115.

• Låt inte identiskt formulerade länkar leda olika, sid 116.

• Förvarna om att ett nytt fönster kommer att öppnas, och ge en tydlig väg tillbaka , sid 331.

WCAG 13.2 Tillhandahåll metadata för att lägga till semantisk information i sidor och webbplatser.

Motsvarande råd:

• Webbsidor bör innehålla metadata , sid 218.

• Beskriv sidans relationer till andra sidor, sid 220.

• Gör det tydligt hur delar och helhet hänger samman, sid 234.

• Koppla samman olika språkversioner i koden, sid 105.

WCAG 13.3 Tillhandahåll information om den aktuella webbplatsens uppläggning (till exempel en översikt eller innehållsförteckning ).

Motsvarande råd: Gör en innehållsförteckning, sid 149.

I samma anda: Synlig sökväg , sid 152.

WCAG 13.4 Använd navigeringsfunktioner på ett konsekvent sätt.

Motsvarande råd:

• Använd symboler på ett konsekvent sätt, sid 68.

• Besökaren skall kunna ta sig direkt till ingångssidan från alla sidor, via logotypen och en textlänk, sid 122.

WCAG 13.5 Tillhandahåll navigeringslister för att markera och ge tillgång till navigationsfunktioner och anvisningar.

Den här och nästa riktpunkt (WCAG 13.6) är litet oklart formulerade, men kokar ner till att det bör finnas ett sätt för användaren att hoppa direkt till navigationen, till sökningen och till själva innehållet på sidan.

Detta kan göras genom kortkommandon eller genom synliga eller dolda länkar i början av sidan.

Motsvarande råd:

• Viktiga funktioner och sidor skall kunna nås med kortkommandon , sid 231.

• Bygg in genvägar så att synskadade användare snabbt kan ta sig runt på sidan , sid 232.

WCAG 13.6 Gruppera relaterade länkar, identifiera gruppen (för användarprogrammen), och erbjud till dess att användarprogram har stöd för detta, ett sätt att gå förbi gruppen.

Stödet hos webbläsare för att gruppera och namnge länkar är obefintligt, så detta råd har ingen praktisk betydelse utöver det som sägs i WCAG 13.5.

WCAG 13.7 Om sökfunktioner tillhandahålls, skapa olika nivåer av sökningar för olika kompetenser och preferenser.

Att fullt ut leva upp till denna riktpunkt är mycket ambitiöst. Det kräver att webbplatsen är strukturerad utifrån språk- eller innehållsnivå, alternativt utifrån de preferenser användaren kan ha. Det är ytterligt få webbplatser som har möjlighet att klara det.

I samma anda:

Se Sök­ning, sid 203, för råd kring hur sökningen kan utformas. Speciellt viktiga för tillgängligheten är följande råd:

• Stavningskontrollera sökningen , sid 205.

• Sök även på synonymer, sid 205.

• Sökmotorn bör förstå böjningar, sid 206.

• Ge sammanhang åt sökträffarna, sid 210.

• Erbjud i första hand enkel sökning, sid 208.

• Visa träffarna uppdelat på avdelningar, sid 213.

WCAG 13.8 Tillhandahåll särskiljande information i början av rubriker, stycken, listor etc.

Motsvarande råd:

• Skriv det viktigaste först , sid 93.

• Sätt det särskiljande först i titeln, sid 221.

WCAG 13.9 Tillhandahåll information om samlingsdokument (det vill säga dokument som innehåller många olika sidor, eller dokument som innehåller olika typer av innehåll, till exempel multimediedokument).

Motsvarande råd:

• Beskriv sidans relationer till andra sidor, sid 220.

• Gör det tydligt hur delar och helhet hänger samman, sid 234.

WCAG 13.10 Tillhandahåll ett sätt att hoppa över bokstavsbilder.

Denna riktpunkt är tämligen överspelad. Att göra bilder med hjälp av HTML-text var möjligen något man höll på i webbens barndom men är nu sällsynt, och bör så förbli. Hellre än att hoppa förbi ASCII-bilder bör man helt hoppa över dem.

Motsvarande råd: Använd inte HTML-text som symboler, pilar eller bilder, sid 421.

I samma anda som riktlinje 13

Informationsdesign, sid 108, syftar till samma sak som denna riktlinje – att skapa en navigation som användaren kan förstå och med vars hjälp hon så småningom kan göra en karta över webbplatsen i sitt huvud.

Några av de råd som är särskilt relevanta för tillgängligheten:

• Ge webbplatsen ett sakregister, sid 151.

• Omantalet alternativ är fler än fem, försök hitta ett tema för navigationen, sid 159.

• Gör hellre flera renodlade navigationer än en samlad, sid 159.

• Om det inte är självklart var något hör hemma, ge det flera placeringar , sid 162.

• Använd inte metaforer för att organisera webbplatsen, sid 182.

• Gör hellre trädet brett än djupt, sid 196.

• Led inte användaren runt i cirkel, sid 198.

• Låt bakåtknappen fungera, sid 202.

• Sidtitel , sid 220.

• Webb­adress , sid 223.

• Väg värdet av nytt material mot den ökade komplexitet det orsakar , sid 237.

• Ta inte bort webbläsarens kontroller, sid 332.

RIKTLINJE 14: Gör sidorna tydliga och enkla

Detta är en av de få delar av WCAG som inte primärt handlar om de synskadade utan om den största gruppen funktionshindrade, de med kognitiva handikapp.

WCAG 14.1 Använd ett språk som är så enkelt och tydligt som möjligt, lämpligt för innehållet på den aktuella webbplatsen.

Motsvarande råd:

• Skriv så enkelt som möjligt, sid 92.

• Använd en stilguide , sid 93.

• Språkgranska texter , sid 94.

• Kontrollera stavning och grammatik, sid 94.

WCAG 14.2 Komplettera text med grafik- eller ljudpresentation när de underlättar förståelsen av sidan.

Att förklara saker på andra sätt än bara text är ett utmärkt (men ambitiöst) mål. Bilder, och i ännu högre grad animationer, filmer och interaktiva illustrationer, kan vara ett suveränt medium för att förklara hur saker fungerar och hänger samman.

Motsvarande råd:

• Använd bilder , sid 57.

• Använd multimedia för att förklara, förmedla och roa, sid 74.

WCAG 14.3 Använd en layout och presentationsstil som är konsistent över sidorna.

• Låt formgivningen hålla samman webbplatsen , sid 46.

I samma anda som riktlinje 14

• Var relevant, undvik dekorationer, sid 45.

• Spaltbredd , sid 53.

• Lämna luft till höger och vänster om texten, sid 55.

• Tilltal , sid 89.

• Formulera rubrikerna så att de är begripliga även när de läses fristående från den övriga texten, sid 95.

• Skrivråd , sid 95.

• Översätt inte bara texten utan anpassa även innehållet, sid 105.

• Skriv information och instruktioner på lättläst och gärna även på andra språk , sid 106.

• Presentera innehållet i flera olika former anpassade till olika användargrupper , sid 375.

• Använd PDF som en tillgängligare alternativform av HTML-sidor , sid 440.