Retningslinjer for integrasjon av BankID-klient

Transkript

1 Retningslinjer for integrasjon av BankID-klient 29.august 2008 BankID samarbeidet 1

2 Dokumentet er utarbeidet på oppdrag fra Bankenes Standardiseringskontor av Eilev Hagen (epost eilev-at-stud.ntnu.no) og Kris-Mikael Krister (krismika-at-stud.ntnu.no) i Dokumentet skal betraktes som en overordnet veiledning og inneholder ikke noen full beskrivelse av emnet Universell utforming. Regelverk og teknologi kan endres og leseren bør derfor kontrollere alle slike referanser for endringer etter at dokumentet ble ferdigstilt. 2

3 Innhold 1 Introduksjon Målgruppe og formål Bakgrunn og motivasjon Innhold i dokumentet Definisjoner Ressurser W3C Deltasenteret Norge.no: Kvalitetskriterier Retningslinjer for integrering av BankID-klienten Generelt Generelle tips for universell utforming av nettsider Feilmeldinger ved inndata Kodevalidering Mer spesielle elementer og teknologi Før oppstart av BankID-klienten Mens BankID-klienten kjører Etter BankID-klient har fullført kjøringen Referanser

4 1 Introduksjon 1.1 Målgruppe og formål Dette dokumentet er en veiledning fra bankene om hvilke tiltak et BankID-brukersted bør gjøre for å sikre at tjenesten er tilrettelagt for alle brukere og i tråd med krav om universell utforming. Målgruppen er utviklere av nettsider som planlegger integrasjon av BankID-klienten. Dokumentet beskriver hvilke retningslinjer som bør følges for å sikre en så godt universell utformet løsning som mulig. Mye av innholdet i denne teksten kommer fra resultater funnet i prosjektarbeid ved NTNU vedrørende universell utforming av nettbank [3]. Under samling av bakgrunnsmateriale og under utformingen av denne rapporten har vi vært i kontakt med Norges Blindeforbund og bojo, som tilbyr blant annet IT-baserte løsninger for synshemmede. Vi ønsker å takke Karianne Havsberg og Øivind Rønning for tipsene og hjelpen de har kommet med underveis. 1.2 Bakgrunn og motivasjon Universell utforming er i dag forankret i lov om offentlig anskaffelser, og nye lovforslag på dette feltet er under arbeid i De nye lovforslagene vil gjøre at også privat sektor blir lovpålagt å være universelt utformet. Mer spesifikt sier den nye loven at all ny IKT (eller neste versjon av allerede eksisterende løsning) rettet mot allmennheten skal være universelt utformet fra 1. januar Den nye loven gjør at universell utforming har blitt mer aktuelt nå enn noen gang, og berører alle som jobber med å utvikle løsninger for allmennheten. 1.3 Innhold i dokumentet Denne teksten er delt opp i to hovedseksjoner. Den første, Seksjon 2, beskriver gode kilder for generell informasjon og råd om universell utforming av nettsteder. Dette kan være kilder for bakgrunnsinformasjon, men også mer praktiske råd. Seksjonen beskriver også noe av det arbeidet med universell utforming av nettsteder, som foregår i norsk offentlig sektor. Den andre, Seksjon 3, presenterer de mest sentrale punktene og retningslinjene som bør følges for å sikre at integrasjon av BankID-klienten er universelt utformet. Vi legger trykk på at det er de mest sentrale, siden dette ikke nødvendigvis holder i absolutt alle tilfeller. For å gjøre seksjonen så oversiktlig som mulig, er den delt opp i fire underdeler. Første del er generelle aspekter som er aktuelle, mens de neste er punkter som er sentrale ved henholdsvis like før BankID-klienten starter, samtidig som den kjører og etter den har fullført kjøringen. Tilfredsstiller nettsiden flesteparten av 4

5 punktene nevnt i disse delene, vil den ha et godt grunnlag for å være universelt utformet - og derfor være tilgjengelig for ``alle''. 1.4 Definisjoner For å unngå tvetydighet ønsker vi å definere følgende ord som er brukt gjennomgående i denne teksten. BankID-klient Bruker Universell utforming Lapp Ekstrautstyr Java-applet som sørger for personautentisering. Person som anvender nettsiden til ett eller flere av formålene den er ment til. Utforming av produkter og omgivelser på en slik måte at de kan brukes av alle mennesker i så stor utstrekning som mulig, uten behov for tilpassing og en spesiell utforming. ``Alle'' betyr i denne sammenhengen de som er i stand til å, eller skal kunne benytte nettsiden for minst ett av formålene den er ment til Et HTML-element som beskriver formateringen av en nettside (muligens bedre kjent som ``tag''). Dette begrepet gjelder utstyr som gir assistanse for personer med særskilt behov. Taleoppleser eller leselist for svaksynte og blinde er et eksempel. 5

6 2 Ressurser Det finnes mange kilder for råd og veiledning som kan benyttes for å sikre at et nettsted er universelt utformet. Nedenfor følger en kort presentasjon av de ulike standardene og retningslinjene som vi anbefaler å bruke, og som denne teksten baserer seg på. 2.1 W3C World Wide Web Consortium (W3C) [11] er en gruppe som utvikler spesifikasjoner, retningslinjer, programvare og verktøy for å optimalisere internettet. Web Accessibility Initiative (WAI) [12] er en undergruppe av W3C som arbeider for å fremme tilgjengelighet på Internett. De arbeider da spesielt med å tilrettelegge Internett for personer med fysiske handikapp av forskjellige slag. WAI arbeider innen tre forskjellige områder av tilgjengelighet, men det er spesielt Web Content Accessibility Guidelines (WCAG) [13] som er interessant i denne konteksten. WCAG er retningslinjer for hvordan innhold på nettsteder skal presenteres, og vi vil påstå at dette er de viktigste retningslinjene som eksisterer for universell utforming av nettsteder. Det arbeides med en ny versjon av WCAG, versjon 2.0 [1], som da denne teksten ble skrevet eksisterer tilgjengelig som et utkast med sist oppdatering Denne har vært under utvikling over flere år, hvor det første utkastet ble publisert WCAG har tre prioritetsnivåer. Web-utviklere må tilfredsstille kravene for nivå 1 (merket ``A'' i WCAG-retningslinjene), de bør tilfredsstille kravene for nivå 2 (merket ``AA'') og de kan tilfredsstille kravene for nivå 3 (merket ``AAA'') for ytterligere å bedre tilgjengeligheten. I denne teksten er det lagt hovedvekt på nivå Deltasenteret Deltasenteret [2] er den norske stats kompetansesenter for deltakelse og tilgjengelighet for mennesker med nedsatt funksjonsevne. Deres mål er deltakelse og tilgjengelighet for alle, uavhengig av funksjonsevne. Deltasenteret arbeider med universell utforming innen IKT-systemer, bygninger, uteområder og transport. De har gitt ut tre publikasjoner som omhandler tilgjengelige nettsteder. ``Oversikt og innholdsproduksjon'' [7] inneholder en introduksjon til temaet, ``Design og koding'' [8] tar for seg det tekniske og ``Anskaffelse og kvalitetskriterier'' [9] tar for seg innkjøp og tilgjengelighetskrav. 2.3 Norge.no: Kvalitetskriterier norge.no [5] har siden 2004 jobbet med å øke kvaliteten på offentlige nettsteder. De utarbeider årlig kriterier for vurdering av kvaliteten på nettsteder. Disse kriteriene er 6

7 basert på WAIs [12] retningslinjer og oppsummerer mange av de viktigste kravene som angår universell utforming. Referansene i dette dokumentet refererer til 2007-utgaven av norge.no sine kvalitetskriterier. Vi gjør oppmerksom på at nummereringen på kriteriene kan avvike noe fra senere versjoner. 7

8 3 Retningslinjer for integrering av BankID-klienten Denne delen tar for seg aspekter som er sentrale for universell utforming av nettsider, og vil gi retningslinjer på hvordan tilrettelegge for at alle kan benytte nettsiden. 3.1 Generelt Følgende punkter oppsummerer kort denne teksten, og kan bli brukt som en overordnet liste for å undersøke om et nettsted er universelt utformet eller ikke. Skill form og innhold (CSS og HTML hver for seg). Benytt kort, men beskrivende alternativ tekst til ikke-tekstlige objekter. Angi alle størrelser i relativ størrelse for å støtte forandring i skriftstørrelse. (CSS: em, %) Unngå å meddele informasjon og tekst på et unødvendig komplisert nivå. Skriv korrekt HTML og bruk valideringsverktøy for å forsikre deg om dette. Gi assistanse til bruker slik at feil i inndata unngås eller gi hint om hvordan rette dem om det skjer. 3.2 Generelle tips for universell utforming av nettsider Undersøkelser gjort [3, 7] tyder på at det er visse problemer som ofte går igjen ved nettsteder når det gjelder å være universelt utformet. De mest vesentlige er listet opp under med en kort beskrivelse av hvilke konsekvenser dette har for universell utforming og hvorfor de må unngås. Hvilke retningslinjer fra WCAG hvert punkt gjelder er i tillegg listet opp sammen med det aktuelle punktet. Sjekkpunkt 1: Manglende alternativ fremvisning av ikke-tekstlige objekter. Personer som ikke er i stand til å se objekter på nettsiden har behov for en forklarende alternativ representasjon i form av tekst. De fleste elementene i HTML støtter slike egenskaper uten at det står i veien for det opprinnelige elementet. De vanligste elementene dette gjelder er en normal lenke, <a> som kan suppleres med attributtet 8

9 TITLE, og bilde-lappen kan anvende attributtet ALT for å gi en alternativ beskrivelse dersom bildet ikke kan vises eller sees. Skjemafelter kan ta i bruk LABEL-attributtet for å oppnå en lik effekt. Et viktig poeng her er at feltene må gi en beskrivelse av hva det faktisk viser, så konsis som mulig og ikke tvetydig eller av unødvendig komplisert art. Følgende er et eksempel på hvordan linker og bilder kan utformes med alternativ fremvisning. <a href="hund.jpg" title="se bildet av hunden min i full storrelse."> <img src="hund.jpg" alt="hunden min" class="thumbnail" /> </a> WCAG punkt og ``Design og koding'' side 28 Sjekkpunkt 2: Nettsiden skaleres ikke ved forstørring og forminskning fra nettleser. Svaksynte kan ha behov for at forstørring av nettsiden er mulig, og at utformingen av nettsiden gjør dette mulig fra en nettleser. Det vil typisk bety at hele siden kan forstørres, og ikke bare visse elementer som tekst. Dette løses ved å spesifisere størrelser i relative størrelser (Definer størrelser gjennom CSS i relativ størrelser som ``em'' eller ``%'') og ikke faste størrelser som ``px'', ``pt'', ``mm'' og liknende). WCAG punkt Sjekkpunkt 3: Klikkbare felt er for små i forhold til resten av siden. Dette gjelder spesielt når lenker er utformet som ikoner, men også for alle lenker og elementer som kan klikkes på, inkludert tekstlige lenker. Tekstlige lenker som er sentrale for å kunne navigere på nettsiden må ikke utformes på en slik måte at de blir gjemt unna for svaksynte. Sjekkpunkt 4: Kildekode validerer ikke kravene til HTML og CSS. Eksterne hjelpemidler, som leselist og taleopplesingsapplikasjoner baserer mye av sin 9

10 funksjon på at nettsteder er korrekt kodet og strukturert i følge W3C sine retningslinjer [11] for både HTML og CSS. Les mer om dette i Seksjon 3.4. Sjekkpunkt 5: Hjelp brukere å unngå feil I felter hvor brukere skriver inn tekst som krever syntaks, burde applikasjonen være av en slik art at den skal kunne gi kontekstsensitiv hjelp til brukeren slik at mest mulig feil unngås. Applikasjonen bør også rette trivielle inndatafeil og gi godt forklarende feilmeldinger dersom noe uventet oppstår. Dette er viktig for å gi brukerne som ikke nødvendigvis er familiære med nettstedet en indikasjon på at noe har gått galt, og også hva som eventuelt må gjøres for å rette opp i feilen. Hvordan en feilmelding skal presenteres er forklart i Seksjon 3.3. WCAG 2.0 punkt Sjekkpunkt 6: Benytt HTML-lapper til å vise hvor man er i navigasjonstreet og eventuell kontekst Tilleggsutstyr benytter visse HTML-elementer sentralt, og disse må brukes korrekt og konsekvent. Under integrasjonen til BankID-klienten er det viktig å benytte eksempelvis <TITLE>-lappen på en slik måte at den gir indikasjon på hvor man befinner seg i innloggingsprosedyren og ved en vellykket innlogging bør tittelen vise dette. For ekstrautstyr er dette informasjonen som vanligvis blir prosessert for brukeren først. En god tittel (i <TITLE>-lappen) etter en vellykket innlogging er eksempelvis: ``Sparebanken Bank Vellykket innlogging - Min side''. WCAG 2.0 punkt norge.nos kvalitetskriterie 2.12 ``Design og koding'' side 18 ``Verdensveven for alle'' [6] side 29 Sjekkpunkt 7: Fokuser skjemafelt som krever inndata 10

11 For mange personer som har vanskeligheter med å bruke mus eller tastatur er det fordelaktig å unngå unødvendig fysisk interaksjon med nettsiden og første felt i en skjemagruppe bør automatisk bli fokusert for å tilfredsstille dette. Dette løses med Javascript: <body onload="setfocus();"> </body> <script> var usernamehasfocus = false; var passwordhasfocus = false; function setfocus(){ if( busernamehasfocus == false && bpasswordhasfocus == false){ document.getelementbyid("username").focus(); } } </script> <form> <input onfocus="usernamehasfocus = true;" onblur="usernamehasfocus = false;" type="text" id="username" /> <input onfocus="passwordhasfocus = true;" onblur="passwordhasfocus = false;" type="password" id="password" /> </form> Merk at dette vil ødelegge for en eventuell ``usynlig'' meny som er beskrevet i sjekkpunkt 10, da første element som er fokusert på siden er innloggingsfeltet - og ikke menyen øverst på siden. WCAG 2.0 punkt Sjekkpunkt 8: Oppretthold en konsistent navigasjon For å unngå forvirring burde navigasjonsmuligheter på nettstedet ikke forandre stil 11

12 verken før, under eller etter BankID-innloggingen. Det skal til enhver tid være lett forståelig å se hvor man er i nettside-strukturen. Dette kan løses ved å ha et ``Du er her'' felt sentralt på siden: Du er her: Start -> Forsikring -> Bil WCAG 2.0 punkt Listen i WCAG-punktet er av en generell art og nettsteder har store avvik i hvorvidt dette blir opprettholdt. Samtlige punkter er aktuelle for å kunne tilby tjenesten så godt universelt utformet som mulig, men alle trenger ikke nødvendigvis å være gjeldende for alle nettsider som skal integrere BankID-klienten. Sjekkpunkt 9: Skill form og innhold Hovedpoenget her er å separere utseende skrevet i CSS og innhold skrevet i (X)HTML. Dette er en svært generell retningslinje, som ikke nødvendigvis er triviell å få til i et allerede implementert system, men det er likevel grunnleggende for å kunne oppnå tilgjengelighet for alle på en gjørbar måte. ``Verdensveven for alle'' side 21 Sjekkpunkt 10: Mulighet for å hoppe over faste elementer/menyer og gå direkte til innhold Da menyer vanligvis kommer før innholdet på en side, blir dette prosessert hver eneste gang brukeren laster en side av nettstedet. En taleoppleser tar som regel for seg nettsidene sekvensielt, og få har derfor slitt seg gjennom nettsidemenyer oftere enn brukere av taleopplesere. Dette er ikke ønskelig, og for å hjelpe brukere av ekstrautstyr til å gå direkte til sidens innhold så anbefales det å lage en ``usynlig'' meny før noe innhold kommer, gjerne rett etter <body>. Man kan tro at skjuling av elementer ved bruk av display:none attributtet i CSS ikke vil skjule elementet for taleopplesere, men dette er ikke alltid tilfelle. Taleopplesere har blitt mer avanserte, og flere av dem tolker et element usynlighetsattributt ut fra stilsettet. Derfor må vår visuelt ``usynlige'' meny lages på en annen måte. Følgende er et eksempel på hvordan man kan løse dette i HTML med tilhørende CSS. 12

13 Tidlig på nettsiden: <a class="focusonly" href="#content"> Ga direkte til hovedinnholdet pa denne siden </a> <a class="focusonly" href="#menu"> Ga direkte til menyen </a> <a class="focusonly" href="/nettstedkart"> Ga til kart over nettstedet </a> Ved de aktuelle elementene: <a name="meny"><h1>meny</h1></a> <a name="content"><h1>innhold</h1></a> Tilhørende CSS: a.focusonly { width: 100%; float: left; position: absolute; top: -999em; left: -999em; } a.focusonly:active, a.focusonly:focus { top: 0; left: 0; } Ekstrautstyr vil tolke menyen, selv om den er usynlig for vanlige brukere. De skjulte lenkene vil også være synlige ved bruk av tastaturet for å navigere. norge.nos kvalitetskriterie 1.8 WAI punkt 13.6 Sjekkpunkt 11: Dårlig forklarende lenker Lenker som ikke har en forklarende lenketekst kan bli et problem for brukere av ekstrautstyr. Eksempelvis så kan forekomster av ``Les mer'' være svært lite forklarende, og kan i stedet virke frustrerende. En mulig løsning er å legge til ``om'' og 13

14 tittelen til siden som det lenkes til, eksempel: ``Les mer om BankID''. Lenker i midten av en setning kan også føre til problemer. Slik vil lenken ``betale regning'' bli lest opp hvis den finnes midt i en setning: ``Du må logge inn i nettbanken for å (pause) Lenke: betale regning (pause) og se betalingshistorikk''. Dette kan fort virke forvirrendes. ``Verdensveven for alle'' side 33 Sjekkpunkt 12: Unngå faguttrykk og kompliserte ord Så mye som 30% av den voksne befolkningen i Norge har en leseferdighet som er utilstrekkelig i forhold til kravene i dagens arbeids- og hverdagsliv [7]. Lange ord, fremmedord og vanskelige uttrykk kan lett skape problemer for disse, og taleopplesere har samme problem. All informasjon bør derfor formuleres kort og konsist, og være skrevet på en slik måte at det skal være forståelig for den generelle brukeren av nettsiden. Det bør for eksempel ikke brukes ordet ``applet'' om appleten, men heller ``tilleggsprogram'' eller ``applikasjon''. norge.nos kvalitetskriterie 2.13 Sjekkpunkt 13: Støtt flere språk Informasjon bør være tilgjengelig på alle språk som er aktuelle for nettsiden. norge.nos kvalitetskriterie Feilmeldinger ved inndata Dersom inndata blir validert eller sjekket før godkjenning, bør ikke-godtatt data presenteres på en god måte til brukeren. Dersom det er muligheter for å rette opp i feil eller det er tydelig hva som mangler, kan dette også foreslås for brukeren. Eksempelvis er et fødselsnummer som mangler ett siffer. Hva som definerer en god 14

15 presentasjonsmåte kan bli summert opp som følger 1. Vær så spesifik og konsis som mulig. Vær konstruktiv og indiker hva brukeren skal gjøre. Anvend konsistent grammatisk form og terminologi. Behold konsistent visning innad i nettsiden. WCAG punkt Kodevalidering For at spesialverktøy som er i bruk for å tolke nettsider skal fungere, er det vesentlig å følge kravene til struktur og innhold fremsatt av W3C [11]. Denne organisasjonen har flere valideringsverkøy, hvor de to mest sentrale er HTML-validering på og CSS-validering på Kodemessig kan WAI-retningslinjene også valideres, men dette kan gi en feil indikasjon. En positiv validering trenger ikke nødvendigvis å være fri for forbedringspotensiale ovenfor WAI og WCAG. Se likevel WCAG 2.0 punkt WAI 2.0 punkt Mer spesielle elementer og teknologi Det er visse teknikker og elementer og teknikker som kan være dårlig, eller ikke støttet i 1 Listen er utarbeidet for å fremme universell utforming, men basert på retningslinjer gitt av Ben Shneiderman [10]. 15

16 det hele tatt av ekstrautstyr. Man må derfor være påpasselig med at disse objektene minimum har en alternativ, tekstlig beskrivelse eller eventuelt inneholder ikke-vesentlig informasjon for å kunne anvende nettsiden. Dette er markert som viktig i WCAG under punkt i versjon 2.0. Eksempelvis er Flash, som ikke skal benyttes til noe som nettsidens funksjonalitet avhenger av siden blinde vil få minimal informasjon ut av et slik objekt. Dersom Flash benyttes, bør alternativ tekst skrives inn i <OBJECT>-lappen som vist under. Teksten bør beskrive hva Flash-objektet inneholder slik at personer som ikke er i stand til å se det kan unngå usikkerheten på om det er nødvendig informasjon eller ikke. Det samme gjelder andre tilsvarende objekter som video og film som krever avspilling lyd eller visning av bilde. <OBJECT TYPE="application/x-shockwave-flash DATA="fiskereklame.swf" WIDTH="400" HEIGHT="300"> <PARAM NAME="movie" VALUE="fiskereklame.swf" /> Fisk er det beste godteriet, spis mye av det! </OBJECT> Javascript, inkludert Ajax, kan også gjøre det vanskelig for hjelpemidler å tolke innhold på siden. I tillegg kan utstyrskrevende javascript-metodenr som onclick, onmouseover og liknende være problematisk for personer som ikke har for eksempel mus. Det jobbes med å integrere mulighet for tolkning av Ajax- og Javascript i ekstrautstyr, men det bør likevel anvendes på en slik måte at alternativt innhold kan vises dersom Javascript er slått av. Det er flere alternativer for å få til dette, og mye avhenger av nettside-implementasjonen. Generelt sett kan <NOSCRIPT>-lappen brukes for å vise alternativ HTML når Javascript er slått av, men best mulig alternativ representasjon kommer an på innholdet. Se lenken under for mer informasjon og eksempler. <SCRIPT TYPE="text/javascript"> <!-- // original javascript-kode //--> </SCRIPT> <NOSCRIPT> Alternativ representasjon av javascript-oppforsel </NOSCRIPT> ``Verdensveven for alle'' side Før oppstart av BankID-klienten Informasjon om innloggingsprosedyren 16

17 På innloggingssiden bør det gis informasjon om hva som kommer til å skje under innloggingsprosedyren. Det bør nevnes at BankID-innloggingen krever bruk av en applet, og at denne sannsynligvis krever en manuell godkjenning fra brukeren om at den får lov til å starte 2. Videre bør det også være informasjon om hva brukeren skal skrive inn i skjemaet til BankID-klienten, og i hvilken rekkefølge dette kommer til å skje. Eksempel på informasjon som gis (dette gjelder innloggingsprosedyre der bruker må skrive inn fødselsnummer i et vanlig skjema, før BankID-klienten starter).: ``For å logge inn må du gjennom to faser, hvor du skal skrive ditt fødselsnummer i den første. Deretter vil et tilleggsprogram starte, og visse maskiner ber om en godkjenning av deg for at det skal startes. Det kreves at du godtar dette for å kunne logge inn på nettbanken. Videre må du fylle inn generert sikkerhetskode fra din kodebrikke, og til slutt ditt personlige passord.'' Hvor informasjonen skal presenteres har ikke et konkret svar, men man bør riktignok unngå å bruke oppsprettvinduer da de kan medføre ulike problemer for svaksynte [8]. For nettsteder som benytter eget skjema for utfyllelse av fødselsnummer før oppstart av BankID-klient kan informasjonen plasseres på samme side. Nettsteder som starter BankID-klienten direkte uten en ``introduksjonsside'', kan plassere sentral informasjon over selve appleten, mens mindre viktige informasjonen under. I noen tilfeller vil nettleseren vise frem en dialogboks med spørsmål om brukeren vil starte BankID-klienten. Dette kan være en utfordring da denne dukker opp nokså fort etter at siden vises, og brukeren vil ikke ha hatt tid til å lese informasjonen om at en applet vil starte. En løsning på dette er å ha informasjon om appleten på en side man må besøke før siden med BankID-appleten kommer, men dette blir da på bekostning av ett ekstra lenkeklikk. Man ønsker som regel så få klikk som mulig for å navigere på et nettsted, derfor er det heller ikke optimalt å gjøre det på denne måten. Hvordan BankID er lagt opp på ulike nettsteder varierer, og gjør det derfor vanskelig å komme med generelle råd om hvor informasjonen bør plasseres. Dette må vurderes på hvert enkelt sted. Bruk av skjema Flere nettsider bruker et skjema der brukere skal fylle inn sitt fødselsnummer før BankID-klienten starter. For nettsider som bruker skjema (forms) er det sentralt å følge standardene slik at ekstrautstyr skal kunne tolke skjemaet på ønskelig måte. Følgende illustrerer et kodeeksempel i HTML for ett av problemene som kan oppstå. Ditt navn <input type="text" name="felta" /><br /> Din e-postadresse <input type="text" name="feltb" /> Her kan personer som ikke har mulighet til å se skjemaet tro at ``Din e- postadresse'' hører til feltet som kommer før teksten, altså ``felta'', og ikke ``felt B''. 2 Hvordan godkjenningen fungerer avhenger av Java-installasjonen, men vil i de fleste tilfeller være en oppsprett-boks som ønsker bekreftelse på at Java får lov til å kjøre. 17

18 Dette kan løses ved bruk av lappen ``label'', vist i følgende eksempel. <label for="felta">ditt navn</label> <input type="text" name="felta" /><br /> <label for="feltb">din e-postadresse</label> <input type="text" name="feltb" /> Man må også huske på at alle ikke har mulighet til å bruke musepekeren, men kun tastaturet til navigering. Retningslinjer for navigering i skjemaer og generelt om skjemaer finnes i HTML Techniques for WCAG 1.0 [4] kapittel Mens BankID-klienten kjører Selve BankID-appleten bør være integrert i nettside-utformingen slik at det er tydelig at den tilhører den aktuelle nettsiden. Eksterne hjelpemidler kan ellers få problemer, og oppsprett-vinduer bør derfor unngås også her. 3.8 Etter BankID-klient har fullført kjøringen Etter BankID-klienten har fullført sin kjøring bør siden der status over hvorvidt innloggingen var vellykket eller ikke, utformes som forklart i Seksjon 3.2. Eventuelle feilmeldinger bør også presenteres, og utformingen av disse bør være i samsvar med retningslinjer gitt i Seksjon 3.3. Om innloggingen ikke var vellykket, så bør det presenteres en mer detaljert forklaring om hvordan man logger inn via BankID enn det som er presentert før innloggingen. Etter denne informasjonen bør det være en link tilbake til BankID innloggingen, så brukerene kan prøve igjen uten å lete etter en vei tilbake. En utloggings-knapp/lenke bør være lett tilgjengelig på alle sider etter en vellykket innlogging. Et kjent problem med disse utloggingsknappene er at de er et bilde, uten alternativ tekst som forklart i Sjekkpunkt 1 i Seksjon 3.2. Referanser [1] W3C. web Content Accessibility Guidelines Sist besøkt

19 [2] Deltasenteret. Sist besøkt [3] Kris-Mikael Krister and Eilev Hagen and Stephan Haugsrud and Lars Petter Hansen and Sverre Grimsmo. Eksperter i Team - Universell utforming av nettbank. Sist besøkt [4] W3C. HTML Techniques for Web Content Accessibility Guidelines Sist besøkt [5] Kvalitetsvurdering av offentlige nettsteder. Sist besøkt [6] Norges Blindeforbund. Verdensveven for alle [7] Deltasenteret. Tilgjengelige nettsteder 1:3 - Oversikt og innholdsproduksjon. Sosial- og helsedirektoratet, [8] Deltasenteret. Tilgjengelige nettsteder 2:3 - Design og koding. Sosial- og helsedirektoratet, [9] Deltasenteret. Tilgjengelige nettsteder 3:3 - Anskaffelse og kvalitetskriterier. Sosial- og helsedirektoratet, [10] Ben Shneiderman. Designing the User Interface. Addison-Wesley, [11] W3C. W3C - The World Wide Web Consortium Sist besøkt [12] W3C. Web Acessibility Initiative (WAI) Sist besøkt [13] W3C. Web Content Accessibility Guidelines Sist besøkt