Under Webdagene 2007 pratet jeg om viktigheten av god kvalitet på grensesnittet, og jeg sa “stå på krava!” Her følger noen konkrete krav dere kan stå på.
Mitt innlegg handlet altså om utvikling, med prosjektledere, markedsansvarlige, webredaktører og flere som målgruppe. Jeg ønsket å gi ikke-tekniske mennesker en grunnleggende forståelse for tekniske problemstillinger slik at dere vet hva dere bør kunne kreve, og samtidig skal kunne vite at ikke alt man får er gull, selvom prisen man betaler ofte skulle tilsi det.
Under følger en sjekkliste som opprinnelig var tenkt delt ut under konferansen, men i stedet havnet den her, hvor jeg også kan skyte inn noen utfyllende kommentarer.
Krav til grensesnittsimplementasjon:
- Alle sider skal validere som HTML 4.01 eller XHTML 1.0
- Design og interaksjon skal være separert fra dokumentet
- All CSS skal være i eksterne CSS-filer
- All Javascript skal være i eksterne js-filer
- HTML skal ikke benyttes til design
- Kontroller ved å skru av stilsett i nettleseren (feks installer Firefox med Web developer og trykk Ctrl+Shift+S når du ser på en webside).
- All CSS skal validere
- Alle sider skal fungere med Javascript slått av. Der dette ikke er mulig finnes det en alternativ ikke-Javascript-side.
- Sidene skal fungere i nyere nettlesere, test med et mangfold.
- Nettsidene skal tilfredsstille WCAG 1.0, minimum alle prioritet 1-sjekkpunkter
Noen kommentarer
Det aller aller viktigste, både i forhold til tilgjengelighet, og det som går på rangering i søkemotorer (utover innhold, selvfølgelig) er semantisk HTML. Det går på at HTML ikke er brukt til design, og at de rette elementene er brukt til det rette innholdet. Dersom du forstår begrepet kan dette leses ut av koden, men har du ikke inngående HTML-kunnskap kan dette bli en utfordring.
Du kan benytte siden uten CSS til å gi deg en pekepinn. Når stilsettene er skrudd av skal ingen elementer ha farge eller bakgrunn utover svart eller hvit (henholdsvis). Videre skal det heller ikke være noen layout, innholdet skal komme sekvensiellt nedover. Se til at hovedoverskriften er den største, og at andre overskrifter på siden vises i stor font, og ikke bare fet tekst. (Merk: dette gjelder altså når stilsettene er av, designet kan gjøre som det vil i denne sammenhengen).
“Nyere nettlesere”
Dette punktet må vurderes i hvert tilfelle. Ideelt sett bør man bruke analyseverktøy for å se på dagens fordeling. Som et minimum, test med IE7, IE6, Firefox 2, Opera 9 og Safari 2. Fungerer tjenesten din godt i disse nettleserene har du sannsynligvis dekket over 99% av dine besøkende. Merk at dersom tjenesten er utviklet riktig, vil den sannsynligvis fungere godt i de fleste nettleserene som ble nevnt, muligens med unntak av IE 6, som av og til trenger litt egen “overbevisning”. Pass på å sjekke disse tingene.
Alt i alt
Dersom noen av punktene på listen over ikke kan tilfredsstilles bør du be leverandøren om en veldig god grunn til hvorfor. Ofte opplever vi at man blir nektet å implementere “drømme”-HTML fordi de som sitter på backendsystemene ønsker å bruke så mye standardisert kode som mulig. Husk at grensesnittet er viktig, og å forsømme det kan i verste fall bli en dyr affære i form av utilgjengelige løsninger som stenger potensielle kunder ute og/eller tapt trafikk fra søkemotorer.
4 kommentarer til "Kvalitetskontroller grensesnittet"
Flott innlegg! Validering av XHTML og CSS burde være en selvfølge, men dessverre er det heller unntaket enn regelen.
Men for å få XHTML og CSS til å spille på lag med IE 6 (og til dels 7) må man jo dessverre ofte ty til stygge hacks som ikke er med i CSS-standarden. Hvordan bør man stille seg til slik problematikk? Er validering viktigst og hvordan skal man håndtere dårlige nettlesere uten forståelse for standarder (les: Internet Explorer)?
Valget er jo dessverre enkelt, å utelate Internet Explorer fra dine nettsider er ikke et sjakktrekk selv om det kan gå på bekostning av absolutt validering.
[...] Steve Krug’s Don’t Make Me Think, a quick and good read btw, made me aware of an article entitled Guidelines for Accessible and Usable Web Sites: Observing Users Who Work, which gives good insight into why it is important to do things right on the front end (Norwegian literates should read this checklist for good quality UIs). [...]
Jeg opplever at det stort sett ikke er noe stort problem å få IE (6 & 7) til å spille på lag. Ja, det er irriterende, og ja, det er uinspirerende å prøve flere ting om i teorien burde fungere før man finner den ene løsningen som funker i IE. Men det går stort sett greit.
Jeg opplever vel så å si aldri å måtte lage (X)HTML som ikke validerer for å få Internet Explorer med på leken, men i noen tilfeller må man til med styggedom på CSS-siden for å få det til skikkelig (så som transparente png-er i IE6/5.5). Løsningen i disse tilfellene er grei: jeg bruker “conditional comments” som er helt gyldig og som gir meg muligheten til å fore IE med egen kode. På den måten kan man snike bort ikke-validerende CSS slik at kun IE leser den.
[...] Bygge nettstedet ditt teknisk korrekt [...]