Riktlinjer för utformning av innehåll på webben, version
1.0
W3C Recommendation 5 Maj 1999
-
-
Detta är en svensk översättning av W3C:s Web Content Accessibility
Guidelines 1.0. Den kan innehålla mindre översättningsfel.
Den normerande, engelska texten finns på:
-
-
http://www.w3.org/TR/WAI-WEBCONTENT/
-
-
Denna översättning har adressen:
-
http://www.w3c.se/resources/office/translations/WAI-WEBCONTENT.html
-
och kan också återfinnas på:
-
http://www.w3.org/TR/WAI-WEBCONTENT-SE/
-
Översättare:
-
Johan Hjelm, Ericsson/W3C
<hjelm@w3.org>
-
-
This documented is a translated copy of the W3C's Web Content Accessibility
Guidelines 1.0 Recommendation. This document may contain translation errors.
The normative, English language, version can be found at:
-
-
http://www.w3.org/TR/WAI-WEBCONTENT/
-
This Swedish translation is:
-
http://www.w3c.se/resources/office/translations/WAI-WEBCONTENT.html
-
and it can also be found at: och kan också återfinnas på:
-
http://www.w3.org/TR/WAI-WEBCONTENT-SE/
-
Translator:
-
Johan Hjelm, Ericsson/W3C
<hjelm@w3.org>
-
Denna version:
-
http://www.w3c.se/resources/office/translations/WAI-WEBCONTENT.html
-
(engelsk ASCII-text,
Engelsk PostScript,
Engelsk PDF, Engelsk gzip tar
file med HTML-text,
Engelsk zip-fil med HTML-text)
-
Senaste engelska version:
-
http://www.w3.org/TR/WAI-WEBCONTENT
-
Föregående engelska version:
-
http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990324
-
Författare:
-
Wendy Chisholm, Trace R & D
Center, University of Wisconsin -- Madison
Gregg Vanderheiden, Trace R & D
Center, University of Wisconsin -- Madison
Ian Jacobs, W3C
Copyright © 1999
W3C
(MIT,
INRIA,
Keio), All Rights Reserved. W3C
liability,
trademark,
document
use and
software
licensing rules apply. Detta dokument är skyddat enligt lagen om
upphovsrätt.
Dessa riktlinjer förklarar hur
innehåll på webben kan göras
mer tillgängligt för människor med funktionshinder. Dessa
riktlinjer är avsedda för alla som
utvecklar innehåll för webben
(författare, informationsarkitekter, webmasters, och webbdesigners)
och för utvecklare av
författarverktyg. Den primära
målsättningen för dessa riktlinjer är att främja
tillgänglighet för människor med funktionshinder, men om de
följs, kommer innehållet på webben att bli mer
tillgängligt för ALLA användare, oavsett vilket
användarprogram
de har (exempelvis webbläsare på PC, röstläsare,
WAP-telefon, bildator, och liknande) och vilka begränsningar
miljön medför (till exempel bullriga omgivningar, mörka eller
överljusa rum, "hands-free" användning, och så vidare). Om
dessa riktlinjer följs, kommer också sökningar på webben
och användares informationsåtkomst att underlättas. Dessa
riktlinjer avser inte att begränsa innehållsutvecklarens
användning av bilder, videoklipp och liknande, utan avser att visa hur
multimedia kan göras mer tillgängligt för en större publik.
Detta är ett referensdokument för tillgänglighetsprinciper
och idéer för utfomning. Detta dokument diskuterar
internationaliseringsfrågor och frågor rörande mobil
åtkomst till information. Detta dokument är emellertid i första
hand inriktat på tillgänglighet för funktionshindrade, och
adresserar inte i full utsträckning frågor som rör andra
aktiviteter inom W3C. För mer information om dessa frågor,
se W3Cs Mobile Access Activitys
hemsida och W3Cs
Internationalization Activitys hemsida för mer information.
Detta dokument är avsett att inte förändras över tiden,
och ger därför ingen specifik information om olika webbläsare
och i vilken mån de stödjer olika tekniker, eftersom detta är
information som tenderar att förändras snabbt. I stället
hänvisas intresserade läsare till den webb som satts upp av
Web Accessibility Initiative
(WAI) (se
[WAI-UA-SUPPORT]).
Till detta dokument finns en bilaga med en
checklista
(på engelska) där de viktigaste punkterna är
organiserade efter ämne och prioritet. Checklistan är länkad
till detta dokument. De ämnen som identifieras i dokumentet omfattar
bilder, multimedia, tabeller, ramar ("frames"), formulär, och scriptprogram.
Bilagan är tillgänglig antingen som en
enkel
lista (på engelska) eller
i form
av en tabell (på engelska)(avsedd för utskrift).
I ett separat dokument, "Tekniska lösningar för Web Content
Accessibility Guidelines 1.0" ([TECHNIQUES]),
förklarar vi hur checklistan skall användas. Detta dokument går
igenom varje punkt i checklistan i mer detalj, och ger exempel på hur
olika tekniker, som till exempel Hypertext Markup Language
(HTML), Cascading Style Sheets
(CSS), Synchronized Multimedia
Integration Language
(SMIL),
och Mathematical Markup Language
(MathML) skall användas. Detta dokument
innehåller också teknikanvisningar för validering och testning
av dokument, och ett index över HTML-element och -attribut (och en
förteckning över vilka tekniker som använder dem). Detta dokument
är avsett att följa teknikutvecklingen, och kommer att uppdateras
betydligt oftare än det aktuella dokumentet. Observera.
Vi kan inte garantera att alla webbläsare eller multimediaverktyg har
stöd för de funktioner som beskrivs i dessa riktlinjer. I synnerhet
gäller detta nyare funktioner som HTML 4.0, CSS 1 eller CSS 2.
"Riktlinjer för utformning av innehåll på webben, version1.0"
är en del i en serie riktlinjer för tillgänglighet som publicerats
av W3C:s Web Accessibility Initiative.
Serien innehåller också User Agent Accessibility Guidelines
([WAI-USERAGENT]) och Authoring Tool
Accessibility Guidelines ([WAI-AUTOOLS]).
Dessa finns dock ej översatta till svenska.
Detta dokument har gåtts igenom och reviderats av W3C:s medlemmar och
andra intresserade grupper, och har tilldelats status av W3C:s Director som
W3C Recommendation. Det kommer inte att förändras och kan
användas som referensmaterial och citeras i normativa referenser från
andra dokument. W3C:s avsikt med att göra detta dokument till en
Recommendation är att dra uppmärksamhet denna specifikation, och
främja dess användning i så stor utsträckning som
möjligt. Om detta dokument används, kommer det att främja
webbens universalitet och utöka dess funktionalitet.
Den engelska versionen av detta dokument är den normerande versionen.
En förteckning av översättningar finns
på http://www.w3.org/WAI/GL/WAI-WEBCONTENT-TRANSLATIONS.
En förteckning över kända fel i detta dokument finns
på http://www.w3.org/WAI/GL/WAI-WEBCONTENT-ERRATA.
Vi är tacksamma om eventuella fel rapporteras till
wai-wcag-editor@w3.org. Detta
gäller emellertid inte den svenska terminologin. Det heter inte
webbläddrare.
En förteckning över de aktuella W3C Recommendations och andra tekniska
dokument finns tillgänglig på
http://www.w3.org/TR.
Detta dokument är producerat som en del av W3C:s
Web Accessibility Initiative.
Målsättningen för Web
Content Guidelines Working Group beskrivs i
gruppens
målbeskrivning.
Ytterligare bilaga:
Checklista
för Web Content Accessibility Guidelines 1.0 (på engelska).
En
tabellversion för utskrift (på engelska) finns också
tillgänglig.
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:
-
Hon kanske inte kan höra, se, röra sig, eller bearbeta olika typer
av information särskilt väl eller alls.
-
Hon kan ha svårt att läsa eller förstå text.
-
Hon kan ha svårt att använda ett tangentbord eller ett pekdon
(till exempel en mus).
-
Hon kan ha en bildskärm som bara återger text, eller en långsam
förbindelse till Internet.
-
Hon kanske inte talar eller förstår till fullo det språk
som dokumentet är skrivet på.
-
Hon kan vara i en miljö eller situation där ögon, öron,
eller händer är upptagna (till exempel under bilkörning, arbete
i bullriga miljöer, och liknande).
-
Hon kan ha en gammal eller annan webbläsare än den du använder,
eller en annan dator, eller rentav en röstläsare.
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":
-
Textinnehållet kan presenteras för användaren som syntetiskt
tal, braille, eller som text på en bildskärm. Vart och ett av
dessa tre alternativ använder varsitt sinne för att presentera
innehållet: Rösten når örat, braille talar till fingrarna,
och ögonen ser texten på skärmen. Detta gör informationen
mer tillgänglig för grupper som har svårigheter att använda
något av de andra sinnena.
-
För att vara användbar måste texten ha samma funktion och
syfte som bilden. Tag till exempel en bild av Jorden sedd från rymden.
Om syftet enbart är dekorativt, kan bilden ersättas med texten
"Jorden sedd från rymden". Men om bildens syfte är att förklara
någon specifik aspekt av Jordens geografi, då skall textalternativet
ge den informationen. Om till exempel syftet är att illustrera Jorden
som en av solsystemets planeter, kan ett textalternativ vara "Information
om Jorden". Detta innebär att om texten har samma funktion eller syfte
för användaren med funktionshinder, så är den ett alternativ
till bilden.
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
alternativ till 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.
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.
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:
-
Skilj strukturen från presentationen (se diskussionen om skillnaderna
mellan
innehåll, struktur, och presentation).
-
Tillhandahåll text (inklusive
textalternativ).
Text kan presenteras för användaren på sätt som finns
tillgängliga i i stort sett alla webbläsarapparater och som är
tillgänglig för i stort sett alla användare.
-
Gör dokument som fungerar även om användaren inte kan se och/eller
höra. Tillhandahåll information som fyller samma funktion och
har samma mål som ljud och video på sätt som är anpassade
till alternativa sinnesförmögenheter. Detta innebär inte att
du behöver spela in en ljudversion av din webb för blinda
användare. De använder ofta
skärmläsare som kan spela upp all
information på sidan.
-
Gör dokument som inte är beroende av en enda typ av dator eller
programvara. Dina sidor bör vara användbara utan pekdon, för
användare med små bildskärmar, låg upplösning,
svart-vita skärmar, enbart röstvisning, etc.
Hur du skapar mjuka övergångar diskuteras vidare i riktlinjerna
1 till 11.
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.
Detta dokument innehåller fjorton
riktlinjer, generella principer för
tillgänglig webbdesign. Varje riktlinje innehåller:
-
Riktlinjens nummer.
-
Vad riktlinjen omfattar.
-
Navigationslänkar för riktlinjen. Tre länkar låter dig
komma vidare till nästa riktlinje (högerpilsikonen), den
föregående riktlinjen (vänsterpilsikonen), eller den aktuella
riktlinjens plats i innehållsförteckningen (uppåtpilsikonen).
-
En bakgrund till riktlinjen och exempel på de användargrupper
som har nytta av den.
-
En lista med definitioner för riktlinjens plats i checklistan.
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:
-
Riktpunktens nummer.
-
Vad riktpunkten omfattar.
-
Riktpunktens prioritet. Prioritet 1 visas med hjälp av formatmallar
(style sheets).
-
Noteringar, exempel, och korsreferenser till andra riktlinjer och definitioner.
Dessa är endast informativa.
-
En länk till den avdelning i teknikdokumentet
([TECHNIQUES]) där implementationer och
exempel på definitionen diskuteras.
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.
I det här dokumentet använder vi följande skrivregler:
-
Elementnamn skrivs med VERSALER (stora bokstäver).
-
Attributnamn skrivs med gemener (små bokstäver).
-
Länkar till definitioner är markerade via formatmallen.
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.
Denna sektion anger tre nivåer som dokument som följer riktlinjerna
kan uppfylla:
-
Nivå"A": alla riktpunkter med Prioritet 1 har
följts;
-
Nivå "Dubbel-A": alla riktpunkter med Prioritet 1
och 2 har följts;
-
Nivå "Trippel-A": alla riktpunkter med Prioritet 1,
2, och 3 har följts;
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:
-
Riktlinjedokumentets titel: "Riktlinjer för utformning av innehåll
på webben, version 1.0"
-
Riktlinjedokumentets URI:
http://www.w3c.se/resources/office/translations/WAI-WEBCONTENT.html
-
Riktlinjenivån: "A", "Dubbel-A", eller "Trippel-A".
-
Vad som omfattas av deklarationen (sidan, hela webben, eller en avgränsad
del av webben).
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.w3c.se/resources/office/translations/WAI-WEBCONTENT.html, 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).
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.
-
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: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.2
Tillhandahå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.3
Tills 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.4
Fö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.5
Tills 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
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.
-
2.1 Se 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.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. [Prioritet 2 för bilder, Prioritet 3 för
text].
-
Tekniska
lösningar för riktpunkt 2.2
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.
-
3.1 Nä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.2 Skapa
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.3 Anvä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.4
Anvä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.5
Anvä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.6 Koda
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.7 Koda 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
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.
-
4.1 Ange
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.2 Ange 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.3 Ange
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
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).
-
5.1 I
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.2 I
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.3
Anvä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.4 Om 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.5
Tillhandahå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.6
Tillhandahå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.
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.
-
6.1
Organisera 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.2 Se
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.3 Se 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.4
Fö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.5 Se 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.
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.
-
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.
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]).
-
8.1
Se till att program, som scriptprogram och applet-program, är
tillgängliga och kan användas med stödtekniker för
funktionshindrade [Prioritet 1 om 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
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.
-
9.1
Tillhandahå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.2
Se 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.3
Ange logiska händelsehanterare i stället för utrustningsberoende
händelsehanterare i scriptprogram.
[Prioritet 2]
-
Tekniska
lösningar för riktpunkt 9.3
-
9.4 Skapa 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.5
Anvä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
Ä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.
-
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
De existerande riktlinjerna rekommenderar tekniker från W3C (tex. HTML,
CSS) av flera skäl:
-
W3C:s tekniker har reviderats av arbetsgrupperna i Web Accessability Initiative,
vilket innebär att de har tillgängligheten inbyggd från
början.
-
W3C:s specifikationer är föremål för tidig granskning
för att göra säkert att frågor som gör
tillgänglighet för funktionshindrade är behandlade under
utformningsprocessen.
-
W3C:s specifikationer görs tillgängliga genom en öppen process,
som förankrar dem inom industrin.
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.
-
11.1
Anvä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.2
Undvik 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.3
Tillhandahå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.4
Nä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.
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.
-
12.1 Ge 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.2 Beskriv
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.3
Dela 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.4
Se 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
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.
-
13.1
Visa 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.2
Tillhandahå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.3
Tillhandahå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.4
Använd navigationsanvisningar konsekvent.
[Prioritet 2]
-
Tekniska
lösningar för riktpunkt 13.4
-
13.5
Tillhandahå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.6 Gruppera
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.7 Om
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.8
Tillhandahå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.9
Tillhandahå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.10
Tillhandahå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
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.
-
14.1
Anvä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.2 Komplettera
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.3
Använd en layout och presentationsstil som är konsistent över
sidorna. [Prioritet 3]
-
Tekniska
lösningar för riktpunkt 14.3
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.
-
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.
-
Validera kodningsspråkets syntax (e.g., HTML, XML, etc.).
-
Validera formatmallar ("style sheets"), till exempel CSS. Ett speciellt
valideringsverktyg för CSS1 finns att tillgå på W3C:s webb.
-
Använd en webbläsare som bara kan återge text, eller emulera
en sådan.
-
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
-
Använd flera olika versioner av webbläsare, både nyare och
äldre.
-
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).
-
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.
-
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.
-
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.
-
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:
-
-
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 ä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.
-
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.
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/TRREC-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