Arrive Inter Media | Tillbaka

Riktlinjer för utformning av innehåll på webben, version 1.0

W3C Rekommendation 5 Maj 1999

Sammanfattning

Detta dokuments status

1. Introduktion

2. Huvudteman för utformning av tillgängligt innehåll

3. Hur riktlinjerna är upplagda

4. Prioriteter

5. Att följa riktlinjerna

 

Innehållsförteckning

Ytterligare bilaga: Checklista för Web Content Accessibility Guidelines 1.0 (på engelska). En tabellversion för utskrift (på engelska) finns också tillgänglig.

1. Introduktion

Den som är obekant med tillgänglighetsfrågor vid utformning av webbsidor kan försöka sätta sig in i situationen för en användare vars värld är annorlunda än den egna:

Den som utvecklar innehåll för webben måste betänka dessa olika situationer under utformningen av webbsidor. Det kan finnas ett flertal situationer som påverkar webbanvändningen, men varje valmöjlighet som förbättrar tillgängligheten för webbsidorna är till nytta för flera olika funktionshindrade grupper, och för alla webbanvändare som helhet. Genom att exempelvis använda formatmallar (style sheets) för att styra typsnittsstorleken och göra FONT-elementet onödigt, kommer författare av HTML-sidor att få mer kontroll över hur deras sidor ser ut, de kommer att göra sidorna tillgängligare för den som har dålig syn, och genom att använda samma formatmallar för alla sidor kommer nedhämtningstiden från nätet att förkortas drastiskt.

Dessa riktlinjer behandlar tillgänglighetsfrågor för människor med funktionshinder, och tillhandahåller lösningar för utformningen av webbsidor som är tillgängliga. De diskuterar olika scenarier (som typsnittsexemplet ovan) som kan innebära problem för användare med funktionshinder. Den första riktlinjen förklarar hur användare kan göra bilder mer tillgängliga. En del användare kanske inte kan se bilder, andra kan använda textläsare som inte har stöd för bildvisning, och somliga kanske har stängt av bildvisningen i sin webbläsare (exempelvis eftersom de tycker att det tar för lång tid att ladda ner bilder). Dessa riktlinjer ger inte rådet att undvika bilder som ett sätt att förbättra tillgängligheten. I stället förklarar de att man genom att tillhandahålla ett textalternativ till bilden gör den tillgänglig.

Hur kan ett textalernativ göra en bild tillgänglig? Nyckeln ligger i begreppet "textalternativ":

Observera att förutom att de är till fördel för användare med funktionshinder kan textalternativ vara till fördel för alla användare, eftersom det blir lättare att hitta sidor när sökrobotar kan använda textalternativet i sitt sidindex.

Innehållsutvecklaren måste tillhandahålla textalternativ till bilderna. Men det är användarprogrammets ansvar (till exempel webbläsare och hjälpmedel som skärmläsare, braille-displayer, etc.) att presentera informationen för användaren.

Icke-textuella alternativtill text (till exempel ikoner, förinspelade röstmeddelanden, eller videoklipp med en person som tecknar samma meddelande) kan göra dokumenten mer tillängliga gör användare som har svårigheter att ta till sig skriven text, inklusive många användare med inlärningssvårigheter, kognitiva funktionshinder, och dövhet. Icke-textuella alternativ kan också hjälpa icke-läsare. En röstbeskrivning är ett exempel på ett icke-textuellt alternativ till visuell information. En ljudrepresentation av en multimediapresentations visuella del underlättar förståelsen för den som inte kan uppfatta den visuella informationen.

2. Huvudteman för utformning av tillgängligt innehåll

Dessa riktlinjer har två huvudteman: Gör mjuka övergångar möjliga, och gör det lättare att förstå och hitta i innehållet.

2.1 Gör mjuka övergångar möjliga

Genom att följa dessa riktlinjer kan innehållsutvecklare skapa webbsidor som mjukt kan övergå i andra presentationsformer. Sidor som mjukt kan övergå i andra presentationsformer förblir tillgängliga trots de begränsningar som beskrevs i introduktionen, inklusive fysiska funktionshinder, svårigheter att uppfatta dem, svårigheter att förstå dem, problem i omgivningen, och tekniska hinder. Här är några nyckelbegrepp för att utforma sidor som kan övergå mjukt i andra:

Hur du skapar mjuka övergångar diskuteras vidare i riktlinjerna 1 till 11.

2.2 Gör det lättare att förstå och hitta i innehållet

Innehållsutvecklare bör göra innehållet enkelt att förstå och lätt att hitta i. Detta innebär att göra språket enkelt och lättbegripligt, men också att tillhandahålla begripliga mekanismer för att navigera inom och mellan sidorna. Tillhandahåll verktyg för att navigera och hjälpa användarna att orientera sig på sidorna. Det maximerar tillgänglighet och användbarhet. Kom ihåg att alla användare inte har nytta av visuella ledtrådar som klickbara bilder, skärmproportionerliga rullningslister, ramar sida vid sida, eller grafik som kan hjälpa användare med god syn att hitta i grafiska webbläsare. Användare förlorar också den kontextuella informationen när de bara kan se en del av sidan, antingen för att de bara kan läsa ett ord i taget (om de exempelvis använder röstsyntes eller en brailleläsare), eller bara en del åt gången (exempelvis om de har en liten skärm, eller en förstorande skärm). Utan navigationsinformation kan användarna kanske inte förstå stora tabeller, långa listor, menyer, etc.

Hur du skall göra innehållet lätt att förstå och navigera diskuteras framför allt i riktlinjerna 12 till 14.

3. Hur riktlinjerna är upplagda

Detta dokument innehåller fjorton riktlinjer, generella principer för tillgänglig webbdesign. Varje riktlinje innehåller:

I riktpunkterna för varje riktlinje förklaras hur riktlinjen skall användas i ett antal typiska scenarion för webbutvecklare. Varje definition innehåller:

Varje riktpunkt är avsedd att vara så specifik att den kan användas som underlag för en revision av en sida eller webb, och visa att riktpunkten har följts.

3.1 Om det här dokumentet

I det här dokumentet använder vi följande skrivregler:

4. Prioriteter

Varje riktpunkt har en prioritetsnivå som den har tilldelats av arbetsgruppen i W3C, och som bestäms av den påverkan riktlinjen har på tillgängligheten.

[Prioritet 1]
Innehållsutvecklare måste följa denna riktpunkt. Annars kommer en eller flera grupper att finna det omöjligt att använda informationen i dokumentet. Att följa denna riktpunkt är ett grundkrav för att somliga grupper skall kunna använda webbsidor. Med svenskt språkbruk är detta ett SKALL-krav.
[Prioritet 2]
Innehållsutvecklare bör följa denna riktpunkt. Annars kommer en eller flera grupper av användare att finna det svårt att ta till sig informationen i dokumentet. Att följa denna riktpunkt kommer att avlägsna avsevärda problem med tillgängligheten för webbsidorna. Med svenskt språkbruk är detta ett BÖR-krav.
[Prioritet 3]
En innehållsutvecklare kan följa denna riktpunkt. Annars kan en eller flera grupper finna det svårt att ta till sig informationen i dokumentet. Att följa denna riktpunkt kommer att förbättra tillgängligheten för webbsidorna.

Vissa riktpunkt anger en prioritet som kan ändras under vissa (angivna) förutsättningar.

5. Att följa riktlinjerna

Denna sektion anger tre nivåer som dokument som följer riktlinjerna kan uppfylla:

Observera. De nivåer som dokumentet kan uppfylla har skrivits ut i text, så de kan läsas ut av en skärmläsare.

När man anger vilken nivå dokumentet uppfyller, är det webbens ägare som deklarerar vilken nivå som uppfylls. Deklarationen skall innehålla ett antal specificerade utsagor och göras enligt en av två angivna former.

Deklaration enligt Form 1: Ange:

Exempel på deklaration enligt Form 1:

Denna sida uppfyller W3C:s "Riktlinjer för utformning av innehåll på webben, version 1.0", som finns tillgängliga på http://www.w3.org/TR/1999/WAI-WEBCONTENT-SE-19990505, nivå Dubbel-A.

Deklaration enligt Form 2: På varje sida som du vill ange följer riktlinjerna skall endera av tre ikoner som tillhandahålls av W3C, tillsammans med en länk från ikonen till den korrekta W3C-förklaringen av nivån. Information om ikonerna och hur du lägger in dem på dina sidor återfinns på [WCAG-ICONS] (på engelska).

6. Riktlinjer för utformning av innehåll på webben

Riktlinje 1. Tillhandahåll motsvarande, alternativ information för auditoriskt (röst och ljud) och visuellt innehåll.

Nästa riktlinje: 2 Föregående riktlinje: 14 Till innehållsförteckningen

Tillhandahåll innehåll som, när det presenteras för användaren, uppfyller samma funktion eller syfte som det auditoriska eller visuella innehållet.

Trots att en del människor inte kan använda bilder, filmklipp, ljud, scriptprogram och liknande direkt, kan de fortfarande använda webbsidor som innehåller motsvarande information som den visuella eller audioriska presentationen. Den motsvarande informationen måste uppfylla samma syften som det visuella eller auditoriska innehållet. Sålunda skall ett textalternativ till en bild av en uppåtpil som länkar till en innehållsförteckning ha texten "Gå till innehållsförteckningen". I en del fall kan det också vara värt att beskriva utseendet på det visuella innehållet (exempelvis i komplexa diagram), eller för ljudklipp (till exempel om de skall användas i utbildning).

Denna riktlinje understryker vikten av att tillhandahålla textalternativ till icke-textuellt innehåll (bilder, förinspelat ljud, videoklipp). Textalternativens styrka ligger i deras förmåga att presenteras för användaren på sätt som är tillgängliga för användare med olika funktionshinder som använder ett antal olika presentationstekniker. Text kan presenteras som syntetiskt tal och på brailleläsare, och kan presenteras visuellt (i olika storlekar) på bildskärmar eller på papper. Syntetiskt tal är helt nödvändigt för personers om är blinda, och en fördel för många av de användare som har läsproblem beroende på svårigheter att förstå, svårigheter att lära sig, eller dövhet. Braille är nödvändigt för personer som är dövblinda, lika väl som för många personer som är blinda. Text som visas visuellt är en fördel för döva användare, lika väl som för de flesta webbanvändare.

Att tillhandahålla icke-textuella motsvarigheter (till exempel bilder, videoklipp, och förinspelat ljud) till en text är också en fördel för många användare, speciellt de som inte kan läsa eller som har svårigheter att läsa. I filmklipp eller visuella presentationer behöver kroppsspråk eller andra visuella ledtrådar inte åtföljas av tillräcklig ljudinformation för att tillhandahålla samma information. Om inte en verbal beskrivning av den visuella informationen tillhandahålls, kommer personer som inte kan se det visuella innehållet (tillfälligt eller permanent) att uppfatta det.

Riktpunkter:

1.1Se 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:ar), scriptprogram (applets) och andra program, bokstavsbilder ("ascii-art"), ramar (frames), bilder som används som listmarkörer, bilder som används som platshållare, grafiska knappar, ljud (som spelas utan användarens inblandning), ljudfiler, ljudspår till video- och filmklipp, och video- och filmklipp. [Prioritet 1]
Detta innebär exempelvis att göra följande i HTML:
  • Använd "alt" tillsammans med IMG, INPUT, och APPLET-elementen, eller tillhandahåll ett textalternativ i innehållet i OBJECT- och APPLET-elementen.
  • Komplext innehåll (till exempel diagram) där "alt"-texten inte kan tillhandahålla en fullständig beskrivning av innehållet, bör du tillhandahålla en ytterligare beskrivning, till exempel genom att använda "longdesc" med IMG eller FRAME, en länk inuti OBJECT-elementet, eller en länk till en beskrivning.
  • För klickbara bilder, använd antingen "alt"-attributet med AREA, eller använd MAP-elementet med A-elementet (och annan text) som innehåll.

Se också riktpunkt 9.1 och riktpunkt 13.10.

Tekniska lösningar för riktpunkt 1.1
1.2Tillhandahåll extra textlänkar för varje aktivt område i en serverbaserad klickbar bild. [Prioritet 1]
Se också riktpunkt 1.5 och riktpunkt 9.1.
Tekniska lösningar för riktpunkt 1.2
1.3Tills användarprogram kan läsa ut innehållet i ett textalternativ till ett visuell presentation, skall du tillhandahålla en ljudbeskrivning av den viktiga informationen i den visuella delen av en multimediapresentation. [Prioritet 1]
Synkronisera ljudbeskrivningen med ljudspåret enligt riktpunkt 1.4. Se också riktpunkt 1.1 för information om textalternativ till visuell information.
Tekniska lösningar för riktpunkt 1.3
1.4För varje tidsstyrd multimediapresentation (exempelvis en film eller animering), synkronisera de alternativa presentationerna (till exempel textremsa eller ljudbeskrivning) med varandra. [Prioritet 1]
Tekniska lösningar för riktpunkt 1.4
1.5Tills användarprogram kan läsa ut textalternativ till en klickbar bild, tillhandahåll extra textalternativ för varje aktivt område i en klickbar bild. [Prioritet 3]
Se också riktpunkt 1.2 och riktpunkt 9.1.
Tekniska lösningar för riktpunkt 1.5

Riktlinje 2. Förlita dig icke på färg allenast.

Nästa riktlinje: 3 Föregående riktlinje: 1 Till innehållsförteckningen

Se till att text och bilder är begripliga när de visas utan färg.

Om endast färg används för att överföra information kan användare som inte kan skilja mellan olika färger och användare med utrustningar som inte har färgskärmar, eller icke-visuella skärmar, inte se informationen. När förgrund och bakgrund har färgtoner som ligger nära varandra, kommer de inte att ha tillräckligt hög kontrast när de visas på en monokrom bildskärm, eller ses av användare som är färgblinda.

Riktpunkter:

2.1Se till att all information som visas enbart med färg också kan uppfattas utan färg, exempelvis genom placeringen i dokumentet eller med hjälp av HTML-kodningen. [Prioritet 1]
Tekniska lösningar för riktpunkt 2.1
2.2Se 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. [Prioritet 2 för bilder, Prioritet 3 för text].
Tekniska lösningar för riktpunkt 2.2

Riktlinje 3. Använd kodning och formatmallar (style sheets) och gör det rätt.

Nästa riktlinje: 4 Föregående riktlinje: 2 Till innehållsförteckningen

Koda dokumenten med rätt strukturelement. Styr presentationen med formatmallar (style sheets) snarare än med presentationselement och -attribut.

Om kodning används fel -- på sätt som inte är specificerade -- kommer det att förorsaka problem med tillgängligheten. Felaktig användning av kodning (till exempel att använda tabeller för layout, eller <H1>-koden för att ändra typsnittsstorleken) gör det svårare för användare med specialiserade program att förstå hur en sida är organiserad och framför allt att navigera i den. Dessutom förorsakar det problem med navigation och andra presentationsformat om du använder presentationskoder för att förmedla sådant som är strukturinformation (till exempel genom att göra en "tabell" med HTML:s PRE-element). Se vidare diskussionen om skillnaden mellan innehåll, struktur, och presentation).

Innehållsutvecklare kan vara frestade att använda (eller missbruka) kodningar som kan ge dem det önskade resultatet på äldre webbläsare. De skall då vara medvetna att detta kan förorsaka problem med tillgängligheten och måste noga väga formatteringseffekten mot det faktum att dokumentet blir otillgängligt för en del användare.

Den andra ytterligheten är att innehållsutvecklare måste avstå från formatkodningar därför att en webbläsare eller stödteknik inte kan bearbeta kodningen. Exempelvis är det korrekt att använda TABLE-elementet i HTML för att koda tabellinformation trots att en del äldre skärmläsare inte kan hantera text i kolumner korrekt (se riktpunkt 10.3). Använd TABLE på riktigt sätt och gör tabeller som kan övergå mjukt till text (se riktlinje 5), vilket gör det möjligt för programvaror att återge tabeller som något annat än ett tvådimensionellt galler.

Riktpunkter:

3.1När ett lämpligt kodningsspråk finns tillgängligt, använd kodningen snarare än bilder för att överföra information. [Prioritet 2]
Detta innebär exempelvis att när matematiska ekvationer presenteras, bör MathML användas, och formatmallar ("style sheets") för att formattera texten och styra layouten. Undvik också att använda bilder för att representera text. Använd text och formatmallar i stället. Se också riktlinje 6 och riktlinje 11.
Tekniska lösningar för riktpunkt 3.1
3.2Skapa dokument som kan valideras i formella programmeringskodningssystem. [Prioritet 2]
Detta innebär exempelvis att i början av dokumentet lägga in en dokumenttypsbeskrivning (DTD) som refererar till en tidigare publicerad DTD (till exempel DTD:n för "strict HTML 4.0").
Tekniska lösningar för riktpunkt 3.2
3.3Använd formatmallar ("style sheets") för att styra layout och presentation. [Prioritet 2]
Använd CSS 'font'-kod i stället för HTML:s FONT-element för att styra typsnitten.
Tekniska lösningar för riktpunkt 3.3
3.4Använd relativa snarare än absoluta enheter i kodningens attributvärden (attribute values) och i formatmallarnas egenskapsvärden (property values). [Prioritet 2]
Ett exempel är att använda 'em' eller en procentsats för att ange typsnittsstorlekar och marginaler i CSS, i stället för 'pt' eller 'mm', som är absoluta måttenheter. Om du måste använda absoluta måttenheter, kontrollera att innehållet är tillgängligt genom att validera det (se avdelningen om validering).
Tekniska lösningar för riktpunkt 3.4
3.5Använd element i <HEAD>-delen av dokumentet för att ange dokumentstrukturen och använd dem som specificerat. [Prioritet 2]
Exempelvis: I HTML, använd H2 för att ange en undersektion till H1. Använd inte rubrikmarkeringar för att skapa typsnittseffekter.
Tekniska lösningar för riktpunkt 3.5
3.6Koda listor och listposter rätt. [Prioritet 2]
Till exempel: I HTML, se till att listor som markeras med OL, UL och DL lagras på rätt sätt i varandra.
Tekniska lösningar för riktpunkt 3.6
3.7Koda citat. Använd inte citatkodningen (QUOTE) för att skapa formatteringseffekter, som indrag. [Prioritet 2]
I HTML, använd Q och BLOCKQUOTE för att markera kortare och längre citat.
Tekniska lösningar för riktpunkt 3.7

Riktlinje 4. Se till att det är tydligt vilket språk som används i texten.

Nästa riktlinje: 5 Föregående riktlinje: 3 Till innehållsförteckningen

Använd kodning som förenklar uttal och tolkning av förkortad eller utländsk text.

När innehållsutvecklare anger ändringar i det språk som används i ett dokument kan talsyntesprogram och brailleläsare automatiskt gå över till det nya språket, vilket gör dokumentet tillgängligt för grupper som är flerspråkiga. Innehållsutvecklare bör alltid ange vilket naturligt språk som huvuddelen av dokumentet använder (i kodningen eller i HTTP-headern). Innehållsutvecklare bör också ange vad förkortningar står för.

Förutom att detta hjälper stödtekniker för funktionshindrade, medger detta att sökmotorer kan hitta nyckelord och identifiera dokument i ett angivet språk. Det ökar också läsbarheten på webben för alla användare, inklusive de som har svårt att lära sig, svårt att förstå, eller som är döva.

När förkortningar och byte av naturligt språk inte anges, kan de bli helt obegripliga när de läses av en maskin eller visas på en brailleläsare.

Riktpunkter:

4.1Ange tydligt när språket i ett dokument ändras, lika väl som i textalternativen (till exempel bildtexter). [Prioritet 1]
I HTML, använd "lang"-attributet. I XML, använd "xml:lang".
Tekniska lösningar för riktpunkt 4.1
4.2Ange alltid vad en förkortning innebär när den först förekommer. [Prioritet 3]
Använd "title"-attributet i  HTML och ABBR och ACRONYM-elementen. Att ange expansion i meddelandekroppen förbättrar också dokumentets tillgänglighet.
Tekniska lösningar för riktpunkt 4.2
4.3Ange det huvudsakliga språket i dokumentet. [Prioritet 3]
Sätt "lang"-attributet i HTML på det berörda HTML-elementet. I XML, använd "xml:lang". Webmasters och andra systemansvariga bör se till att konfigurera sina webbservrar så de använder HTTP:s mekanismer för innehållsförhandling ([RFC2068], sektion 14.13) så att klientprogram automatiskt kan få dokument på det språk som är inställt i användarens preferenser.
Tekniska lösningar för riktpunkt 4.3

Riktlinje 5. Skapa tabeller som mjukt kan omvandlas till text.

Nästa riktlinje: 6 Föregående riktlinje: 4 Till innehållsförteckningen

Se till att det finns tillräcklig kodning av tabellerna så att de kan omvandlas till löpande text av webbläsare som kan hantera detta.

Tabeller skall endast användas för att presentera information som verkligen är tabulär ("datatabeller"). Innehållsutvecklare skall undvika att använda dem för sidlayout ("layouttabeller"). Hur de än används, innebär tabeller som regel problem för användare av skärmläsare (se riktpunkt 10.3).

En del  användarprogram medger att användarna navigerar mellan cellerna i tabellen, och kan läsa tabellöverskrifter och annan information om cellerna i tabellen. Om de inte kodas på rätt sätt, kommer dessa tabeller inte att ge användarprogrammen tillräcklig information. (se också riktlinje 3.)

De följande riktpunkterna är direkt till fördel för användare som läser en tabell med någon form av ljudpresentation (till exempel en skärmläsare eller en bildator) eller som bara kan se en del av sidan åt gången (exempelvis blinda användare som använder en skärmläsare eller en brailleläsare, eller andra användare med små bildskärmar, etc).

Riktpunkter:

5.1I datatabeller, ange rad- och kolumnöverskrifter. [Prioritet 1]
Använd TD för att ange rader, och TH för att ange tabellöverskrifter i HTML.
Tekniska lösningar för riktpunkt 5.1
5.2I datatabeller som har två eller flera logiska nivåer med rad- och kolumnöverskrifter, koda så att dataceller och överskriftsceller hör samman. [Prioritet 1]
I HTML, använd THEAD, TFOOT, och TBODY för att gruppera rader, och COL och COLGROUP för att gruppera kolumner. Använd "axis", "scope", och "headers"-attributen för att beskriva mer komplexa relationer mellan data.
Tekniska lösningar för riktpunkt 5.2
5.3Använd inte tabeller för layout om inte tabellen kan läsas ut rad för rad. Ifall tabellen måste ses i kolumner och celler, tillhandahåll ett alternativ (vilket kan vara en lineär version). [Prioritet 2]
Observera. När användarprogram får stöd för positionsangivelser i formatmallar ("style sheets"), bör detta användas, och tabeller bör inte användas för layout. Se också riktpunkt 3.3.
Tekniska lösningar för riktpunkt 5.3
5.4Om en tabell används för layout, använd inte strukturkoder för visuell formattering. [Prioritet 2]
Använd exempelvis inte TH-elementet i HTML för att innehållet i en cell som inte är en tabellöverskrift skall visas centrerat och i fetstil.
Tekniska lösningar för riktpunkt 5.4
5.5Tillhandahåll sammanfattningar av tabeller. [Prioritet 3]
I HTML, använd exempelvis "summary"-attributet till TABLE-elementet.
Tekniska lösningar för riktpunkt 5.5
5.6Tillhandahåll förkortningar för tabellöverskrifter och rad- och kolumnhuvuden. [Prioritet 3]
Använd "abbr"-attributet till TH-elementet i HTML.
Tekniska lösningar för riktpunkt 5.6

Se också riktpunkt 10.3.

Riktlinje 6. Se till att sidor som använder nya tekniker kan övergå mjukt till presentation med äldre teknik.

Nästa riktlinje: 7 Föregående riktlinje: 5 Till innehållsförteckningen

Se till att sidor är tillgängliga även när stöd inte finns för nya tekniker, eller när ny presentation är avstängd.

Som innehållsutvecklare är du naturligtvis välkommen att använda ny teknik för att lösa de problem som den existerande tekniken för med sig, men du måste ändå vara medveten om hur du skall göra för att dina sidor skall fungera med äldre webbläsare och för dem som har funktioner avstängda eller inte kan uppfatta dem.

Riktpunkter:

6.1Organisera dina dokument så de kan läsas utan formatmallar ("style sheets"). När ett HTML-dokument visas på skärmen utan att formatmallen används, skall det fortfarande vara möjligt att läsa dokumentet. [Prioritet 1]
Innehåll som är logiskt organiserat kommer att visas i en begriplig ordning även när formatmallar är avslagna eller inte stöds i webbläsaren.
Tekniska lösningar för riktpunkt 6.1
6.2Se till att textalternativen till dynamiskt skapat innehåll uppdateras när det dynamiska innehållet ändras. [Prioritet 1]
Tekniska lösningar för riktpunkt 6.2
6.3Se till att sidorna är användbara när scriptprogram, kortprogram ("applets"), och andra program är frånslagna eller inte stöds i webbläsaren. Om det är möjligt, tillhandahåll motsvarande information på en alternativ, tillgänglig sida. [Prioritet 1]
Se till exempel till att länkar som startar scriptprogram fungerar även när scriptprogramfunktionen är avslagen eller inte stöds (dvs: Använd inte "javascript:" som länkens mål). Om det inte är möjligt att göra sidorna användbara utan scriptprogram, tillhandahåll ett textalternativ med NOSCRIPT-elementet, eller använd ett scriptprogram i servern i stället för klientdatorn, eller tillhandahåll en tillgänglig sida enligt riktpunkt 11.4. Se också riktlinje 1.
Tekniska lösningar för riktpunkt 6.3
6.4För scriptprogram och applet-program, se till att de händelsehanterare (event handlers) som används är oberoende av vilken datortyp som används. [Prioritet 2]
Se definitionen av datortypoberoende.
Tekniska lösningar för riktpunkt 6.4
6.5Se till att dynamiskt genererat innehåll är tillgängligt, eller tillhandahåll en alternativ presentation eller -sida. [Prioritet 2]
I HTML, till exempel, använd NOFRAMES i slutet på varje rampaket (frameset). För en del program kan scriptprogram i servern vara mer tillgängliga än scriptprogram på klientdatorn.
Tekniska lösningar för riktpunkt 6.5

Se också riktpunkt 11.4.

Riktlinje 7. Se till att användaren kan styra tidskritiska ändringar av innehållet själv.

Nästa riktlinje: 8 Föregående riktlinje: 6 Till innehållsförteckningen

Se till att rörliga, blinkande, rullande, eller självuppdaterande objekt och sidor kan pauseras eller avbrytas.

En del människor med synsvårigheter eller svårigheter att uppfatta kan inte läsa text som rör sig. Rörelse kan också vara en distraktion som gör att man missar resten av sidan. Skärmläsare kan inte heller läsa rörlig text. Den som har svårigheter att röra sig kan också ha problem att röra sig snabbt nog för att interagera med rörliga ikoner och liknande.

Observera. Alla de följande riktpunkterna innebär att innehållsutvecklaren har ett ansvar för att de fungerar, tills användarprogram tillhandahåller tillräckliga mekanismer för att styra funktioner i  programmet.

Riktpunkter:

7.1 Tills användarprogram medger användaren att styra skärmflimmer, undvik funktioner som får skärmen att flimra. [Prioritet 1]
Observera. Människor med ljusutlöst epilepsi kan få anfall när de utsätts för stroboskopiskt ljus eller flimmer i frekvenserna från fyra till 59 pulser per sekund (Hz), med en toppnivå på 20 pulser per sekund, lika väl som snabba ändringar från mörker till ljus.
Tekniska lösningar för riktpunkt 7.1
7.2 Tills användarprogram medger att användaren kan styra blinkfrekvensen, undvik funktioner som får innehåll att blinka (exempelvis som förändrar presentationen regelbundet, till exempel genom att stänga av och slå på den). [Prioritet 2]
Tekniska lösningar för riktpunkt 7.2
7.3 Tills användarprogram medger att användaren kan stänga av rörelser i innehållet, undvik detta. [Prioritet 2]
När en sida innehåller rörliga eller animerade element, se till att det finns en mekanism inom det scriptprogram eller appletprogram som styr rörelsen som medger att användaren kan stänga av rörelser eller bildbyten. Använd formatmallar ("style sheets") tillsammans med scriptprogrammen, vilket underlättar för användaren att stänga av dem. Se också riktlinje 8.
Tekniska lösningar för riktpunkt 7.3
7.4 Tills användarprogrammen tillhandahåller möjligheter att avbryta automatiska uppdateringar, använd inte sidor som uppdaterar sig automatiskt. [Prioritet 2]
I HTML, till exempel, använd inte "HTTP-EQUIV=refresh" för att sidor skall uppdateras automatiskt, tills användarprogrammen medger att användaren kan stänga av funktionen.
Tekniska lösningar för riktpunkt 7.4
7.5 Tills användaragenter medger att användaren stänger av automatisk omdirigering, använd inte kodningar som styr om sidor automatiskt. Använd i stället servern för att göra omdirigeringar av innehållet (redirects). [Prioritet 2]
Tekniska lösningar för riktpunkt 7.5

Observera. BLINK och MARQUEE-elementen finns inte definierade i någon specifikation från W3C, och skall inte användas. Se också riktlinje 11.

Guideline 8. Se till att användargränssnittet för skärmobjekt är lika tillgängliga som webbsidorna.

Nästa riktlinje: 9 Föregående riktlinje: 7 Till innehållsförteckningen

Se till att användargränssnittet för objekt som du skapar inom ramen för dina webbsidor också föjer principerna för tillgänglighet, exempelvis genom att inte vara knutna till en viss typ av funktion, tangentbord, etc.

När ett skärmobjekt som presenteras inom ramen för dina webbsidor har sitt eget användargränssnitt, måste detta - lika väl som användargränssnittet för webbläsaren själv - vara tillgängligt för människor med funktionshinder. Om användargränssnittet till skärmobjektet inte kan göras tillgängligt, tillhandahåll en alternativ, tillgänglig representation.

Observera. För mer information om tillgängliga användargränssnitt, se W3C:s User Agent Accessibility Guidelines ([WAI-USERAGENT]) och W3C:s Authoring Tool Accessibility Guidelines ([WAI-AUTOOL]).

Riktpunkt:

8.1Se till att program, som scriptprogram och applet-program, är tillgängliga och kan användas med stödtekniker för funktionshindrade [ Prioritet 1om funktionen är viktig för förståelsen av innehållet och inte presenteras på annan plats, annars Prioritet 2.]
Se också riktlinje 6.
Tekniska lösningar för riktpunkt 8.1

Riktlinje 9. Utforma för oberoende av presentationsutrustningen.

Nästa riktlinje: 10 Föregående riktlinje: 8 Till innehållsförteckningen

Se till att funktioner som aktiverar sidelement fungerar med olika typer av pekdon, tangentbord etc.

Utrustningsoberoende åtkomst till information innebär att användaren kan interagera med användarprogrammet eller dokumentet med det pekdon eller tangentbord han eller hon valt. Om en typ av styrelement bara kan aktiveras via en speciell mus eller annat pekodon, kommer den som inte kan se, som bara har röststyrning, eller bara ett tangentbord, eller någon som använder ett annat pekdon, inte att kunna använda formuläret.

Observera. Att ange textalternativ till klickbara bilder och bilder som används som länkmarkeringar gör det möjligt för användare att interagera med dem utan pekdon. Se också riktlinje 1.

Generellt sett är sidor där användaren matar in information tillgängliga för den som använder röstinmatning eller som bara har ett textgränssnitt.

Riktpunkter:

9.1Tillhandahåll klickbara bilder i klientdatorn i stället för klickbara bilder i servern, förutom i fall då de aktiva regionerna inte kan definieras som geometriska former. [Prioritet 1]
Se också riktpunkt 1.1, riktpunkt 1.2, and riktpunkt 1.5.
Tekniska lösningar för riktpunkt 9.1
9.2Se till att alla element som har egna användargränssnitt kan användas oberoende av användarens utrustning. [Prioritet 2]
Se också definitionen av utrustningsoberoende.
Se också riktlinje 8.
Tekniska lösningar för riktpunkt 9.2
9.3Ange logiska händelsehanterare i stället för utrustningsberoende händelsehanterare i scriptprogram. [Prioritet 2]
Tekniska lösningar för riktpunkt 9.3
9.4Skapa en logisk ordning i länkar, formulär, och objekt, så användaren kan stega mellan dem. [Prioritet 3]
I HTML, skapa en ordning som kan stegas igenom med tabuleringstangenten genom att använda "tabindex"-attributet, eller utforma sidan logiskt.
Tekniska lösningar för riktpunkt 9.4
9.5Använd snabbvalstangenter för viktiga länkar (inklusive länkar i klickbara bilder), formulärknappar, och grupper av styrelement i formulär. [Prioritet 3]
I HTML, exempelvis, ange snabbvalstangenter med hjälp av "accesskey"-attributet. Om du översätter ett dokument, glöm inte att också översätta "accesskey"-attributen i HTML-koden.
Tekniska lösningar för riktpunkt 9.5

Riktlinje 10. Använd interimslösningar.

Nästa riktlinje: 11 Föregående riktlinje: 9 Till innehållsförteckningen

Använd interimslösningar för att öka tillgängligheten, så att stödtekniker för funktionshindrade, och äldre webbläsare, kan fungera korrekt.

Äldre webbläsare (version 2 och tidigare) tillåter inte användare att gå till tomma redigeringsrutor. Äldre skärmläsare läser listor av länkar som en enda länk. Dessa aktiva element är därför svårtillgängliga, eller till och med omöjliga att använda. Att ändra det aktiva fönstret, eller att öppna nya fönster kan också vara mycket störande för användare som inte kan se att detta händer.

Observera. De följande riktpunkterna gäller tills användarprogram (inklusive stödtekniker) kan hantera dessa problem. Dessa riktpunkter är interimistiska, vilket innebär att W3C:s arbetsgrupp Web Content Guidelines betraktar dem som giltiga och nödvändiga när detta dokument ges ut. Arbetsgruppen anser emellertid inte att dessa riktpunkter kommer att vara nödvändiga i framtiden, när webbtekniken innefattar de förutsedda funktionerna och möjligheterna.

Riktpunkter:

10.1 Tills användarprogram medger att användaren slår av funktioner som automatiskt öppnar fönster från det aktiva fönstret, som förorsakar menyer att öppnas automatiskt, och som ändrar det aktiva fönstret utan att informera användaren. [Prioritet 2]
I HTML, undvik att använda ett ramsystem vars länkmål är ett nytt fönster.
Tekniska lösningar för riktpunkt 10.1
10.2 Tills användarprogram ger stöd för uttryckliga associationer mellan etiketter och formulärstyrelement, se till att etiketten är korrekt placerad i formulär med implicit associerade etiketter. [Prioritet 2]
Etiketten måste omedelbart föregå dess styrelement på samma rad (vilket medger mer än ett styrelement - etikettpar per rad), eller endast en etikett och ett styrelement per rad i raden före styrelementet. Se också riktpunkt 12.4.
Tekniska lösningar för riktpunkt 10.2
10.3 Tills användaragenter (inklusive stödtekniker för funktionshindrade) återger textkolumner (sida vid sida) korrekt, ange ett linjärt alternativ (på den aktuella sidan, eller någon annan sida) för alla tabeller som anger text i parallella, radbrutna kolumner. [Prioritet 3]
Observera. Se definitionen av en lineariserad tabell. Denna riktpunkt är till hjälp för användare med användarprogram (som exempelvis skärmläsare) som inte kan hantera textblock som presenteras i kolumner; denna riktpunkt skall inte avskräcka innehållsutvecklare från att använda tabeller för att representera tabulär information i tabellform.
Tekniska lösningar för riktpunkt 10.3
10.4 Tills användarprogram kan hantera tomma styrelement korrekt, använd platshållare för att hantera tomma styrelement i redigeringsrutor och textområden. [Prioritet 3]
I HTML, gör detta för TEXTAREA och INPUT.
Tekniska lösningar för riktpunkt 10.4
10.5 Tills användarprogram (inklusive stödtekniker för funktionshindrade), se till att näraliggande länkar visas tydligt, inklusive icke-länkade, utskrivbara tecken (som omges av mellanslag) mellan näraliggande länkar. [Prioritet 3]
Tekniska lösningar för riktpunkt 10.5

Riktlinje 11. Använd W3C:s tekniker och riktlinjer.

Nästa riktlinje: 12 Föregående riktlinje: 10 Till innehållsförteckningen

Använd W3C:s tekniker (som de är specificerade), och följ riktlinjerna för tillgänglig information. Där du inte kan använda teknik från W3C, eller där användningen av det skulle innebära att materialet inte kan gå över mjukt till andra format, gör en alternativ version av innehållet som är tillgänglig.

De existerande riktlinjerna rekommenderar tekniker från W3C (tex. HTML, CSS) av flera skäl:

Många format som inte utvecklats inom ramen för W3C:s specifikationsprocess (tex. PDF, Shockwave, etc.) kräver att man använder ett tilläggsprogram eller en speciell applikation för att öppna dem. Dessa format kan inte öppnas i de vanligare användarprogrammen (inklusive stödtekniker för funktionshindrade). Att undvika format som inte är standardiserade av W3C, och som inte är innehåller icke-standardiserade funktioner (leverantörsspecifika element, attribut, egenskaper och funktioner) som tenderar att göra sidor mera tillgängliga för fler användare, allt eftersom variationen i programvara och maskiner ökar. När otillgängliga tekniker (leverantörsegna eller ej) måste användas, skall motsvarande, tillgängliga sidor tillhandahållas.

Även när W3C:s tekniker används måste de användas så att de följer riktlinjerna för att göra information tillgänglig. När ny teknik används, se till att det finns en mjuk övergång till äldre tekniker (se också riktlinje 6.).

Observera. Att konvertera dokument (från PDF, PostScript, RTF, etc.) till W3C:s kodningsspråk (HTML, XML) skapar inte automatiskt ett dokument som är tillgängligt för funktionshindrade. Alla sidor och dokument måste valideras för tillgänglighet och användbarhet efter en sådan konverteringsprocess (se avdelningen om validering). Om en sida inte går att omvandla enkelt, gör antingen om sidan eller gör om dess ursprungliga representation tills det antingen går att konvertera till en tillgänglig HTML-sida eller en textsida.

Riktpunkter:

11.1Använd W3C:s tekniker när de är tillgängliga och fungerar för det aktuella fallet. Använd den senaste versionen, när så är möjligt. [Prioritet 2]
Se listan på referenser för information om var W3C:s specifikationer kan återfinnas, och [WAI-UA-SUPPORT] för information om vilka användarprogram som stöder W3C:s tekniker.
Tekniska lösningar för riktpunkt 11.1
11.2Undvik nedgraderade funktioner i W3C:s tekniker . [Prioritet 2]
Exempelvis, i HTML, använd inte det nedgraderade FONT-elementet; använd formatmallar ("style sheets" i stället (till exempel "font"-funktionen i CSS).
Tekniska lösningar för riktpunkt 11.2
11.3Tillhandahåll information så användare kan få dokument i enlighet med sina preferenser (till exempel språk, innehållstyp, etc). [Prioritet 3]
Observera. Använd innehållsförhandling (content negotiation) där så är möjligt.
Tekniska lösningar för riktpunkt 11.3
11.4När du försökt så mycket du kan, men ä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. [Prioritet 1]
Tekniska lösningar för riktpunkt 11.4

Observera. Innehållsutvecklare bör endast använda alternativa sidor när andra lösningar är omöjliga, eftersom de generellt sett uppdateras mer sällan än de ursprungliga sidorna. En sida som innehåller gammal information kan vara lika frustrerande som en sida som är svårtillgänglig, eftersom informationen på sidan i bägge fall är oanvändbar. Att automatiskt generera alternativa sidor kan innebära att de uppdateras mer ofta, men innehållsutvecklare måste vara försiktiga så de sidor som genereras fortfarande har en begriplig innebörd, och att användare kan navigera genom webben genom att följa länkarna på primära sidor, alternativa sidor, eller bägge. Innan du gör en alternativ sida, tänk igenom den ursprungliga sidans utformning. Om du gör den mer tillgänglig kommer det sannolikt att göra den bättre för alla användare.

Riktlinje 12. Tillhandahåll information som ger användaren möjlighet att förstå var i dokumentet hon är.

Nästa riktlinje: 13 Föregående riktlinje: 11 Till innehållsförteckningen

Tillhandahåll information som ger användaren möjlighet att förstå var i dokumentet hon är, och förstå komplexa sidor och element.

Att gruppera element och tillhandahålla information som förklarar hur de förhåller sig till varandra är användbart för alla användare. Komplexa relationer mellan delar av en sida kan vara svåra för den som har svårt att se eller förstå att begripa.

Riktpunkter:

12.1Ge varje ram ("frame") en egen titel för att underlätta navigation mellan dem. [Prioritet 1]
Använd exempelvis "title"-attributet i HTML på FRAME-element.
Tekniska lösningar för riktpunkt 12.1
12.2Beskriv syftet med ramar och hur de förhåller sig till varandra, om detta inte är uppenbart av ramarnas titlar. [Prioritet 2]
Till exempel, i HTML, använd "longdesc" eller en beskrivande länkbeskrivning.
Tekniska lösningar för riktpunkt 12.2
12.3Dela upp stora block av information i mer hanterliga grupper där det är naturligt och verkar stämma. [Prioritet 2]
I HTML, exempelvis, använd OPTGROUP för att gruppera OPTION-element inuti en SELECT; gruppera styrelement i formulär med FIELDSET och LEGEND; använd listor inuti varandra där detta är användbart; använd rubrikmarkeringar för att strukturera sidor, etc. Se också riktlinje 3.
Tekniska lösningar för riktpunkt 12.3
12.4Se till att styrelement i formulär är explicit kopplade till etiketterna. [Prioritet 2]
I HTML, använd LABEL och dess "for"-attribut.
Tekniska lösningar för riktpunkt 12.4

Riktlinje 13. Tillhandahåll tydliga navigationsanvisningar.

Nästa riktlinje: 14 Föregående riktlinje: 12 Till innehållsförteckningen

Tillhandahåll tydliga och konsekventa navigationsanvisningar - information om var användaren är, navigationslister, en karta över webbplatsen - för att öka sannolikheten att en person finner vad de söker på din webb.

Tydliga och konsekventa navigationsanvisningar är viktiga för användare med svårigheter att förstå eller se, men är till fördel för alla användare.

Riktpunkter:

13.1Visa tydligt vart varje länk leder. [Prioritet 2]
Länktext bör innehålla så mycket mening att den går att förstå även när den läses utanför sitt sammanhang - antingen för sig själv, eller som en del av en följd av länkar. Länktext skall också vara kortfattad.
Skriv exempelvis aldrig "klicka här" som beskrivning av en länk. Försök i stället säga något om vart länken leder, till exempel "Information om version 4.3". Förutom en tydlig länktext är det en fördel om innehållsutvecklare kan förklara länken med en länktitel ("title" attributet i HTML).
Tekniska lösningar för riktpunkt 13.1
13.2Tillhandahåll metadata och lägg till semantisk information för sidor och webbar. [Prioritet 2]
Använd exempelvis RDF ([RDF]) för att ange ett dokuments författare, innehållets typ, etc.
Observera. En del användarprogram för HTML kan bygga upp navigationsverktyg från dokumentrelationer som de beskrivs i HTML LINK och "rel" och "rev"-attributen (tex. rel="next", rel="previous", rel="index", etc.). Se också riktpunkt 13.5.
Tekniska lösningar för riktpunkt 13.2
13.3Tillhandahåll information om den aktuella webbens uppläggning (till exempel ett diagram över webben, och dess innehåll). [Prioritet 2]
För att beskriva en webbs layout, markera och förklara de tillgänglighetsfunktioner som finns används.
Tekniska lösningar för riktpunkt 13.3
13.4Använd navigationsanvisningar konsekvent. [Prioritet 2]
Tekniska lösningar för riktpunkt 13.4
13.5Tillhandahåll navigeringslister för att markera och ge tillgång till navigationsfunktioner och -anvisningar. [Prioritet 3]
Tekniska lösningar för riktpunkt 13.5
13.6Gruppera relaterade länkar, identifiera gruppen (för användarprogrammen), och tills användarprogram gör så, ett sätt att gå förbi gruppen. [Prioritet 3]
Tekniska lösningar för riktpunkt 13.6
13.7Om sökfunktioner tillhandahålls, skapa olika nivåer av sökningar för olika kompetenser och preferenser. [Prioritet 3]
Tekniska lösningar för riktpunkt 13.7
13.8Tillhandahåll särskiljande information i början av rubriker, stycken, listor etc. [Prioritet 3]
Observera. Detta kallas allmänt "frontlastning", och är till särskild hjälp för den som får tillgång till informationen med läsutrusningar som går igenom informationen sekventiellt, som till exempel skärmläsare.
Tekniska lösningar för riktpunkt 13.8
13.9Tillhandahåll information om samlingsdokument (till exempel dokument som innehåller många olika sidor, eller dokument som innehåller olika typer av innehåll, till exempel multimediadokument). [Prioritet 3]
Exempelvis, i HTML, ange samlingsdokument med hjälp av LINK-elementet och "rel" och "rev"-attributen. Ett annat sätt att skapa samlingar är att bygga ett arkiv (exempelvis komprimerat med zip, tar och gzip, stuffit, etc.) av sidorna.
Observera. Den prestandavinst som kan göras genom att läsa sidorna från den egna hårddisken kan göra webbläsning mycket mindre problematisk för användare med funktionshinder, som söker långsamt.
Tekniska lösningar för riktpunkt 13.9
13.10Tillhandahåll ett sätt att hoppa över bokstavsbilder. [Prioritet 3]
Se riktpunkt 1.1 och exemplet på bokstavsbilder i ordlistan.
Tekniska lösningar för riktpunkt 13.10

Riktlinje 14. Se till att dokument är lättillgängliga och inte tillkrånglade.

Nästa riktlinje: 1 Föregående riktlinje: 13 Till innehållsförteckningen

Se till att dokument är lättillgängliga, tydliga, och inte tillkrånglade så de är enkla att förstå.

Konsekvent sidlayout, diagram och bilder som är lätta att känna igen, och ett lättbegripligt språk är till fördel för alla användare. De hjälper särskilt människor med svårigheter att förstå, som har svårt att läsa. (Se dock till att bilder har textekvivalenter för dem som är blinda, har dålig syn, eller inte kan se eller har valt bort grafik. Se också riktlinje 1.)

Att använda enkelt och lättbegripligt språk gör kommunikation lättare. Men skriven information kan också innebära ett problem för dem som har inlärningssvårigheter, eller svårt att förstå, liksom för dem som inte är vana att läsa svenska, liksom de som är vana att kommunicera med teckenspråk.

Riktpunkter:

14.1Använd ett språk som är så enkelt som möjligt, anpassat till innehållet på den aktuella webben. [Prioritet 1]
Tekniska lösningar för riktpunkt 14.1
14.2Komplettera text med grafik och ljudpresentation när de underlättar förståelsen av sidan. [Prioritet 3]
Se också riktlinje 1.
Tekniska lösningar för riktpunkt 14.2
14.3Använd en layout och presentationsstil som är konsistent över sidorna. [Prioritet 3]
Tekniska lösningar för riktpunkt 14.3

Bilaga A. -- Validering och utvärdering

Utvärdera tillgängligheten med såväl automatiska verktyg som genomgång av en person. Automatiska metoder är som regel snabba och bekväma, men kan inte identifiera alla problem med tillgänglighet. Mänsklig genomgång kan bidra till att språket är klarare och lättare att förstå, och sidan lättare att hitta i.

Börja använda olika utvärderingsmetoder så snart som möjligt under utvecklingen. Ju tidigare tillgänglighetsproblem upptäcks och identifieras, desto lättare är de att korrigera och undvika i den vidare utvecklingen.

Nedan följer en förteckning över några av de vanligare utvärderingsmetoderna. De diskuteras i detalj i avdelningen om utvärdering och validering i teknikdokumentet.

  1. Använd ett automatiskt utvärderingsverktyg och en webbläsare som validerar. Observera att programvaruverktyg inte kan hantera alla tillgänglighetsfrågor, till exempel om en länktext är meningsfull, om ett textalternativ stämmer med innehållet, etc.
  2. Validera kodningsspråkets syntax (e.g., HTML, XML, etc.).
  3. Validera formatmallar ("style sheets"), till exempel CSS. Ett speciellt valideringsverktyg för CSS1 finns att tillgå på W3C:s webb.
  4. Använd en webbläsare som bara kan återge text, eller emulera en sådan.
  5. Använd flera olika grafiska webbläsare, med olika alternativ i inställningarna, till exempel:
    • ljud och bilder påslagna vid nedladdningen
    • bilder frånslagna vid nedladdningen
    • ljud frånslagna vid nedladdningen
    • ingen mus
    • ramar ("frames"), scriptprogram, formatmallar ("style sheets"), och applet-program frånslagna vid nedladdningen
  6. Använd flera olika versioner av webbläsare, både nyare och äldre.
  7. Använd en läsande webbläsare, en skärmläsare, skärmförstoring, liten skärm, och så vidare (ett sätt att göra detta kan vara att ta upp sidorna på en handdator, till exempel en Palm Pilot eller Psion).
  8. Använd stavningsrättningsprogram och grammatikrättningsprogram (om sådana finns att tillgå för det språk du skriver på). En person som läser en sida med hjälp av ett talsyntesprogram kanske inte kan förstå när ett felstavat ord uttalas. Att ta bort grammatikfel underlättar förståelsen, framför allt för människor som inte har språket som sitt modersmål.
  9. Gå igenom dokumenten och kontrollera att de är lättförståeliga och tydliga. Läsbarhetsstatistik, som LIX och sådan statistik som produceras av ordbehandlare, kan vara en god hjälp att avgöra om en sida är lättläst. Emellertid är en bedömning av en erfaren redaktör det bästa verktyget. Att låta en redaktör redigera sidan kan också öka tillgängligheten i texten genom att korrigera språket så att kulturberoende problem undviks. Detta gäller även sidans visuella utseende, till exempel vilka ikoner som används.
  10. Bjud in funktionshindrade medarbetare att gå igenom dokumenten. Vana såväl som ovana användare med funktionshinder kan ge värdefull information om tillgänglighetsproblem, och hur allvarliga de är.

Bilaga B. -- Ordlista

Användarprogram (User agent)
Programvara för att återge innehåll från World Wide Web, som grafiska webbläsare, textläsare, röstläsare, mobila terminaler, multimediaspelare, och stödtekniker som används tillsammans med webbläsare, som skärmläsare, skärmförstorare, och röststyrningsprogram.
Appletprogram (Applet)
Ett program som presenteras inom ramen för en webbläsare.
Bakåtkompatibel (Backward compatible)
En programvara eller annan informationsmängd som fungerar med tidigare versioner av densamma eller dess beroende program eller informationsmängder (exempelvis webbläsare).
Bild (Image)
En grafisk presentation.
Bokstavsbilder (ASCII art)
Bokstavsbilder är bilder som åstadkommits genom att bokstäver och andra tecken kombineras för att skapa en bild. :-) är en så kallad "smiley", som vänd på sidan visar att författaren ler, d.v.s. menar det sagda skämtsamt. Det följande är en bild som visar förhållandet mellan blixtfrekvens och ljusberoende sammandragningar hos patienter med ögonen öppna respektive stängda [klicka här för att hoppa över figuren eller se en beskrivning av diagrammet]: 
 
  %   __ __ __ __ __ __ __ __ __ __ __ __ __ __   
100 |             *                             |
 90 |                *  *                       |
 80 |          *           *                    |
 70 |             @           *                 |
 60 |          @                 *              |
 50 |       *        @              *           |
 40 |                   @              *        |
 30 |    *  @              @  @           *     |
 20 |                                           |
 10 |    @                       @  @  @  @     |
      0  5 10 15 20 25 30 35 40 45 50 55 60 65 70
      Flash frequency (Hertz)
Brailleskrift
Brailleskrift använder sex upphöjda punkter i olika mönster för att representera bokstäver och siffror på ett sätt som gör att de kan läsas av blinda med hjälp av känseln. Ordet "Accessible" i brailleskrift ser ut såhär:
Accessible
En brailleläsare höjer upp och sänker ner metallstift i olika mönster på kommando från en elektronisk utrustning, som regel en dator. Resultatet är en rad med brailletecken som kan ändras på kommando. De vanligaste brailleläsarna är en cell (sex gånger sex eller åtta gånger åtta stift) upp till åttio celler.
Dynamisk HTML (DHTML)
DHTMLär en marknadsföringsterm för en blandning av ett antal olika standarder, inklusive HTML, formatmallar ("style sheets"), Document Object Model [DOM1] och scriptprogrammering. DHTML är inte standard, och det finns ingen W3C-specifikation som specicfierar DHTML. Följande riktlinjer berör området: Riktlinje 1, riktlinje 3, riktlinje 6, riktlinje 7, och riktlinje 9.
Element (Element)
Detta dokument använder begreppet "element" både i den strikta SGML-bemärkelsen (ett element är en syntaktisk konstruktion), och mer generellt i from av en innehållstyp (som video eller ljud), lika väl som en logisk konstruktion (exempelvis en rubrik eller en lista). Den andra betydelsen understryker att en riktlinje som är utformad för HTML kan användas för ett annat kodningsspråk.
Observera att en del (SGML)element har innehåll som visas på skärmen (exempelvis P, LI, och TABLE-elementen i HTML), medan en del har innehåll som ersätts med innehåll som hämtas in utifrån (exempelvis IMG), och somliga som påverkar bearbetningen av dokumentet (exempelvis STYLE och SCRIPT, som gör att informationen hanteras av en formatmall ("style sheet" eller ett scriptprogram). Ett element som inkluderar text (bokstäver) i ett dokument kallas ett textelement.
Formatmallar (Style sheets)
En formatmall är en uppsättning beskrivningar som anger hur ett dokument skall presenteras. Formatmallar kan kopplas till dokumentet på olika sätt: De kan vara de som definierats av innehållsutvecklaren, de kan definieras av användaren, eller de kan vara inbyggda i användarprogrammet. I CSS-standarden ([CSS2]), beskrivs interaktionen mellan innehållsleverantör, användare, och användarprogram som en kaskad (på svenska vore "vattenfall" en lämpligare metafor).
Författarverktyg (Authoring tool)
Dokumentkonverteringsverktyg, redigeringsprogram för HTML, och program som genererar webbsidor från databaser är alla författarverktyg. Se vidare "Authoring Tool Accessibility Guidelines" ([WAI-AUTOOLS]) för information om hur sådana verktyg bör utformas för att underlätta produktionen av tillgängliga sidor.
Handdator (Personal Digital Assistant (PDA))
En handdator är en liten, handhållen dator. De flesta handdatorer används antingen för personligt bruk som elektroniska kalendrar, eller i tillämpningar som lagerinventarier och liknande. Skärmen på en handdator är som regel ungefär av samma storlek som handflatan. Inmatningen kan göras på olika sätt, med penna, tangentbord, eller andra metoder.
Innehåll, struktur och presentation av dokument (Document content, structure and presentation)
Innehållet i ett dokument är det meddelande det överför till användaren genom naturligt språk, bilder, ljud, film, animeringar, mm (observera att användaren kan vara ett annat program eller en annan dator). Dokumentets struktur är dess logiska organisation (exempelvis i kapitel, stycken, med ingress och innehållsförteckning, etc.). Ett element (till exempel P, STRONG, BLOCKQUOTE i HTML) som anger hur dokumentet är strukturerat är ett strukturelement. Presentationen av dokumentet är hur det visas för användaren (exempelvis via en webbläsare på bildskärmen, som en utskrift, i form av en tvådimensionell grafisk presentation, i form av en textpresentation, som syntetiskt tal, utskrivet på en brailleläsare, etc.). Ett element som anger dokumentets presentation (exempelvis B, FONT, CENTER) är ett presentationselement.
Ett HTML-dokuments rubrik innehåller det texten i fältet anger. I dokumentets struktur utgör det en rubrik. Rubriken kan presenteras som en större grad centrerat i spalten, som en marginalrubrik i fetstil, eller som en starkare betoning eller annorlunda röst. Hur presentationen ser ut (eller låter) anges i formatmallen ("style sheet"). Ett exempel på ett sådant fält är <h2>Detta &auml;r en rubrik</h2>. Innehållet är "detta är en rubrik", det är en rubrik eftersom den anges inom ramen för <h2></h2>. Presentationen anges i formatmallen.
Innehållsutvecklare (Content developer)
En person som författar eller kodar webbsidor, och/eller utformar webbar.
Klickbar bild (Image map)
En bild som delats in i regioner med händelser associerade med dem. Klickar man på en aktiv region kommer en händelse att inträffa, till exempel att en ny sida hämtas in.
När en användare klickar på en aktiv region i en klickbar bild med regionerna inskrivna i HTML-koden, beräknar användaragenten var regionen är och följer den länk som är associerad med regionen. Om de aktiva regionerna är lagrade i en server kommer koordinaterna att sändas till servern, som sedan utför en aktion.
Innehållsutvecklare kan göra klickbara bilder tillgängliga genom att tillhandahålla utrustningsoberoende åtkomst till de länkar som är associerade med de aktiva regionerna i bilden. Klickbara bilder tillåter användarprogrammet att visa om skärmpekaren befinner sig över ett aktivt område.
Tabell i löpande text (Linearized table)
En tabell som återges i form av en serie stycken efter varandra är linjär. Styckena kommer att återges i samma ordning som cellerna är definierade i dokumentets grundtext. Cellerna måste vara begripliga när de läses i ordning, och innehålla strukturelement (som skapar stycken, rubriker, listor, etc) så att sidan är begriplig när den lineariserats.
Länktext (Link text)
Den text som återges på skärmen (eller av en skärmläsare) för att visa länken.
Motsvarighet eller alternativ (Equivalent)
Innehåll motsvarar annat innehåll när bägge fyller samma funktion eller ändamål när det presenteras för användaren. I detta dokuments sammanhang måste alternativ ha samma funktion för användaren med funktionshinder (så länge detta är möjligt, givet funktionshindret och teknikens nivå), som för en användare utan funktionshinder. Exempelvis: Textalternativet "Bild av fullmånen" kan överföra samma information till användaren som en bild av fullmånen, om detta är det enda syftet med bilden (om det är en dekoration; är det en astronomisk bild, måste textalternativet givetvis också ange tid på året andra relevanta fakta). Observera att informationsekvivalenten är fokuserad på att ha samma funktion för användaren. Om bilden är en del av en länk, och att förstå bilden är nödvändigt för att förstå länkens mål, måste textalternativet också ge användaren en idé om innehållet i målet. Att tillhandahålla motsvarande innehåll för otillgängligt innehåll är ett av de främsta sätten innehållsutvecklare kan göra dokument tillgängliga för användare med funktionshinder.
Ett alternativ kan ha en motsvarande funktion som innehållet om det innehåller en beskrivning av innehållet (exempelvis vad det ser ut som eller låter som). Innehållet i ett komplext diagram kan göras tillgängligt om det också beskrivs i textform.
Innehåll i textform kan överföras till användare genom att visas på skärmen, som syntetiskt tal, eller braille. Därför kräver dessa riktlinjer att det finns textekvivalenter för grafik och ljudinformation. Textekvivalenter måste vara skrivna så att de överför allt nödvändigt innehåll. Icke-textuella ekvivalenter (exempelvis en ljudbeskrivning av en visuell presentation, en videofilm av en person som berättar en historia med teckenspråk) kan också förbättra tillgängligheten för användare som ine kan använda visuell information eller skriven text, exempelvis personer med nedsatt syn, svårigheter att förstå, svårigheter att lära, och nedsatt hörsel.
Ekvivalent information kan tillhandahållas på många sätt, exempelvis genom attribut (exempelvis text i "alt"-attributet i HTML och SMIL), som en del av elementets innehåll (exempelvis OBJECT i HTML), lika väl som dokumentets text, eller via ett länkat dokument (angivet exempelvis genom "longdesc"-attributet i HTML, eller en beskrivande länk). Beroende på innehållets komplexitet, kan det bli nödvändigt att kombinera olika tekniker (exempelvis använda "alt" för en förkortad motsvarighet som är begriplig för vana läsare, förutom "longdesc" för att ange en länk till mer fullständig information som är användbar för förstagångsläsare). Hur och när ekvivalent information skall tillhandahållas kan återfinnas i teknikdokumentet ([TECHNIQUES]).
Ett transkription i textform är ett textalternativ till ljudinformation som innehåller talade ord eller andra icke-talade ljud som ljudeffekter av olika slag. En undertext är en transkription av ett ljudspår för en film eller video som är synkroniserad med bilden eller ljudspåret. Undertexter visas som reger visuellt genom att visas över videon, vilket är till fördel för människor som är döva eller har svårt att höra, och alla andra som har svårt att höra ljudet (exempelvis i ett rum med hög ljudnivå). En beskrivande undertext (collating caption) kombinerar (kollimaterar) undertexter med textbeskrivningar av innehållet i filmen eller videon (beskrivningar av händelserna, kroppsspråket, grafiken, och klipp mellan scener). Dessa textspår gör innehållet tillgängligt för användare som är dövblinda, och för dem som inte kan spela upp filmer, video, animeringar, och liknande. Det gör också informationen tillgänglig för sökmotorer.
Ett exempel på en icke-textuell informationsekvivalent är en ljudbeskrivning av nyckelelementen i en visuell presentation. Beskrivningen är antingen en förinspelad röst, eller en syntetiserad röst (antingen sammansatt av element som spelats in i förväg, eller skapat av en talsyntetisator). Ljudbeskrivningen är synkroniserad med ljudspåret för presentationen, som regel genom naturliga pauser i ljudspåret. Ljudbeskrivningar kan innefatta information om händelser, kroppsspråk, grafik, och scenbyten.
Naturligt språk (Natural Language)
Talade, skrivna eller tecknade språk som franska, japanska, svenska, och American Sign Language. Det språk som används i ett dokuments innehåll kan indikeras med "lang"-attributet i HTML ([HTML40], stycke 8.1) och "xml:lang"-attributet i XML ([XML], stycke 2.12).
Navigationsanvisningar (Navigation Mechanism)
En navigationsanvisning är information som hjälper användaren att hitta på en sida eller i en webb. Några typiska navigationsanvisningar är:
navigationslister
En navigationslist är en samling länkar till de viktigaste delarna av ett dokument eller en webb.
webbkartor
En webbkarta är en övergripande bild av hur webben eller sidan är organiserad.
innehållsförteckning
En innehållsförteckning förtecknar som regel de viktigaste delarna av dokumentet, och innehåller länkar till dem.
Nedgraderad (Deprecated)
Ett nedgraderat element eller attribut är ett som blivit obsolet eftersom nya element eller attribut har tillkommit. Nedgraderade element kan bli helt obsoleta i framtida versioner av HTML, men har behållits för bakåtkompatibilitetens skull. Listan över HTML-element och attribut i teknikdokumentet anger vilka element och attribut som har nedgraderat i HTML 4.0.
Innehållsutvecklare bör undvika att använda nedgraderade element och attribut.
Presentationskodning (Presentation markup)
är kodning av dokument som anger en presentationsfunktion, snarare än en strukturell funktion. Exempel är B och I-elementen i HTML. Observera att STRONG och EM-elementen inte är presentationskodning eftersom de innehåller information som är oberoende av typsnitt och presentationsmedium.
Skärmförstorare (Screen magnifier)
Ett program som förstorar en del av skärmen, så att den kan läsas lättare. Skärmförstorare används som regel av användare med synsvårigheter.
Skärmläsare (Screen reader)
Ett program som läser ut innehållet på skärmen i form av tal. Skärmläsare används framför allt av användare som inte kan se. Skärmläsare kan som regel bara läsa ut text som skrivs ut via datorns teckengenerator, och inte återges som grafik.
Stödteknik (Assistive technology)
Datorprogram eller utrustning som har utformats för att underlätta för människor med funktionshinder att utföra vardagsuppgifter. Sådan teknik kan innefatta rullstolar, maskiner för textläsning, hjälpmedel för handikappade, och så vidare. När det gäller att göra webbsidor tillgängliga omfattar vanliga stödtekniker program för skärmläsning, förstoring av skärmbilden, talsyntesprogram, och röststyrningsprogram som fungerar tillsammans med webbläsare och andra användarprogram. Även alternativa tangentbord och pekdon kan räknas hit.
Tabellinformation (Tabular information)
När tabeller används för att representera logiska relationer mellan dataelement - text, siffror, bilder, etc. - kallas informationen "tabellinformation", och tabellerna "datatabeller". Relationerna som uttrycks i en tabell kan återges visuellt (i form av en tvådimensionell matris), uttalat (ofta föregående celler med rubriker), eller i andra format.
Tillgänglig (Accessible)
Innehåll är tillgängligt när det kan användas av någon som har ett funktionshinder, till exempel nedsatt syn eller hörsel (observera att detta inte behöver innebära att personen är handikappad, eller att funktionshindret är permanent).
Tills användaragenter (Until user agents) ...
I de flesta riktpunkter anges att innehållsutvecklare skall se till att deras sidor är tillgängliga. Det finns emellertid tillgänglighetsfunktioner som är lättare att hantera i användarprogram (user agents) (inklusive stödtekniker (assistive technologies)). När detta dokument ges ut kan många användarprogram och stödtekniker inte hantera alla tillgänglighetsfunktioner (en del användarprogram tillåter exempelvis inte att användaren slår från blinkande innehåll, och en del skärmläsare har problem med tabeller). Riktpunkter som innehåller orden "tills användaragenter..." kräver att innehållsutvecklare tillhandahåller ytterligare stöd för tillgänglighetsfunktioner tills användarprogram innehåller dessa funktioner.
Observera. W3C:s WAI-webb ([WAI-UA-SUPPORT]) ger mer information om användarprogrammens stöd för tillgänglighetsfunktioner. Innehållsutvecklare bör konsultera denna sida regelbundet för aktuell information.
Utrustningsoberoende (Device independent)
Användaren måste kunna ställa om preferenserna för användarprogrammet (och det dokument det återger) med hjälp av de in- och utdatafunktioner som de väljer att använda, och efter deras behov. Indataverktyg kan vara exempelvis pekdon, tangentbord, brailleläsare, pekare som bärs på huvudet, mikrofoner, och så vidare. Utdataenheter kan vara bildskärmar, talsyntesprogram, och brailleläsare, bland annat.
Observera att "utrustningsoberoende" inte innebär att användarprogrammet måste ha stöd för samtliga tänkbara utrustningar. Om användarprogrammet bara har stöd för tangentbord och mus, skall användaren kunna använda alla funktioner med endast tangentbord eller mus.
Viktigt (Important)
Informationen  i dokumentet är viktig om den är nödvändigt för att användaren skall förstå dokumentet.

Tack

Web Content Guidelines Working Group ordföranden:
Chuck Letourneau, Starling Access Services
Gregg Vanderheiden, Trace Research and Development
Kontakter på W3C:
Judy Brewer och Daniel Dardailler
Vi vill tacka de följande personerna, som alla har bidragit sin tid och sina värdefulla kommentarer till utformningen av dessa riktlinjer:
Harvey Bingham, Kevin Carey, Chetz Colwell, Neal Ewers, Geoff Freed, Al Gilman, Larry Goldberg, Jon Gunderson, Eric Hansen, Phill Jenkins, Leonard Kasday, George Kerscher, Marja-Riitta Koivunen, Josh Krieger, Scott Luebking, William Loughborough, Murray Maloney, Charles McCathieNevile, MegaZone (Livingston Enterprises), Masafumi Nakane, Mark Novak, Charles Oppermann, Mike Paciello, David Pawson, Michael Pieper, Greg Rosmaita, Liam Quinn, Dave Raggett, T.V. Raman, Robert Savellis, Jutta Treviranus, Steve Tyler, Jaap van Lelieveld, och Jason White.
För korrekturläsning av den svenska texten riktar vi ett tack till Jan Sandred.

Det ursprungliga utkastet till detta dokument bygger på "The Unified Web Site Accessibility Guidelines" ([UWSAG]) som sammanställts av Trace R & D Center vid University of Wisconsin. Det dokumentet innehåller en lista på ytterligare medarbetare.

Referenser

För en lista av de senaste specifikationerna från W3C, se W3C:s tekniska rapportsidor.

[CSS1]
"CSS, level 1 Recommendation", B. Bos, H. Wium Lie, eds., 17 December 1996, reviderad 11 Januari 1999. CSS1 Recommendation finns tillgänglig på adressen: http://www.w3.org/TR/1999/REC-CSS1-19990111.
Den senaste versionen av CSS1 finns tillgänglig på: http://www.w3.org/TR/REC-CSS1.
[CSS2]
"CSS, level 2 Recommendation", B. Bos, H. Wium Lie, C. Lilley, and I. Jacobs, eds., 12 Maj 1998. CSS2 Recommendation finns tillgänglig på: http://www.w3.org/TR/1998/REC-CSS2-19980512.
Den senaste versionen av CSS2 finns tillgänglig på: http://www.w3.org/TR/REC-CSS2.
[DOM1]
"Document Object Model (DOM) Level 1 Specification", V. Apparao, S. Byrne, M. Champion, S. Isaacs, I. Jacobs, A. Le Hors, G. Nicol, J. Robie, R. Sutor, C. Wilson, and L. Wood, eds., 1 Oktober 1998. DOM Level 1 Recommendation finns tillgänglig på: http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001.
Den senaste versionen av DOM Level 1 finns tillgänglig på: http://www.w3.org/TR/REC-DOM-Level-1
[HTML40]
"HTML 4.0 Recommendation", D. Raggett, A. Le Hors, and I. Jacobs, eds., 17 December 1997, reviderad 24 April 1998. HTML 4.0 Recommendation-standarden finns tillgänglig på: http://www.w3.org/TR/1998/REC-html40-19980424.
Den senaste versionen av HTML 4.0 finns tillgänglig på: http://www.w3.org/TR/REC-html40.
[HTML32]
"HTML 3.2 Recommendation", D. Raggett, ed., 14 January 1997. The latest version of HTML 3.2 is available at: http://www.w3.org/TR/REC-html32.
[MATHML]
"Mathematical Markup Language", P. Ion och R. Miner, eds., 7 April 1998. MathML 1.0 Recommendation har adressen: http://www.w3.org/TR/1998/REC-MathML-19980407.
Den senaste versionen av MathML 1.0 finns tillgänglig på: http://www.w3.org/TR/REC-MathML.
[PNG]
"PNG (Portable Network Graphics) Specification", T. Boutell, ed., T. Lane, contributing ed., 1 Oktober 1996. Den senaste versionen av PNG 1.0 finns tillgänglig på: http://www.w3.org/TR/REC-png.
[RDF]
"Resource Description Framework (RDF) Model and Syntax Specification", O. Lassila, R. Swick, eds., 22 February 1999. RDF-standarden (W3C Recommendation) finns tillgänglig på: http://www.w3.org/TR/1999/REC-rdf-syntax-19990222.
Den senaste versionen av RDF 1.0 finns tillgänglig på: http://www.w3.org/TR/REC-rdf-syntax
[RFC2068]
"HTTP Version 1.1", R. Fielding, J. Gettys, J. Mogul, H. Frystyk Nielsen, and T. Berners-Lee, Januari 1997.
[SMIL]
"Synchronized Multimedia Integration Language (SMIL) 1.0 Specification", P. Hoschka, ed., 15 June 1998. Adressen till SMIL 1.0 Recommendation är: http://www.w3.org/TR/1998/REC-smil-19980615
Den senaste versionen av SMIL 1.0 finns tillgänglig på: http://www.w3.org/TR/REC-smil
[TECHNIQUES]
"Techniques for Web Content Accessibility Guidelines 1.0", W. Chisholm, G. Vanderheiden, I. Jacobs, eds. Detta dokument förklarar hur riktpunkterna i dokumentet "Web Content Accessibility Guidelines 1.0" skall implementeras. Det senaste utkastet till detta dokument finns tillgängligt på: http://www.w3.org/TR/WAI-WEBCONTENT-TECHS
[WAI-AUTOOLS]
"Authoring Tool Accessibility Guidelines", J. Treviranus, J. Richards, I. Jacobs, C. McCathieNevile, eds. Det senaste utkastet till dessa riktlinjer för hur författarverktyg skall utformas för att göra information tillgänglig finns tillgängliga på: http://www.w3.org/TR/WAI-AUTOOLS/
[WAI-UA-SUPPORT]
Denna sida dokumenterar i vilken mån användarprogram (inklusive stödtekniker) innehåller de funktioner för tillgänglighet som listas i detta dokument: http://www.w3.org/WAI/Resources/WAI-UA-Support
[WAI-USERAGENT]
"User Agent Accessibility Guidelines", J. Gunderson and I. Jacobs, eds. Det senaste utkastet för dessa riktlinjer, som anger hur användarprogram skall utformas för att göra information tillgänglig, finns på: http://www.w3.org/TR/WAI-USERAGENT/
[WCAG-ICONS]
Information om uppfyllande av detta dokument, och de ikoner som anger att de uppfylls finns på http://www.w3.org/WAI/WCAG1-Conformance.html
[UWSAG]
"The Unified Web Site Accessibility Guidelines", G. Vanderheiden, W. Chisholm, eds. The Unified Web Site Guidelines sammanställdes av Trace R & D Center vid University of Wisconsin med finansiering från National Institute on Disability and Rehabilitation Research (NIDRR) och  U.S. Dept. of Education. Detta dokument finns tillgängligt på: http://www.tracecenter.org/docs/html_guidelines/version8.htm
[XML]
"Extensible Markup Language (XML) 1.0.", T. Bray, J. Paoli, C.M. Sperberg-McQueen, eds., 10 February 1998. XML 1.0-specifikationen finns tillgänglig på: http://www.w3.org/TR/1998/REC-xml-19980210.
Den senaste versionen av specifikationen av XML 1.0 finns tillgänglig på: http://www.w3.org/TR/REC-xml

 

[Innehåll]   [Checklista över riktpunkterna]  
Copyright © 1999 W3C (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.