Evaluering av nettsted tilgjengelighet

Del 3 av 3 (Enda Mer) fra serien “Evaluering av nettsted tilgjengelighet”

Vennligst bemerk: denne siden er en norsk oversettelse av den andre delen av Roger Johannson sin 3-dels serie "Evaluating Website Accessibility" (Evaluaring av nettsted tilgjengelighet), beliggende her: Evaluating Website Accessibility part 3

Introduksjon

I Evaluering av nettsted tilgjengelighet del 1, Bakgrunn og forberedelse, ga jeg litt bakgrunnsinformasjon og foreslo noen nyttige program for tilgjengelighet evalueringsprosessen. I den andre artikkelen i serien, Evaluering av nettsted tilgjengelighet del 2, Grunnleggende Kontrollpunkt dekket jeg aspekter om tilgjengelighet som kan testes med automatiserte program, samt et par relativt enkle manuelle metoder.

I denne siste artikkelen i serien skal jeg forklare noen aspekter som er vanskelige å teste med automatiserte program, og krever mer tid og / eller erfaring til å vurdere manuelt. Noen av beskrivelsene i denne artikkelen forutsetter at du har lest de første artiklene, så hvis du ikke har lest dem, bør du gjøre dette før du fortsetter.

Denne artikkelen inneholder følgende sjekkpunkt:

  1. Farge kontrast
  2. Dokumenttitler
  3. Lenke text
  4. Ikke-HTML format
  5. Plattform diskriminering
  6. Navigasjon ved bruk av tastatur
  7. Data tabeller
  8. Form kontroller og etiketter
  9. Bruk en skjermleser
  10. Ikke overse innholdet
  11. Videre lesing

1. Farge kontrast

En enkel måte å sjekke om forskjellen i nyanse og letthet mellom forgrunn og bakgrunnsfargen er stor nok er å bruke Jonathan Snook sin utmerkede Farge Kontrast Sjekk program. Du kan enten angi heksedesimale tall for forgrunn og bakgrunnsfargen eller trekke skyveknapper og få informasjon øyeblikkelig om kontrast og farge forskjell.

Gez Lemon sitt Farge Kontrast Analyse program er lignende, og er også tilgjengelig som en utvidelse til Firefox.

Begge disse programmene bruker en algoritme som tilbys av W3C for å beregne farge synlighet.

Du kan også endre skjermen din til grå-skala eller svart-hvitt for å sikre at all teksten er lesbar. Hvis du bruker Mac OS X er det mange gode valgmuligheter for dette i "Universal Access"-valgpanelet. Den lar deg invertere fargene, sette skjermen til svart-hvitt eller grå-skala, og endre kontrasten. Hvis du vet om tilsvarende program for andre operativsystemer, kan du legge inn en kommentar og gi oss beskjed.

Hvorfor? Hvis det ikke er nok forskjell i farge og lysstyrke mellom forgrunn og bakgrunnsfargen kommer mange mennesker til å ha problemer med å lese teksten. Dette kan være fordi de har en farge mangel eller fordi de bruker en skjerm som er svart-hvitt eller bare gråtoner. Eller, som meg, har de perfekt syn, en virkelig god skjerm som viser 24-bit farger, men fremdeles problemer med å lese teksten fordi nettstedet bruker lys grå tekst på hvit bakgrunn.

Av samme grunn er det viktig å ikke stole på farge alene for å formidle informasjon. Linker, for eksempel, bør avvike fra omkringliggende teksten ikke bare i farger, men for eksempel også ved å bli fet eller understreket.

2. Dokumenttitler

Sørg for at hvert dokument har et unikt og beskrivende tittel og at tittelen ikke bruker overdreven tegnsetting.

Det finnes ikke regler som definerer hvilke tegn man kan bruke som skilletegn i tittel. Men, dokumenttitler bør definitivt ikke inneholde tegnsetting brukt kun til dekorative formål, for eksempel ":: Tittel ::" eller "... == Tittel == ...". Hvert skilletegn kan leses høyt av skjermlesere, som vil gjøre å høre tittelene svært langtekkelig. For noen eksempler om hva visse tegn høres ut som i JAWS, ta en titt på The Sound of the Accessible Title Tag Separator (Lyden av Tilgjengelig Tittelkodeverdi Skilletegn).

En annen skjermleser, Apple sin VoiceOver, leser "»" som "right pointing double angle quotation mark" (anførselstegnet med to vinkler som peker til høyre). Det utelukker dette tegnet ikke bare for bruk i dokumentet titler, men også i lenker, der det dessverre er ganske populært.

En diskusjon om ulike skilletegn til tittel finnes i Document titles and title seperators (dokumenttitler og skilletegn).

Hvorfor? Dokumenttitler er viktige av flere grunner: de er ofte det første som vises når man laster en ny side, den brukes også i nettleserens tittellinje, i bokmerker, og ved utskrift av dokumentet. Beskrivende dokumenttitler er svært nyttig for alle. De er også svært viktig for søkemotorsynlighet.

Lenker bør høres fornuftige ut om de ikke blir lest i sammenheng med resten av siden. "Klikk her" eller "her" blir derfor ikke god lenketekst siden er det ingen informasjon i det hele tatt om der lenken vil føre deg. Lenketekst som består av et helt avsnitt, noe som er vanlig på nettsider til aviser, osv. inneholder for mye informasjon og bør også unngås.

I hovedsak bør ikke samme teksten brukes på lenker som fører en til ulike destinasjoner. Ideelt skal hver lenke kunne forstås ut av sammenhengen. Noen automatiserte program til sjekking av tilgjengelighet advarer deg om dette.

Det finnes unntak til dette. Link tekster som "Les mer" eller "Fortsett lesing" kan være ok i en liste eller lignende, så lenge tittel attributtet brukes til å differensiere lenkene. Joe Clark forklarer hvorfor i hans intervju fra mai 2005 med Web Standards Group.

For å få en oversikt over alle lenkene i et dokument, kan du enten laste ned dokumentet i Opera og åpne "Links" vinduet, eller bruke "Links list" funksjonen i Fangs utvidelsen.

Hvorfor? Lenker er mer nyttige for alle hvis de består av beskrivende tekst. De fleste av folk som kan se ser først over nettsider for å få en rask idé av innholdet, og lenker er ofte en viktig del av dette innholdet. Lenker som er lette å forstå gjør dette raskere. Blinde og folk med dårlig syn kan ikke se over siden på samme måte, og i stedet bruker TAB tasten for å bla over lenker eller åpner de en liste med alle lenkene. Det hjelper det en god del å ha beskrivende lenketekst. Beskrivende lenker er også viktig for søkemotorsynlighet, så dette er enda en sak av tilgjengelighet som også gjør god SEO.

4. Ikke-HTML format

Hvis nettstedet gjør viktig informasjon tilgjengelig i PDF, Microsoft Word, Microsoft Excel, eller andre proprietære formater, bør HTML alternativer også være tilgjengelig. Merk at det ikke er noe galt med å gjøre informasjon tilgjengelig i ikke-HTML format så lenge det er også tilgjengelig som HTML.

Hvorfor? Mens det er mulig å gjøre innholdet i PDF-filer rimelig tilgjengelig for personer som har det nødvendige programmet, er HTML fortsatt det mest utbredte format som støttes, og bør alltid være det foretrukne valget. I tillegg har langt fra alle Microsoft Word eller Excel eller andre midler til å åpne dokumenter i disse formatene. Hvis informasjonen er kun tilgjengelig i en proprietær Microsoft-format (som ofte er tilfellet), er mange effektivt stengt ute.

5. Plattform diskriminering

Med plattform diskriminering mener jeg delvis eller helt begrenset tilgang til informasjon eller funksjonalitet for brukere av operativsystemer eller nettlesere som er minoritet. For dette sjekkpunktet bør du ideelt ha tilgang til flere forskjellige operativsystemer med flere nettlesere installert. Dette slags oppsett ikke er praktisk for mange, så du må kanskje bare bruke falsk brukeragent i nettleseren som bruker til testing.

Siden du bruker Firefox (som jeg anbefalte i Evaluering av nettsted tilgjengelighet del 1, Bakgrunn og Forberedelse, husker du), kan du installere User Agent Switcher Extension, laste ned en liste med brukeragenter, og du er klar.

Sjekk om nettstedet tillater brukeragenter annet enn Internet Explorer for Windows. Dette sjekker åpenbart bare om nettstedet bruker en slags nettleser sniffing som er basert på brukeragent strengen. Hvis diskriminering er basert på funksjoner som bare finnes på en bestemt plattform kommer ikke en falsk brukeragent streng til å hjelpe.

Plattform diskriminering kan være utilsiktet, men altfor ofte er det helt tilsiktet. Det er ekstremt sjeldent å finne et nettsted som diskriminerer mot brukere av Internet Explorer for Windows. De fleste Mac-og Linux-brukere, derimot, har sikkert opplevd å bli nektet tilgang til flere områder, fordi de bruker et "ustøttet" operativsystem eller nettleser. Dette er helt uakseptabelt.

Jeg hevder ofte at nettsted tilgjengelighet er et mye bredere problem enn å ta hensyn til funksjonshemmede. Plattform diskriminering er et utmerket eksempel på dette, og er faktisk den største faktoren som gjorde meg klar over hvor viktig det er for internettet å være tilgjengelig for alle. Få ting er så irriterende som å ikke få tilgang til informasjon bare fordi jeg bruker en Mac.

Hvorfor? Fordi en av de grunnleggende egenskapene til nettet er at det skal være uavhengig av maskinvare eller programvare bruket til å få tilgang til den. En web for alle, overalt, på hva som helst.

6. Navigasjon ved bruk av tastatur

Legg vekk muså for en stund og prøv å navigere nettstedet bare med å bruk av tastaturet, ved tabbing gjennom lenker og form kontroller. Merk at du må kanskje justere innstillingene i nettleseren for å kunne gjøre dette. Verken Firefox eller Safari har dette aktivert som standard. Fungerer det? Om det er drop-down menyer eller flyout menyer, sjekk om de kan aktiveres uten å bruke musa.

Hvorfor? Brukere av skermlesere bruker ikke mus til å navigere på nettet, så dette er veldig viktig for dem. Det er også mange som velger å bruke tastaturet, fordi de synes det er raskere og mer praktisk enn å bruke mus.

Avhengig av rekkefølgen i koden og størrelsen på dokumentet kan det også være svært gunstig for dem som ikke bruker mus om det er mulig å "hoppe" fram til innholdet. Hvis dokumentet inneholder et stort antall navigeringslenker før hovedinnholdet, kan en lenke som fører til starten av hovedinnholdet spare brukere av tastatur mange tastetrykk.

Et tilgjengelig nettsted er nødvendig å være utstyrsuavhengige og ikke måtte stole på at de besøkende skal bruke en bestemt inndataenheten, i dette tilfellet ei mus.

7. Data tabeller

Det er på tide å sjekke etter bruk og misbruk av <table> element. Web Developer utvidelsen er igjend hendig. Bruk den til å markere alle tabeller ved å velge Outline - Outline Table Cells og Outline - Outline Tables. Hvis siden ikke inneholder data i tabellform, burde ingenting skje. Hvis deler av siden som ikke inneholder data i tabellform blir markert, blir <table> element brukt for framføring og nettsiden består ikke denne testen.

Hvis siden faktisk inneholder data i tabellform, sjekk at det er merket opp som en tabell, og bruker korrekt og tilgjengelig kode. For informasjon om hvordan du bruker HTML-tabeller den rette måten kan du se artikkelen min Bring on the tables.

Hvorfor? Det burde ikke være noen <table> element brukt til presentasjon, og tabellform data skal være riktig merket opp med <table> som benytter seg av midlene til forbedret tilgjengelighet.

8. Formkontroller og etiketter

For dette sjekkpunkt må du åpenbart finne et nettsted som inneholder minst en form. Når du har funnet dette, sjekk at hver formkontroll har en etikett forbundet med den, at etiketter er korrekt merket med etikett elementer, og at etikettene og kontroller er i riktig rekkefølge (etiketten først, deretter kontroll, utenom alternativknappene og avmerkingsboksene som burde være kontrollen først og deretter etiketten).

Hvis formen bruker valgbokser for navigering sørg for at formen automatisk fyller (med JavaScript) når en er valgt. For tilfeller der JavaScript ikke er tilgjengelig, må du sørge for at skjemaet kan sendes inn, og at eventuelle klientside validering av tastet data håndteres av serveren. Automatiserte accessibility verktøy vil normalt varsle deg av form kontroller som ikke har en tilknyttet etiketten. Du kan også bruke Web Developer Extension: Skjemaer - Vis skjemainformasjon og påse at alle synlige form kontrollene har en tilknyttet etiketten. Hvorfor? Riktig etiketter hjelpe alle, siden det gjør de klikkbare område større. Hver synlig skjemakontroll bør eksplisitt knyttet til en etikett element.

Å sende en form automatisk når et alternativ blir valgt i en valgboks medfører problemer for brukere av kun tastatur. Å kreve JavaScript for å sende formen gjør det åpenbart umulig å sende formen om JavaScript ikke er tilgjengelig. Å være avhengig av JavaScript for input-validering kan føre til uventede verdier lagret i databasen.

9. Bruk en skjermleser

Først og fremst ønsker jeg virkelig å understreke at tilgjengelighet handler ikke bare om skjermlesere. Langt fra det. Å tilsvare nettsted tilgjengelighet med "fungerer i skjermleser X" er en veldig vanlig feil, og tilgjengelighet er egentlig mye mer enn det.

Nå for mer informasjon om skjermlesere. Hvis du kan se, er det svært vanskelig å forestille seg hvordan det er å bruke internett uten å kunne se det. Du kan prøve, men det er veldig vanskelig å holde deg fra å jukse. Du bør likevel prøve selv, og for å gjøre dette trenger du en skjermleser.

Hvis du bruker en Mac har du kanskje allerede en skjermleser - Mac OS X 10.4 og senere inneholder VoiceOver, Apple sin skjermleser. Den er ikke så avansert som noen av de andre skjermleserene som er tilgjengelige, men den er god nok til å gi deg en anstendig idé om hvordan en nettside høres ut til noen som ikke kan se det. Jeg har skrevet en artikkel som forklarer om bruke av VoiceOver for å surfe på nettet: VoiceOver and Safari: Screen reading on the Mac.

Hvis du ikke har en Mac med Mac OS X 10.4 eller senere, må du installere en skjermleser. De fleste skjermlesere ene er svært kostbare, så du må sannsynligvis nøye eg med en demo versjon. Her er en liste over skjermlesere som er tilgjengelig som demo-versjoner:

Hvorfor? alle de andre sjekkpunktene i denne serien tar deg svært langt når det gjelder tilgjengelighet. Men, å oppleve hvordan nettet er for en som ikke kan se er viktig fordi det vil gjøre deg klar over betydningen av mange av de ulike problemområdene jeg har nevnt.

10. Ikke overse innholdet

Hvis nettstedet du sjekker har bestått alle sjekkpunktene i denne serien, er det helt trygt å anta at området er teknisk tilgjengelig for alle. Dessverre, betyr det ikke nødvendigvis at innholdet er forståelig for alle.

Å skape og presentere innhold som virkelig er tilgjengelig for alle kan være svært vanskelig, og evaluering av dette aspektet av tilgjengelighet er utenfor omfanget av disse artiklene. Husk at dårlig eller usammenhengende skriftlig innhold kan være vanskelige å forstå, selv for svært intelligente folk.

Åpenbart kan forståelse av et nettsted bli enda mer problematisk hvis du har en form av kognitiv verdifall eller problemer med å lære. En artikkel om dette emnet som jeg anbefaler å lese er Developing sites for users with Cognitive disabilities and learning difficulties (Å utvikle nettsteder for brukere med kognitiv funksjonshemming og lærevansker). I artikkelen diskuterer Roger Hudson, Russ Weakley og Peter Firminger noen problematiske områder og gir noen forslag til hvordan man kan forbedre tilgjengeligheten for personer med kognitive funksjonshemming og lærevansker.

11. Videre lesing

Jeg anbefaler også å lese Web Content Accessibility Guidelines 1.0 og medfølgende Techniques for Web Content Accessibility Guidelines 1.0. De er store dokumenter og kan være litt, uh, utilgjengelige, men det ligger mye informasjon i dem.

Du bør også lese utkast til WCAG 2.0, og medfølgende Techniques for WCAG 2.0. Igjen, merk at WCAG 2.0 dokumenter er utkast og endrer trolig før de er sluttført.

Og til slutt, husk at tilgjengeligheten er ikke snakk om alt eller ingenting. Å gjør noe for å forbedre tilgjengeligheten er mye bedre enn å gjøre ingenting og håpe at ingen vil merke.

Se Også

Evaluering av nettsted tilgjengelighet del 1, Bakgrunn og Forberedelse

Evaluering av nettsted tilgjengelighet del 2, Grunnleggende Kontrollpunkt