Introduktion til tilgængelighed og tilgængeligt webdesign lbc/14.4.2010/2.3.

Præsentationer af emnet: "Introduktion til tilgængelighed og tilgængeligt webdesign lbc/14.4.2010/2.3."— Præsentationens transcript:

1 Introduktion til tilgængelighed og tilgængeligt webdesign lbc/14.4.2010/2.3

2 Tilgængeligt Webdesign ”Web’ens styrke ligger i, at den er universel. Det er helt grundlæggende, at alle mennesker — uanset funktionsnedsættelser — har adgang” Tim Berners-Lee Opfinder af WWW, direktør for W3C Tilgængelighed er et spørgsmål om at give flest mulige mennesker i flest mulige situationer og fra flest mulige browser-teknologier adgang til web-baseret information

3 Det officielle fokus 1.Tilgængelighed af hensyn til mennesker med en række handicaps: –Syn, hørelse, bevægelse, tale, kognition, sprog, læring, neurologiske –Kombinationer af disse 2.Tilgængelighed af hensyn til ældre mennesker med aldersbetingede behov 3.Tilgængelighed af hensyn til brugere i al almindelighed

4 Status •Op imod 25% af alle brugere oplever problemer med tilgængeligheden •MeAC 2007 –5,3% af offentlige netsteder –0% af private netsteder •Danmark ligger ikke øverst •Lovkrav giver generelt lidt mere fokus og lidt bedre resultater

5 Status – Seneste undersøgelser •Nationale kortlægninger 2006, 2008, 2010 •Kortlægning 2008 –Fejl på alle ca 250 netsteder –Perfekt: 0% –Godt tilgængeligt: 6% –Jævnt tilgængeligt: 70% –Dårligt tilgængeligt: 24% •Bedst på Nettet –Bedst til blinde?

6 Tilgængelighed er et krav FN •FN’s handicapkonvention om handicappedes rettigheder (2006, 2009)FN’s handicapkonvention •FN’s Standardregler om lige muligheder for handicappede (1993) EU •Jun ’06: I 2010 skal det være •Sep ’05: Resultater, tak! •e-Inclusion (2003) •e-Government, Europæisk handicapår (2003) •e-Accessibility (2001, 2002) •Målsætning for eEurope (2000) •W3C retningslinjer USA •Præsidentdekret (2000) •Access Board retningslinjer •Section 508, 504, ADA Danske beslutninger •Åbne standarder incl. tilgængelighed obligatorisk (2008)Åbne standarder incl. tilgængelighed obligatorisk •IT og Telestyrelsens kortlægning af problems omfang (2006) •Regeringens handlingsplan for handicappedes it- og telebrug (2002) •Krav til alle statslige netsteder (2000) •Netpublikationer v2 (1999)?Netpublikationer v2 (1999)? •Det digitale Danmark (1999) •Regeringens IT-politiske handlingsplan på handicapområdet (1996) •Regeringsbeslutning om ligestilling og ligebehandling af handicappede (1993)

7 Tilgængelighed - Status Kilde: MeAC 2007

8 Tilgængelighed - Policy Kilde: MeAC 2007

9 Tilgængelighed - Status Kilde: MeAC 2007

10 Tilgængelighed - Policy Kilde: MeAC 2007

11 Retningslinjer og prioriteter •Internationale retningslinjer fra World Wide Web Consortium (W3C) –Web Accessibility Initiative (WAI) –Web Content Accessibility Guidelines (WCAG) –Authoring Tools Accessibility Guidelines (ATAG) –User Agents Accessibility Guidelines (UAAG) Brugeren oplever tilgængelighed UAAG Browsere, Media players ATAG Redigerings- værktøjer, editors, CMS WCAG Indhold, struktur, layout, interaktion

12 Retningslinjer og prioriteter •W3C prioriteter og overholdelse –Prioritet 1 – Skal overholdes (niveau A) –Prioritet 2 – Bør overholdes (niveau AA) –Prioritet 3 – Kan overholdes (niveau AAA) •Niveau AA (prioritet 1 og 2) er minimum; niveau AAA er ikke altid realistisk •Danske retningslinjer fra IT- og Telestyrelsen •EU anvender ligeledes W3C/WCAG •Nye og gamle W3C retningslinjer?

13 Obligatoriske standarder

14 Retningslinjer og prioriteter 2 •Ikke-W3C retningslinjer –Ikke-W3C teknologier •Indhold fra eksempelvis Microsoft (Office), Adobe (PDF, Flash), Open Office, andre •Hvis utilgængelige, så skal findes tilgængelige alternativer i W3C format •Dokumenterne skal følge retningslinjerne for det pågældende format •Leverandører er på vej med WCAG 2 supplement til sikring af tilgængeligheden til fx Word og PDF

15 4 principper for tilgængelighed 1.Opfattelig (perceivable) – information og brugergrænseflader skal præsenteres for brugere på måder, som de kan opfatte 2.Anvendelig (operable) – brugergrænsefladen og navigationen skal være anvendelig 3.Forståelig (understandable) – information og brugergrænsefladen skal være forståelig 4.Robust (robust) – indholdet skal være tilstrækkelig robust til at det kan præsenteres pålideligt på en bred vifte af bruger agenter, herunder kompenserende teknologier

16 Brugere er forskellige •Nogle kan ikke se, skelne farver, høre eller bevæge sig. •Nogle har svært ved at læse eller forstå tekst. •Nogle har ikke eller har svært ved at anvende tastatur eller mus. •Nogle har kun en tegn-baseret skærm, en meget lille skærm, en meget stor skærm eller en langsom Internet forbindelse. •Nogle anvender kompenserende teknologi. •Nogle kan ikke tale eller forstå det sprog, som et netsted er skrevet på. •Nogle kan være i en situation, hvor deres øjne, ører eller hænder er optaget af noget andet (fx fordi de kører bil, arbejder i støjende omgivelser, etc). •Nogle har en gammel browser, en browser som ikke er på top-2 listen, en tale-baseret browser, en tale-styret browser eller en helt anden teknisk platform.

17 EU eAccessibility/eInclusion Informationsteknologi er et tveægget sværd “Der er 37 millioner mennesker i EU med funktionsnedsættelser og der bliver stadig flere ældre. I takt med, at offentlige selvbetjeningsløsninger får større betydning for vores liv, løber disse grupper en alvorlig risiko for at blive socialt udstødt som følge af tekniske barrierer på Internettet. De fleste barrierer kan let undgås hvis udviklerne ville følge et simpelt regelsæt for indhold, struktur og programmering på netsteder.” EU Kommissionen 2002

18 Hvorfor utilgængelighed? •Uvidenhed –Forudsætter, at alle er som os selv –Anvender en top-1/top-2 browser –Har den samme opfattelse af ”intuitivt” –Anvender en almindelig PC med mus og skærm •Arrogante designere –Vi prioriterer ”lækkert” design og teknologi over tilgængelighed og brugervenlighed –Kan læse 7½pt grå på lys grå baggrund •Misforståelser –Vi tror, at tilgængelighed og design udelukker hinanden

19 Problemets omfang •Mennesker er meget forskellige, og de anvender web’en forskelligt –Mangler sanser eller motorik –Mange (ca 15%) er læsesvage, ordblinde, blinde, svagsynede, hjerneskadede,... –Mange (ca 10%) Anvender en anden platform (kompenserende hjælpemidler, Macintosh, ingen mus, PDA, SmartPhone, mobiltelefon,...) –Befinder sig i situationer, som gør dem ”handicappede” –Mere end 1.500 browsere og browser-versioner i omløb •I Danmark har op mod 1 mio mennesker problemer med utilgængelighed •Problemet bliver større når web’en skal være sikkerhedsnet

20 Det vi gør forkert: Eksempler på fejl •Anvender strukturelementer til layout (fx tabeller, overskrifter) •Illustrationer, interaktive kort, knapper og scripts uden beskrivelser (og andre medier uden alternativer) •Frames og sider uden titler •Tabeller uden strukturbeskrivelse •Utilgængeligt indhold (fx PDF og Flash) uden alternativer •Ikke-W3C formater (fx PDF), som ikke er tilgængelige •Linktekster, som ikke kan læses udenfor deres kontekst •Genbrug af linktekster •Pop-up uden advarsler •Fejl i koden (fx HTML, XHTML, CSS, Javascript) •Sider, der ikke giver mening når stylesheet ignoreres •Siden mangler identifikation af markup format •Fejl i den hierarkiske, nestede struktur •Formularer hvor labels og felter ikke er knyttet sammen •Netsteder anvender absolutte angivelser af størrelser og placeringer. Forudsætter fx faste dimensioner/ombrydning (800*600) •Netstedet indeholder frameset uden NOFRAME eller uden filhenvisning •Faste farver, skrifttyper og skriftstørrelser •Mangelfuld kontrast og for små skrifttyper •Inkonsistent struktur (orientering, navigation, valg) •Forudsætning om standard hardware (PC, mus, tastatur, skærm) •Forudsætning om bestemte features i browseren (versioner, platform) •Indhold, som er tagget forkert, og som fjernes af software firewall

21 Type af problemer (Web) •Nogle problemer skabes af systemerne og af udviklerne –Fx tabel-layout, HTML-fejl, linktekster/URL- genbrug, scripts, faste dimensioner, … •Andre skabes af designerne –Fx ringe kontrast, små bogstaver, dårlig navigation, … •Atter andre problemer skabes af redaktørerne –Fx dokumentproduktion, copy/paste fra Word, billeder uden ALT, uforståeligt sprog

22 Type af problemer (dokumenter) •Nogle problemer skabes af systemerne –Fx utilgængelige auto-generede dokumenter, dårlige skabeloner, forkerte pdf værktøjer, … –Manglende skabeloner •Andre problemer skabes af medarbejdere –Fx forkert anvendelse af skabeloner og værktøjer, uheldig publiseringspraksis •Atter andre skabes af eksterne leverandører af dokumenter –Konsulenter, grafikere, … –Syndikerede dokumenter, …

23 Tilgængelighed Top Tre (Web) 1.Navigation ved hjælp af tastaturet 2.Kontroller og ledetekster er knyttet sammen 3.Alt ikke-tekstligt indhold er forsynet med alternativ tekstlig beskrivelse 4.Anvend valid kode

24 Tilgængelighed Top Tre (dok) 1.Velstrukturerede dokumenter 2.Korrekt opmærkning –Adskillelse af præsentation og indhold/struktur –Opmærkning af struktur –Opmærkning af sprog 3.Tekstlige alternativer til illustrationer 4.Meningsfuld læserækkefølge

25 PDF dokumenter •PDF = Portable Document Format •Oprindeligt proprietært format fra Adobe; nu standardiseret •PDF er mange forskellige ting •To hovedtyper af PDF dokumenter 1.Dokumenter skabt fra tekstbehandlings- eller DTP-program Tilgængelige for de fleste 2.Dokumenter skabt fra scanning Utilgængelige for de fleste

26 PDF fra Word og lignende •Kildedokumentet –Skal være velstruktureret –Skal være korrekt opmærket med klar adskillelse af indhold og struktur –Sprog/sprogskift skal være angivet –Det resulterende dokument skal være i Tagged PDF –Tags kan tilføjes senere; anbefales ikke –Sikkerhedsniveauet skal være korrekt (Content Extraction for Accessibility)

27 PDF fra Word og lignende (II) •Konverteringen –Ikke ligegyldigt hvorledes man skaber PDF filer –Dårlige: Printer drivere (Adobe PDF, CutePDF, …) –Gode: Microsoft gem-som-pdf, Adobe Acrobat Office Plug-in, Open Office Gem- som-pdf

28 Hvordan sikrer man ikke tilgængelighed? Eksempler fra virkeligheden •Tror på, at det sker af sig selv •Satser på ildsjæle i organisationen •Nøjes med at skrive det i kravspecifikationen •Får en blind til at teste •Tror på leverandørerne •Tror på, at man kan teste sig selv

29 Hvordan sikrer man tilgængeligheden? •Tilgængelighed kræver en strategisk beslutning •Tilgængelighed kræver prioritering •Tilgængelighed forudsætter en politik •Sikring af tilgængelighed er en proces Retningslinjer Tilgængelig løsning Definer standarder Implementer/køb i overensstemmelse med standarder Test i overensstemmelse med standarder Ledelse Uddannelse

30 Sikring af tilgængelighed er en proces ForberedelseUdbudIndkøbImplementeringOverdragelseDrift • Kurser og workshops i tilgængelighed • Strategisk rådgivning • Skabelon til tilgængeligheds politik • Bistand til formulering af krav- specifikation • Kvalitets- sikring af krav- specifikation • Bistand ved leverandørvalg • Faglig vurdering og vægtning af leverandører og deres besvarelser • Workshops i tilgængelighed • Vurdering af design • Vurdering af teknologi • Løbende test • Teknisk rådgivning • Formel validering af netsted i forhold til retningslinjer og kravspecifikation • Brugertest • Workshops for medarbejdere i publicering, dokument- produktion, pdf konvertering • Løbende test Sensus • Træf strategisk beslutning • Formuler politik • Deltag i kurser; workshops • Skriv generelle og specifikke krav i krav- specifikation • Kræv referencer og CV’er • Henvis til retningslinjer • Vægt krav til tilgængelighed som alle andre • Anvendt tredjepart til at vurdere • Vær kritiske overfor leverandørers påstande • Vær enige med leverandør om definition • Få tredjepart til at teste design og teknologi undervejs • Få tredjepart til at teste netsted undervejs • Få tredjepart til at teste alle krav til tilgængelighed som alle andre krav • Insister på overholdelse • Afsæt den fornødne tid • Uddan medarbejdere • Overvåg praksis • Planlæg løbende test af tilgængelighed Organisation

31 Automatisk validering? •Kan anvendes til at finde fejl •Kan ikke anvendes til at godtgøre tilgængelighed •WCAG1: Tjekker 20-25% af koden –Indiskutable brud –Mulige brud, som forudsætter manual validering –Mulige brud, som kræver fortolkning

32 Spørgsmål, kommentarer ?!