HvorforHvordan tilgængelighed?
Eller: Hold op med at fortælle mig, at tilgængelighed er godt. Fortæl hellere hvordan man får det.
På dette tidspunkt er du sikkert blevet tudet ørerne fulde at, at Tilgængelighed Er Godt For Dig. Hvis ikke, så læs eventuelt min tidligere posting om samme. Hvis du er for doven til at læse den artikel, er her den korte version: Tilgængelighed er godt, fordi man når en større målgruppe (privat virksomhed) eller fordi man opfylder et anbefalede retningslinier fra IT- og Telestyrelsen (offentlig myndighed).
Jeg synes, der mangler gode anvisninger på, hvordan man rent praktisk anskaffer sig tilgængelighed, så her er altså en artikel, der forklarer det (når jeg i denne artikel skriver “tilgængelighed”, så mener jeg de tekniske betingelser for adgang til indhold på et website. Jeg tillader mig forresten at antage, at der ligger et CMS bag dit site.
Man opnår tilgængelighed sådan:
10 Lav en tilgængelighedsstrategi
20 Analysér nuværende situation
30 Forankr og uddan
40 Implementér tilgængelighed
50 Test
60 Fix
70 GOTO 50
Lav en tilgængelighedsstrategi
Hvis du ikke begynder med at lave en strategi, så lad helt være med at begynde på projektet. Strategien skal svare på følgende spørgsmål:
- Projektets målsætninger. Skal der opfyldes krav fra IT- og Telestyrelsen? Ønsker man flest mulige besøgende? Ønsker man adgang for bestemte enheder? (telefoner PDA’er etc). Forventer man stigning i on-line omsætning eller reduceret tidsforbrug i manuelle arbejdsgange?
- Omfang af ambitioner. Hvilke(n) standard(er) skal opfyldes? (X)HTML, WAI A/AA/AAA, Section 508?
- Ressourcer og budget. Hvor mange penges afsættes til projektet? Hvilke kompetencer findes i organisationen? Skal der uddannes interne personer eller skal projektet outsources?
Analysér nuværende situation
Lav – eller få lavet – en tilgængelighedstest. Testen skal omfatte ALLE sider på sitet. Bobby er et godt værktøj til at gennemføre testen. Desværre et en maskinel test ikke tilstrækkelig. For eksempel er der krav om, at billeder skal have en sigende ALT-tekst. Bobby kan naturligvis ikke vurdere, om en ALT-tekst er sigende i forhold til billedet. Derfor er det nødvendigt med menneskelig vurdering på en række punkter.
Det kan være en god idé at få lavet testen af en ekstern leverandør, fordi den menneskelige vurdering kræver god viden på området. Sensus og Dansk Center for Tilgængelighed laver fx denne type af tests.
Forankr og uddan
Der skal være placeret et klart ansvar for tilgænglighed. Det nytter ikke noget, at den webansvarlige tror, at webudvikleren sørger for, at sitet er tilgængeligt – mens webudvikleren regner med, at den webansvarlige siger til, hvis han/hun vil have tilgængelighed. Ansvaret for tilgængelighed bør ligge åbenlyst hos den webansvarlige. Men det er ikke tilstrækkeligt: Webudviklere bør have den tekniske kompetence, og webforfattere bør være klar over, hvordan man lægger indhold ind i systemet på en tilgængelig måde. Måske har de adgang til HTML-koden i afsnit, måske kan de lave tabeller, måske kan de indsætte billeder. I alle tilfælde er der specielle forhold at være opmærksom på, når sitet skal være tilgængeligt. Hjælp alle med relation til websitet i organstionen med retningslinier for arbejdet med systemet.
Implementér tilgængelighed
Jeg antog jo tidligere, at der ligger et CMS bag dit site. I så fald skal der nok implementeres tilgængelighed flere steder i systemet. Det er vigtigt at kigge bag det publicerede site og på det system, der genererer sitet.
Dels skal alle skabeloner tweakes, så de fremover genererer tilgængeligt output. Lad være med at lave et selvstændigt sæt skabeloner til en tilgængelig variant at sitet. Der er flere gode grunde. Desuden skal der ses på det eksisterende indhold i systemet. De fleste WYSIWYG-editorer laver formattering med HTML. Det betyder, at indholdet kan være “forurenet” af utilgængelig kode. Eventuelt kan der laves en søg-og-erstat på alt indholdet i databasen. Editoren skal følgeligt også tilpasses, så den fremover ikke genererer utilgængeligt indhold. Endelig skal der helt sikkert tilføjes alternativt indhold for ikke-tekstligt indhold som billeder, lyd, video, Flash og så videre.
Hvis CMS’et tillader det, bør man overveje at tilpasse det, så det fremover støtter forfattere i at lave tilgængeligt indhold. Det kan være at spørge efter ALT-tekster til billeder og muligvis lave on-the-fly validering af sider, der skal publiceres.
Hvis dit site ikke publiceres af et CMS, og der er mange sider, ved du, hvad du skal lave resten af året…
Test
Test resultatet af implementeringen. Husk både maskinel test og menneskelig vurdering. Bruges ekstern leverandør af den første, diagnosticerende test, bør samme leverandør også lave testen efter implementering.
Fix
Regn med at første implementering ikke fanger alle tilgængelighedsproblemer. Der er mange faktorer at styre på samme tid. Der vil derfor næsten helt sikkert være fejl at udbedre. Re-fix og re-test indtil resultatet er tilfredsstillende.
Planlæg også at følge op med regelmæssige mellemrum. Lav – eller få lavet – eventuelt en tilgængelighedstest hvert halve år. Når den første, store implementering af tilgængelighed er gennemført, vil der typisk kun være småting at rette fremover.
13. June 2005 kl. 0:24
Og så den virkelige verden:
1. Meddel medarbejderstaben, at personalecomputeren (bemærk entalsformen), har fået installeret et nyt program.
2. Giv en kort information om programmets anvendelighed, vær gerne selv novice i brugen af det – uddeleger straks uddannelsesansvaret til den første nysgerrige medarbejder.
3. Ved konkrete tilbagemeldinger på fejlfinding, ændringsforslag og tekniske spørgsmål, ret da ansvaret videre andre myndigheder eller programudviklere. Suk gerne højt for signalværdiens og ansvarsforflygtigelsens skyld. Saml endelig ikke disse data sammen!
4. Når programmet formodes at have været afviklet af alle, forvent da at medarbejdernes arbejdsrutiner har ændret sig, og højere effektivitet har indfundet sig.
5. Sker pkt. 4 ikke, er det ihvertfald ikke din skyld! Nu har du gjort alt der stod i din magt for at give medarbejderne et godt værktøj og bruger de det så? Overhovedet ikke! De fleste er fuldstændig inkompetente og håbløst ude af sync med tidens krav til selv de mest basale computer-kundskaber! Medarbejdere! Argh! Medarbejdere!
13. June 2005 kl. 8:38
/many, det er jo altid interessant-uhyggeligt med indblik i den virkelig verden, men måske lidt ved siden af emnet?
13. June 2005 kl. 20:53
Sorry. En frustration pressede sig på og _måtte_ sådan ud
)
13. June 2005 kl. 21:40
Arh, det er i orden. Det sker. Det er vigtigt at få ud hurtigt.
14. June 2005 kl. 2:36
Når man snakker om tekniske betingelser for tilgængelige websites skal det understreges at hele den process, Andreas så fint har beskrevet, ikke nødvendigvis skal opfattes som et tidskrævende ekstra projekt.
Tværtimod burde de nævnte retningslinier allerede være en integreret del af ethvert web-projekt. Tilgængelighed er nemlig ikke kun et spørgsmål om at kunne opfylde nogle statslige krav eller fortrykte kravspecifikationer, men i høj grad også et spørgsmål om kvalitet, stolthed og penge i kassen!
Kort formuleret kan man sige at en web udvikler der har gjort sit arbejde ordentligt (læs: korrekt opmarkering af (X)HTML og tanke for brugervenlighed i det færdige produkt) allerede er langt i forhold til et teknisk tilfængeligt website. Ligeledes må det antages at designeren uanset krav til tilgængelighed har tænkt brugervenlighed og dermed tilgængelighed ind i sit oplæg.
En glædelig sideeffekt ved et teknisk og indholdsmæssigt tilgængeligt website er at et større antal brugere vil få en bedre oplevelse, websitet vil med stor sandsynlighed performe bedre og søgemaskiner (Google) vil i højre grad kunne indeksere de dit indhold. Selvom dette hurtigt kunne forvekles med “Hvorfor tilgængelighed” synes jeg det understreger hvor vigtigt det er ALTID at tænke i tilgængelighed.
Alt efter den tilgængelighedsstrategi man har valgt / er blevet påtvunget skal ovenstående naturligvis ikke forståes som en bagatellisering af omfanget. Der er selvsagt lang vej fra WAI A til WAI AAA – netop derfor kan det være til stor hjælp at organisere projektet med udgangspunkt i den lille programstrump øverst.
Nu handler det om HVORDAN man opnår tilgængelighed og så må jeg hellere komme med mine personlige tips:
1: Programmering
Lav altid din kode i XHTML!
Undgå at bruge tabeller til layout. Benyt istedet DIV struktur og kontrollér dit layout v.h.a. et tilhørende stylesheet.
Lav såvidt muligt alting tekstbaseret. Benyt listmenuer til struktureret information, som f.eks. navigationer.
2: Test & kvalitetssikring
Kør løbende din kode/sider gennem en validator (http://validator.w3.org/). Det vil ikke alene øge chancen for at dit website er tilgængeligt, men også sikre at koden er korrekt struktureret.
3: Undgå generelt at …
… bruge frames
… modsætte dig standarder for navigering og strukturering
… tænke avanceret – simpelt er som udgangspunkt bare federe!
4: Problemknusning
Find svaret på dine tekniske og visuelle spørgsmål ved at lade dig “inspirere” af andre.
Gældende artikler:
A List Apart (http://www.alistapart.com/)
Stopdesign (http://stopdesign.com/)
Oversigter (og blær):
Stylegala (http://www.stylegala.com/)
CSS Vault (http://cssvault.com/)
15. June 2005 kl. 13:19
Microsoft fik sidste år lavet en undersøgelse, der viste, at op imod 57% af computerbrugerne mellem 16-64 år (altså ikke de allerældste) ville have gavn af tilgængelighed. Hvis ikke det forklarer hvorfor, så ved jeg ikke, hvad der gør!?
5. March 2006 kl. 18:10
Godt overskueligt sammendrag, du har skrevet her Andreas. Jeg måtte jo grave lidt for at finde den artikel hos Microsoft som Peter refererer til.
Det er faktisk langt mere radikalt end Dansk Center for Tilgængelighed som har sagt at 25% af webbrugerne har problemer med dit netsted. Mere info i min blog artikel: 25% of all web users are disabled