Evaluering av nettsted tilgjengelighet

Del 2 av 3 (Grunnleggende Kontrolpunkt) 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 2

Introduksjon

Dette er den andre artikkelen av tre i en serie artikler som forklarer hvordan du utfører en evaluering av tilgjengeligheten til en nettside. For litt av bakgrunnen og for å sikre at du har programvarene som du bør installert, anbefaler jeg å lese Evaluering av nettsted tilgjengelighet del 1, bakgrunn og forberedelser før du starter på denne artikkelen.

Sjekkpunktene i denne artikkelen dekker visse tilgjengelighet aspekter som kan testes med automatiserte verktøy og annet som er relativt lett å sjekke manuelt.

En full tilgjengelighet evaluering er mer grundig og involverer flere sjekkpunkter, noe som vil være dekket i den tredje artikkelen i denne serien. Men disse grunnleggende sjekkpunktene er en god start:

  1. Valider HTML og CSS
  2. Ingen rammer, om du kan
  3. Programvare til automatiserte sjekk av tilgjengelighet
  4. Bilder og alternativ tekst
  5. Sikre at JavaScript er "unobtrusive"
  6. Øk tekststørrelse
  7. Se etter semantisk kode
  8. Skru av CSS
  9. Bruk Fangs til å etterligne en skjermleser

1. Valider HTML og CSS

Bruk W3C validatorene for å sjekke om HTML og CSS koden er gyldig. Det er veldig praktisk å bruke Web Developer utvidelsen for dette: Tools - Validate CSS og Tools - Validate HTML. Jeg anbefaler at du konfigurerer hurtigtastene for disse to, siden du kommer til å bruke dem ofte.

Selvfølgelig kan du også bruke W3C sine validator nettsider:

Merk at HTML koden til mange nettsteder som ikke er laget bra er vanskelig å validere fordi de mangler DOCTYPE eller ikke har character encoding (tegnkodingsmetode) angitt. For disse nettsidene kan det være nødvendig å legge koden inn i validatoren manuelt.

Enda verre er de nettstedene som fullstendig blokkerer tilgangen fra validatorer. Ja, jeg har faktisk sett nettsteder gjøre dette. Hvorfor du ville skjule et nettsted fra validatorer forstår jeg ikke. Uansett, for slike tilfeller må du bruke Tools - Validate Local CSS og Tools - Validate local HTML i Web Developer utvidelsen. Avhengig av hvor ugyldig HTML koden er, må du kanskje også bruke Tools - Validate Local CSS for noen nettsteder som ikke blokkerer validators - enkelte feil i HTML koden vil gjøre at CSS validatorer nekter å gjøre jobben sin.

Også HTML Validator utvidelsen kan hjelpe deg med å validere nettsteder som blokkerer W3C Markup validator. Dette gjøres uten å sende noe til en server, så dette er et godt alternativ for nettsteder som er bak en brannmur eller krever pålogging.

HTML Validator utvidelsen vil automatisk varsle deg om eventuelle feil og advare deg om mulige tilgjengelighet problemer for hver side som lastes i nettleseren. Du kan tilpasse nivået på tilgjengelighets advarsler i "Options"-dialogboksen. Du bør huske på at HTML Validator utvidelsen er basert på "Tidy", som betyr at det er tilfeller der den ikke oppdager visse feil som W3C Markup validator kan.

Vær klar over at gyldighet betyr ikke tilgjengelighet. Jeg har sett nok av nettsteder som bruker gyldig kode men fortsatt er langt fra å være tilgjengelig. Dette er særlig vanlig på nettsteder basert på visse typer CMS (innhold styringssystemer) som synes at sine utviklere har misforstått hensikten med å bruke web-standarder.

Hvorfor? Fordi gyldig kode er viktig å sikre enhet-uavhengighet, en av de grunnleggende byggeklossene i nettet. Å bruke gyldig kode er så nært som du kan komme til å garantere at informasjonen kan tolkes riktig med så mange enheter som mulig.

2. Ingen <frame> element, er det mulig

I Firefox, høyre trykk siden eller på "View Source" (vis kilden) for å finne ut om nettstedet bruker frames. Hvis siden inneholder frames, får kontekstmenyen i Firefox et alternativ kalt "This Frame" (denne rammen). Iframe-kode er litt vanskelig å finne siden du må også trykke innenfor området okkupert av iframe elementet for at "This Frame" skal vises. Heldigvis kan Web Developer utvidelsen sin Outline - Outline Frames lage rammer rundt alle iFrame elementene på siden.

Hvorfor? Selv om rammer (og iframe-kode) er ikke nødvendigvis helt utilgjengelige, gjør de generelt et nettsted mindre tilgjengelig og brukervennlig, og bør unngås. Frames er også en indikasjon på at nettstedet ble bygget av en web-utvikler med en mangel på forståelse av både tilgjengelighet og brukervennlighet. Les artikkelen min Who framed the web - frames and usability for mer info om hvordan frames påvirker brukervennlighet.

3. Automatiserte program som sjekker tilgjengelighet

Automatiserte program til sjekking av tilgjengelighet har en tendens til å bli brukt hovedsakelig av tilgjengelighet nybegynnere. Det er fullt forståelig - ville det ikke vært flott om du å sjekke hvor tilgjengelig et dokument er var så enkelt som å bekrefter det med en validator? Problemet er at de eksisterende automatiserte programmene til evaluering av tilgjengelighet er langt fra perfekte og bør ikke brukes som grunnlag.

Disse programmene vil bidra til å avsløre noen problemer, og kan brukes som en veiledning for å få en rask og svært generell oversikt over tilgangen til en nettside. Derfor tror jeg at å sjekke deres mening om nettstedet er verdt det. Bare vær oppmerksom på at det er mange mulige tilgjengelighets problemer som disse verktøyene vil ikke kan finne, og de vil av og til rapportere problemer som egentlig ikke er problemer. En manuell oppfølging er alltid nødvendig.

Følgende automatiserte program skal derfor ikke helt stoles på, men i det minste de kan gi deg et hint om nettstedet er tilgjengelig eller ikke, og hvilke områder som kan være mer problematisk:

Og bare for å gjøre det klart: Et nettsted som består alle automatiserte tilgjengelighets sjekk er ikke nødvendigvis tilgjengelig.

Hvorfor? Automatiserte programvare hjelper deg med å oppdage problemer med tilgjengelighet som kunne ta mye lengre å finne med å gå gjennom koden manuelt. Sørg for at du evaluerer rapporten som lages automatisk og sjekk områdene som er merket som problematisk.

4. Bilder og alternativ tekst

HTML validatorene og programmene som sjekker tilgjengelighet automatisk som er nevnt her vil fortelle deg om noen bilder eller Bildekart mangler alternativ tekst, siden alt attributt er nødvendig. Hvis validatoren ikke rapporterer eventuell mangel på alt attributter, vet du at alle bildene i dokumentet har en alt-attributter. Men det kan fortsatt være problemer, så må du sjekke hvordan alt attributt blir brukt.

Bruk "Web Developer" utvidelsen for å vise alternative teksten i eventuelle bilder i dokumentet: Images - Replace Images With Alt Attributes. Deretter prøver du å forstå siden uten bildene. Sjekk også at alternative teksten faktisk er synlig når bildene er slått av - mange nettlesere bruker tekst farge angitt for bilde (eller en av sine foreldre i koden) for å vise alternativ tekst. Hvis fargen er for nær bakgrunnsfargen som vises når bildet mangler, blir alternative teksten svært vanskelig eller umulig å lese. Dette oppstår hovedsakelig på nettsteder som bruker mye bakgrunnsbilder.

Mange misforstår Alt attributtet. Det er ment å gi meningsfylte, informativ tekst som skal brukes som et alternativ når et bilde som inneholder informasjon eller annet grafisk objekt kan ikke vises. Det er ikke ment å gi teksten som vises i en "tooltip". ALT-attributtet er nødvendig for img og area element.

Informative bilder burde ha en kort beskrivelse av bildet. Dekorative bilder burde ha tom alternativ tekst. Jeg har sett nettsteder som i et feilretter forsøk prøver å være nyttige med å ta mye hensyn til å beskrive hvert dekorativt bilde og spacer GIF i detalj. Du må bare besøke en nettside som dette en gang med en skjermleser eller en nettleser som bare viser tekst for å innse hvor irriterende dette kan være.

For en mer detaljert beskrivelse av alt-attributtet og det liknende title attributt, foreslår jeg at du leser artikkelen min The alt and title attributes. Litt hjelp med å avgjøre om et bilde er opplysende eller dekorativt kan finnes i Dimitri Glazkov sin artikkel Keeping “pretties” out of content.

Hvorfor? Fordi om alternativ tekst ikke er angitt, eller hvis det er angitt feil, vil alle som ikke kan se bildene enten gå glipp av informasjon eller bli oversvømmet av unyttig informasjon.

5. Upåtrengende bruk av JavaScript

Det er på tide å sette Web Developer utvidelsen til bruk igjen. Slå av JavaScript (Disable - Disable JavaScript), så prøv å bruke nettstedet. Noen områder er umulig å bruke når JavaScript ikke er tilgjengelig. Blant offentlige nettsteder er det vanligste problemet jeg har sett navigering som krever JavaScript for å fungere. Mange bruker også JavaScript for å laste stilark (etter å først sniffe etter nettleseren, som på 20 århundret), som betyr at du får en dokument uten stil dersom JavaScript er deaktivert.

Jeg bruker også Lynx, som ikke har JavaScript-støtte, for å teste om et nettsted er mulig å bruke uten JavaScript.

Hvorfor? Et anstendig antall mennesker har slått av støtte for Javascript eller bruker en nettleser som ikke støtter JavaScript. De bør fortsatt kunne bruke nettstedet.

Dette betyr ikke at du ikke kan bruke JavaScript. Det kan du definitivt. Du må bare sørge for at du bruker det fornuftig og upåtrengede, og sørge for grasiøs degradering hvis JavaScript ikke er tilgjengelig.

6. Øk tekststørrelse

For å sjekke dette må du fyre opp IE / Win eller ta en titt på CSS bruket på nettstedet. Du ser etter er hvordan skriftstørrelsen er angitt.

Skriftstørrelse spesifisert i en relativ enhet som em eller prosent sørger for at teksten kan gjøres større eller mindre i alle nettlesere. Hvis skriftstørrelsen angis i piksler kan ikke brukere av Internet Explorer til Windows endre skriftstørrelsen uten først å endre innstillingene i nettleseren, som svært få gjør.

Last derfor nettstedet i IE / Win hvis om du kan og prøv å forandre på størrelsen til teksten (Ctrl + rullehjul eller Vis - Tekststørrelse - Størst). Hvis ingenting skjer bruker sannsynligvis nettstedet piksler for å angi skriftstørrelse.

Hvis du ikke har tilgang til IE / Win, kan du ta en titt på CSS koden. Man kan igjen bruke Web Developer utvidelsen: CSS - Edit CSS. Se etter enheten brukt i hvilken som helst font-size erklæring. Hvis alt du ser er px, bruker siden ikke relative enheter (teknisk så gjør den det, men ikke for hensikten til dette dokumentet). Du har lysst å se em eller %.

Om nettlesere bør endre størrelsen på teksten som er spesifisert i piksler eller ikke er et helt annet spørsmål, og en som har vært diskutert i årevis. En slik diskusjon kan finnes i artikkelen min Setting font size in pixels.

Selv om skriftstørrelsen er angitt i en relativ enhet kan det fremdeles være problemer med å endre tekststørrelsen. Oppsettet må være utviklet på en måte som tar hensyn til muligheten for at de som besøker kan ha forstørret teksten noen hakk. Mange utforminger blir fort ubrukelige dersom tekststørrelse øker. Tydeligvis kommer alle utforminger til å ødelegges til slutt, men en god utforming burde kunne holde seg rimelig bra selv om tekststørrelse er økt noen hundre prosent. Det trenger ikke å se så bra ut som den gjør med normal tekststørrelse, men innholdet bør ikke forsvinne eller bli uleselig.

Om du bestemmer deg for å lage en font widget til å forandre på font størrelsen (som jeg ikke anbefaler), sørg for den største innstillingen er veldig stor. Ikke bare litt større enn standard skriftstørrelsen, men mye større. Hva er vitsen i å bruke tid på å lage slike ting hvis sluttresultatet ikke er så annerledes enn standarden?

Hvorfor? Fordi mange trenger eller ønsker større tekst for å kunne lese komfortabelt. De kan ha en synshemning, være over en alder av 40 eller foretrekke å lene tilbake i stolen mens de surfer på internettet.

7. Se etter semantisk kode

Å finne ut om nettstedet bruker semantiske kode, View - Source Code og se etter overskrifter (<h1> - <h6>), lister (<ul> <ol> <dl>), sitater (<blockquote> <q>), og vekt (<strong> <em>). Du kan vanligvis se dette ganske raskt siden nettsteder som ikke bruker semantiske HTML pleier å ha konstruerer som <span class="stortykkrødtittel"> Tittel </ span> derimot et dokumentet som er laget semantisk vil ha <h1> Heading </ h1>.

Hvorfor? Semantisk kode er viktig fordi det gir nettlesere en sjanse til å tolke og presentere innhold på en måte som er egnet for betydning som det har. Som en ekstra fordel, tenderer også søkemotorer å favorisere semantisk kode.

Riktig bruk av overskrifter forteller også enheter hvordan å opprette dokument disposisjonsnivå som kan være svært nyttig for brukere av skjermlesere.

Selv om ikke alle enheter kan bruke all semantisk informasjon de får, hvis en nettside ikke bruker semantiske kode til å begynne med det er umulig for en enhet å utlede noen mening fra teksten.

8. Skru av CSS

Skru CSS av ved hjelp av Web Developer utvidelsen igjen: Disabled - Disable Styles - All Styles. Dette lar deg se på strukturen i underliggende HTML koden med nettleseren sin standard styling.

Om svært lite skjer når du deaktiverer CSS, ser du sannsynligvis på et dokument som bruker <table> element og annet HTML kode til presentasjon. Du kommer sannsynligvis ikke til dette punktet uten å allerede ha funnet mange problemer med tilgjengeligheten i slik et dokument.

Hvorfor? Et tilgjengelig dokument skal velstrukturert, meningsfylt og lesbar uten CSS.

9. Bruk Fangs for å etterligne en skjermleser

Hvis du ikke har tilgang til et skjermleser program er en god måte å få en rimelig følelse for hvordan nettsiden du vurderer høres ut til dem som bruker en skjermleser å bruke Fangs. Fangs er en Firefox utvidelse (som jeg anbefalte deg å laste ned og installere i del en av denne serien) som emulerer en av de mest brukte skjerm leserne, men viser teksten i stedet for å tale den.

Hvorfor? Skjermlesere er viktige hjelpemidler. Å vite hvordan en skjermleser kommer til å uttale innholdet på nettsiden du tester kommer til å hjelpe deg med å finne ut ting som om rekkefølgen på innholdet gir mening, hvis lenker og overskrifter blir brukt, og om alternativ tekst brukes riktig.

Evaluering av resultatene

Etter å ha gått gjennom denne listen har du kanskje funnet mange virkelig alvorlig teknisk tilgjengelighet problemer med nettstedet. Hvis du selv er utvikleren burde du gjøre hva du kan for å løse eventuelle problemer du har funnet og gå gjennom sjekklisten igjen. Hvis du ikke er utvikleren, kontakt den som er ansvarlig for å utvikle nettstedet og la dem vite at du har funnet noen problemer som må vurderes.

Det er fortsatt mange potensielle tilgjengelighets problemer. I Vurdering av nettsted tilgjengelighet del 3, Enda Mer, den tredje og siste artikkel i denne serien, tar jeg en titt på ting som er vanskelige å teste med automatiserte verktøy, og krever litt mer tid til å vurdere manuelt, samt diskuterer jeg noe som ofte blir oversett når det er snakk om tilgjengeligheten: innhold.

Se Også

Evaluering av nettsted tilgjengelighet del 1, Bakgrunn og Forberedelse

Evaluering av nettsted tilgjengelighet del 3, Enda Mer