Et godt utviklet grensesnitt er en faktor som bidrar til å gi nettsteder god rangering i Googles søkeresultater. I tillegg er grensesnittet viktig i forhold til å gjøre nettsidene tilgjengelige for personer med funksjonshindringer. I USA er det tilfeller hvor bedrifter har blitt saksøkt for å slurve med grensesnittsprogrammeringen.
Jeg skrev for en drøy ukes tid siden et oppfølgingsinnlegg til mitt foredrag på Webdagene 2007. I innlegget kom jeg med noen konkrete krav du kan sette til grensesnittet når dere får det utviklet. Det jeg kanskje ikke var like klar på var akkurat hvordan man kan gjøre en sånn kontroll.
Alle kan gjøre det
Grunnleggende kvalitetssikring av grensesnitt er ikke vanskelig, og krever ikke noen voldsom teknisk innsikt. Det krever egentlig bare at du vet hvilke verktøy du skal bruke, og hvordan. I dette innlegget skal jeg ta for meg de viktigste punktene fra forrige innlegg og vise hvordan de kan sjekkes.
Obs: Å bruke disse verktøyene gir en god indikasjon, men grundig kontroll krever innsikt i teknologien bak (HTML eller XHTML, CSS og eventuellt Javascript, Flash og annet).
Validering
Alle sider skal validere som HTML 4.01 eller XHTML 1.0
Dette kan sjekkes ved å gå til validator.w3.org. Tast inn adressen til nettstedets forside og trykk Check. Programmet vil gi deg en rapport. Det er en viktig ting å se etter. Det ønskelige er at du får en grønn linje på toppen med teksten “This page is valid …”.
Andre varianter har en rød linje på toppen, med teksten “Sorry, this document can not be checked” eller “This page is not valid …”. Ingen av de røde variantene er ønskelige, får du en av disse bør du be om en forklaring.
Hvis tjenesten ikke er tilgjengelig på åpent nett har du to andre muligheter. Den ene er å se på siden du ønsker å validere i nettleseren. Velg så Fil -> Lagre som… og deretter webside, kun HTML. Denne filen kan så lastes opp til validatoren: validator.w3.org/#validate_by_upload. Den andre muligheten er å høyreklikke siden og trykke “Vis kildekode”/”View source” og kopiere all teksten i vinduet som kommer opp. Denne teksten kan limes inn på validator.w3.org/#validate_by_input og sjekkes.
Validering med Firefox
Nettleseren Firefox kan installeres med en rekke nyttige utvidelser for alle som jobber med web. Jeg har nylig laget en liste over mine favorittutvidelser til Firefox. Den viktigste utvidelsen på denne lista er Web developer. Med denne utvidelsen instalert kan du validere sider enkelt ved å trykke Ctrl+Shift+H. Hvis tjenesten ikke er tilgjengelig over internett kan du validere ved å la Web developer laste opp siden din – bare trykk Ctrl+Shift+A. Genialt!
Å validere enkeltsider er vel og bra, men det hjelper ikke mye hvis resten av nettstedet ikke henger sammen. Samtidig kan det bli veldig tungvindt å gjøre dette med hundrevis eller tusenvis av sider. Jeg har ingen gulltips for å validere hele nettstedet, men WDGs validator kan følge lenker på nettstedet og validere opp til 100 sider. Får du ikke noen feil fra denne er du på god vei. Et hot tips her er å sjekke av for “Validate entire site” og “Hide valid results”. På den måten får du kun beskjed om sider som ikke validerer.
CSS
CSS kan valideres manuelt på jigsaw.w3.org/css-validator/ eller halvautomatisk gjennom Web developer (trykk Tools, Validate CSS).
HTML skal ikke brukes til design
Implisitt her ligger det at det skal benyttes semantisk HTML. Det er to tester man kan gjøre for å få en pekepinn her.
Semantic Extractor
Ett verktøy er W3Cs Semantic extractor. Dette verktøyet leser HTML og henter ut data. Programmet er avhengig av semantisk HTML for å gjøre noe fornuftig. Se semantisk data fra www.ixd.no.
Verktøyet bør kunne trekke ut tittel, språk og et fornuftig sammendrag som et minimum. Spesielt sammendraget (“outline”) er viktig – hvis dette ikke gir mening er HTML muligens ikke brukt riktig.
Web developer
Du kan også bruke web developer til å se til at det ikke er lagt design i HTML. Trykk Ctrl+Shift+S. Denne tastekombinasjonen slår av CSS. Siden skal nå være helt hvit med svart tekst, og innholdet skal flyte sekvensielt nedover. Det eneste innholdet som skal stilles opp side-om-side er tabulær data som kan stilles opp i en tabell.
WCAG 1.0
W3Cs sjekkliste for tilgjengelighet kan ikke sjekkes fullstendig automatisk. Men, du kan benytte Smartlabs WAI-validator eller Cynthia says til å maskinteste det som kan maskintestes. Begge disse gir en rapport som du må gå over manuelt og sjekke opp de punktene som ikke er mulig for systemene og sjekke.
Oppsummering
Jeg har vært igjennom noen nyttige metoder og verktøy for å kvalitetskontrollere grensesnitt, enten det er du selv som lager det, det kommer fra andre i prosjektet eller det kommer fra ekstern leverandør. De viktigste verktøyene er:
5 kommentarer til "Kvalitetskontroll i praksis"
Som en ytterligere forlengelse til foredraget ditt på webdagene hvor det ble presenterte tall fra den uformelle undersøkelsen Eirik H. Rønjum har gjennomført om forventninger til, og reell kompetanse blant utviklere og designere synes jeg det er på sin plass å peke til norge.nos kriterier for kvalitet på nettsteder. Her finner de ikke fullt så webkyndige (les: kommunikatørene) et godt støtteredskap når de skal ha en kvalitetsgjennomgang av sitt nettsted, kriteriene kan også fungere som en del av en kravspek til et nytt nettsted.
I utgangspunktet er jo dette kriterier som er utviklet for offentlige nettsteder, men det er ingen grunn til at private nettsteder skal ha en annen praksis enn offentlige hva tilgjengelighet og brukertilpassning angår.
Her som over alt ellers skal man ikke stole blindt på et sett av kriterier og indikatorer, men de oppleves for mange som en nyttig pekepinn.
http://www.norge.no/kvalitet/kvalitet2007/kriterier.asp
Veldig bra! Mange av norge.nos retningslinjer er hentet rett fra WCAG som jeg gir konkrete tips til over. Mange av de andre kravene går på faktisk brukervennlighet og som du sier trenger hverken tilgjengelighet eller brukervennlighet å være noe som kun gjelder for det offentlige.
Det var ok tips du kom med, men jeg kan ikke se at (x)html og css validering har med ‘personer med funksjonshindringer å gjøre’. Tror ikke det er noen som blir saksøkt om sidene deres ikke valideres av w3. Det du vel egentlig skulle skrevet om ifølge innledningen er vel hvilke grep som kreves for at siden skal bli mer tilgjengelig for denne gruppen individer. Noen løser dette ved å gi brukeren mulighet til å forstørre teksten, eller forminske den, alt etter som, selv om alle har denne muligheten i utgangspunktet i nettleseren sin. Andre, som visse kommuner i Norge har løst dette ved å lage lesbar tekst av alt innholdet. Dette er noe som skulle vært diskutert, for jeg tror ikke noen med funksjonshindringer som nedsatt syn har det lett på nettet. Men så er vel dette nærmest den eneste gruppen, og de vil vel gi seg blanke f… i om siden ikke valideres korrekt, eller hva?
Poenget er enkelt og greit at en side som ikke validerer korrekt ikke er ment å vises for alle brukere, og de som eier nettstedet mister derfor brukere. Selv om noen overprøver definerte standarder er det vel stort sett ønskelig at så mange som mulig kan bruke nettstedet, og dette gjelder vel i størst grad for offentlige sider, etter som de ikke har et segment å foholde seg til. Poenget med w3′s valideringer er endelig at skal kunne se at man er innen for visse rammer, og nettsiden dermed vil vises tilnærmet likt på de fleste maskiner. F.eks. kan man i Firefox og Safari kjøre et a element (html lenke) rundt block elementer uten problem, mens denne lenken i Internet Explorer ikke ville bli vist. Kan du ikke forklare nærmere hvor stor påvirkning valideringer har å si for rangeringen hos google?
Validering er ikke det eneste jeg tar opp. Validering er viktig, fordi det er den eneste måten å programmatisk sjekke at koden er i henhold til standarder. En aktør som er seriøs på webstandarder og tilgjengelighet vil ikke sende fra seg kode som ikke validerer med mindre det er en god grunn til det.
Teknikkene som er gitt over er en rask måte å få en god indikasjon på om det er brukt korrekt og semantisk HTML. Semantisk HTML er grunnsteinen i tilgjengelige nettsider. Semantisk HTML handler om å bygge struktur i dokumentet på en mer generisk måte enn bare grafisk design (store fonter på overskrifter osv).
Når det gjelder automatiserte tjenester så som indekseringsroboter så er det lettere for disse å bruke en XML-parser fremfor en HTML-parser fordi XML-parseren ikke trenger å ta hensyn til alle feilene som er gjort og å forsøke å rette de opp. Slike XML-parsere vil få problemer med dokumenter som ikke validerer. Dokumentet ditt blir da mindre anvendelig om det ikke validerer (dette gjelder såvidt jeg vet ingen av dagens indekseringsroboter, men det gjelder for eksempel denne tjenesten).
Angående lenker med blokkelementer i så legger standarden opp til at lenker (som er inline-elementer) ikke kan inneholde blokkelementer, og IEs oppførsel kan derfor ikke klandres.