For projektteam: At der på et meget tidligt tidspunkt i planlægningsfasen tages beslutning om mulige afviklingsplatforme og udviklingsværktøjer.
Her tænkes f.eks. på, at programmet skal kunne afvikles i et internetbaseret miljø uafhængigt af valg af (nyere) browsere og/eller uafhængigt af forskellige operativsystemer.
De anvendte udviklingsværktøjer skal give mulighed for uafhængigt af operativsystemet og/eller browser at kunne generere almindeligt brugte programelementer som menuer, knapper, dialogbokse m.m.
At informere om konsekvenserne af disse valg til øvrige projektdeltagere.
For programdesigner og programmør (udviklerne): De skal på et tidligt tidspunkt sætte sig ind i de valgte systemers muligheder og begrænsninger bl.a. med henblik på at kunne generere de nedennævnte egenskaber.
For projektteam: At der vælges udviklingsværktøjer, der på forhånd lader de i operativsystemet indbyggede indstillingsmuligheder for f.eks. handicappede nedarve til det udviklede program.
For udviklere: De skal på et tidligt tidspunkt sætte sig ind i de valgte udviklingsværktøjers muligheder og begrænsninger for at generere kode, som tager hensyn til indstillinger ved selv at håndtere dem eller ved at lade operativsystem/browser håndtere dem.
Ud over de for tilgængelighed specifikke, skal der tages hensyn til de generelle retningslinjer for layout.
Brugerne skal inddrages på et tidligt tidspunkt i et samarbejde med
den lokale Usability-gruppe både med hensyn til præsentation,
navigation, funktionaliteter og indhold.
En konsekvens heraf er, at der sker hyppige afprøvninger af de følgende punkter med deltagelse af relevante brugere og Usability-gruppe.
Designer og evt. Usability-gruppe skal med fra start og sammen lave et enkelt og brugbart layout, og heri skal der også indgå almindeligt anerkendte standarder og normer.
For udviklere: Overvej sammenhænge og evt. sekventiel anvendelse.
Tag hensyn til Windows Active Usability, IBM Accessibility Center: Software Accessibility mm., W3AI og SI i valg af opsætning af layout - f.eks. Begrænsning i anvendelse af tabeller ved web-design.
For forfattere: Overvej sammenhænge f.eks. ved tekster og tilhørende illustrationer.
For udviklere: Valg af farver/farvemuligheder. Specielt, hvor der anvendes skrift på grafiske elementer.
Ved vinduer, der indeholder skrift, bør der gives mulighed for brugerens egne indstillinger - fortrinsvis ved at benytte systemets indstillinger.
Undgå at overskrive eller ignorere systemindstillinger. Test ofte med ændrede systemindstillinger.
For udviklere: Lav en visuel markering af skærmbilledets fokus, eller vis overalt med hjælpeinstruktion eller andet, hvad der nu forventes af brugeren. (BCD)
For udviklere: Begræns antallet af skærmbilleder.
Giv overalt information om, hvor man befinder sig.
Benyt fast placerede navigationsmuligheder. (BCD)
For udviklere: Altid direkte adgang til navigationsmenuer. Altid mulighed for at gå tilbage (historie).
Alle navigationsmenuer /-knapper skal indeholde information om, hvor de fører hen. (BCD)
For udviklere: Overvej hvilke elementer, der skal kunne flyttes, hvordan og hvorhen de må flyttes. (BCD)
Er en evt. flytning temporær eller permanent?
For udviklere: Alle de nævnte elementer skal have kodet ekstra information i form af skærmtips eller referencer til hjælpetekst.
Den supplerende information laves allerede i designfasen. (BCD)
For forfattere: Der skrives supplerende information til alle visuelle elementer.
For udviklere og forfattere: Tekstinformation på grafisk form bør beskrives separat ved hjælp af henvisninger til beskrivelse (links) (f.eks. longdesc i web-produkter) og eller skærmtips.
Hvis der forekommer tekstinformation i illustrationer, bør denne anbringes som tekst oven på billedet, men ikke i grafisk form.
Hvis teksten laves på grafisk form, skal der være link til beskrivelse eller oplæsning.
For programdesigner: Der skal sættes plads af til, at brugeren kan få adgang til proceslinjen.
Der må ikke ligge knapper eller links i bunden af skærmbilledet.
For udviklere: Registrer alle værktøjer og funktioner og tildel dem til menupunkter og -grupper.
Tastaturgenveje skal så vidt muligt følge standarder for afviklingsplatform(ene), og man bør undgå at benytte de F-taster, der sædvanligvis benyttes til styring af eksterne programmer.
Hvis der benyttes F-taster til genveje, skal det være muligt at vælge alternativer til disse. (BCD)
For udviklere: Fastlæg tabuleringsrækkefølge for værktøjer og funktioner.
Hvis det er muligt, skal man angive tabuleringsrækkefølge, svarende til læserækkefølge.
For programdesigner: Skab mulighed for at slå de valgte alternative betjeningsmuligheder til og fra. - Helst af brugeren selv, alternativt via parametre eller særlige brugerprofiler.
Kontroller, at de alternative betjeningsformer ikke blokerer for vigtige dele af skærmbilledet. Lav evt. internt skærmtastatur. (BCD)
For programmør: Undgå at blokere eller ignorere læsningen af alternative betjeninger.
For udviklere: Find alle "ikke skriftlige" funktioner og lav en musebetjening til disse.
For udviklere: Programmet kan evt. starte med at rydde skærmfladen. Programvinduet begrænses, så der bliver plads til vinduer fra hjælpeprogrammer.
Alternativt gøres programvinduet skalerbart med mulighed for panorering eller samtidig skalering af alle programmets elementer.
Ved flere vinduer skal det være tydeligt for alle brugergrupper, hvilket vindue, der i øjeblikket har fokus. (BCD)
For udviklere: Alle billeder, der skal være skalerbare anbringes i skalerbare vinduer.
Eller også skal det være muligt for brugeren at udpege billedet og via en funktion i programmet vælge en større version af billedet.
For programdesigner: Udnyt systemmarkøren ved i alle tilfælde at tildele den et grafisk udseende passende til den aktuelle situation.
Overvej med andre ord i alle programmets dele, hvordan markøren bedst understreger opgaven - uden at markørens udseende dog alene kommer til at fortælle brugeren, hvad der forventes. (BCD)
For programmør: Undgå at gøre systemmarkøren usynlig.
Hvis muligt kodes markør, så gældende standarder for markører på afviklingsplatform(ene) overholdes i de forskellige situationer.
For udviklere: Hvis det er muligt, skal oplæsning af lyd aktiveres ved mouse-over eller ved at det pågældende skærmelement får fokus på anden vis.
Eller oplæsningen overlades til et evt. skærmlæsningsprogram. (BCD)
For programmør: Ved ny lyd: Evt. igangværende egen lyd afbrydes, og den nye lyd afspilles i en ledig kanal.
Når et brugervalg gør en lyd uaktuel, afbrydes lyden.
Lyd fra andre programmer, som f.eks. skærmlæser afbrydes ikke.
Hvis en del af programafviklingen skal vente på, at en lyd spilles færdig, må dette ikke blokere for brugerinput ved hjælp af mus og tastatur.
For udviklere: Undgå helt tidsbestemt respons, eller skab mulighed for at indstille responstiden generelt.
Vær opmærksom på, at dobbeltklik også under visse omstændigheder kan opfattes som en tidsbestemt respons!
For forfatter: Undgå at lave opgaver, der er afhængige af tidsbestemt respons.
For programdesigner/programmør: Lav modale meddelelsesbokse, eller skab mulighed for at indstille responstiden generelt.
For udviklere: Beslutning om, hvilke situationer, der skal udløse feedback, samt arten af feedback og effekter, der skal anvendes.
F.eks. tekstmarkør (caret) for aktuel position i tekst, indramning af aktuelle visuelle elementer.
Ved valg markeres valget med en effekt: knap, farve, highlight, invertering, lyd.
Visuel feedback skal så vidt muligt udnytte mere end én effektmetode og følge standarder for afviklingsplatform(ene). (BCD)
For udviklere/forfattere: Undgå brugen af farveinformation alene, eller træf beslutninger om alternative informationer.
Det kan måske ikke lade sig gøre at implementere (kode) alle de forskellige muligheder, der beskrives herunder, men kan det, skal man følge gældende standarder og retningslinier for, hvilke effekter der bruges - og helst flere end een ad gangen - og tage hensyn til, at effekterne kan være fravalgt med brugerindstillinger eller systemindstillinger!
For udviklere: Tag beslutning om, hvilke tilpasninger, der skal kunne foretages af brugeren.
For udviklere: Tag højde for i designet, at værktøjslinjer og menuer kan være slået fra.
Skab mulighed for igen at slå disse til uden brug af værktøjslinje henholdsvis menuer. (BCD)
For udviklere: Designet skal give mulighed for, at væsentligt programindhold ikke fjernes/klemmes ved valg af større ikoner og knapper.
For udviklere: Skrift må ikke kunne vælges i en størrelse, der gør det svært eller umuligt at anvende programmet, eller så væsentlig information forsvinder fra skærmbilledet eller forvanskes.
Farver må ikke kunne vælges, så teksten bliver usynlig mod sin baggrund.
Farver må ikke kunne vælges uden advarsel, så de giver konflikt med de problematiske farvekombinationer for farveblinde. (BCD)
For udviklere: Giv mulighed for, at eksterne editorer og afspillere kan udskiftes med andre. Giv evt. mulighed for, at brugeren kan teste en udvalgt editor eller afspiller mod de af programmet anvendte filformater.
I alle tilfælde skal kald ske ved, at så mange kaldsparametre som muligt angives i kaldet, f.eks. filnavne, hvor i fil man er positioneret, hvilken funktion det kaldte program forventes at udføre ved opstarten (aktuelt ved browser f.eks.).
I de tilfælde, hvor der anvendes interne afspillere, skal det sikres, at de nødvendige betjeningsfunktioner er til rådighed både fra mus, tastatur og evt. alternativ betjening. (BCD)
For udviklere: Giv brugeren mulighed for at vælge mellem forskellige muligheder for highlight.
Valg af highlight må ikke gøre teksten usynlig mod sin baggrund.
Valg af highlight skal så vidt muligt følge standarder og helst udnytte flere effekter på een gang. (BCD)
For udviklere: Giv brugeren mulighed for at vælge visning i positiv eller negativ eller evt. samme mulighed direkte ved det aktuelle billede - som ved markering af billedet. (BCD)
For udviklere: Give brugeren mulighed for generelt at slå indbygget speak af de forskellige tekster til og fra.
For udviklere: Designet må omfatte muligheden for, at al speak af tekster, der ikke i forvejen findes på skærmen, vises som undertekster, i talebobler eller lignende. (BCD)
For udviklere: Give mulighed for, at brugeren kan få information fra animationer i form af skrift og/eller tale og/eller et fast billede fra animationssekvensen.
For forfattere: Ved anvendelse af animationer i indholdsmaterialet, skal informationen derfra stilles til rådighed i skriftlig form og evt. som fast billede.
Lav alternative opgaver, hvis der laves opgaver, hvor bevægelsen (animationen) er vigtig for besvarelsen/forståelsen.
For udviklere: Beslutninger vedr. hjælpefil: Struktureret og menustyret eller kontekstafhængig eller blot et dokument med en vejledning.
Muligheder for alternativ hjælp i form af speak.
Adgang via menuer, knapper, taster?
Altid retur til det kaldende sted i programmet. (BCD)
For forfattere: Hjælpetekster skal holdes i et sprog, der er relevant for målgruppen.
For udviklere: Skal de to typer hjælp separeres og vises på hver sin måde?
F. eks. information i form af skærmtips og andre tekster tilknyttet elementerne, og instruktion i form af tekster i statuslinjen i bunden af programvinduet, som aktiveres ved roll-over eller fokus.
Eller skal de holdes sammen evt. også med ovennævnte generelle instruktion (i samme fil) for at gøre dem lettere at opdatere - og alligevel vises på hver sin måde?
Muligheder for alternativer f.eks. i form af speak. (BCD)
For forfattere: Instruktioner og informationer skal holdes i et sprog, der er relevant for målgruppen.
For udviklere: Beslutninger vedr. meddelelser: I hvilke situationer og hvor på skærmen de skal vises.
Skal meddelelser ledsages af særlige effekter? - F.eks. særlige lyde ved fejl.
Muligheder for alternativer f.eks. i form af speak. (BCD)
For forfattere: Meddelelser skal holdes i et sprog, der er relevant for målgruppen.
For udviklere: Der tilknyttes prædiktionslister til programmets indholdstekster.
Hvis det er muligt at generere disse lister automatisk ud fra markeringer/specielle koder i indholdstekster og/eller hjælpetekster, skal det ske der for at sikre konsistens med indholdet.
For forfattere: Der udarbejdes prædiktionslister til indholdstekster.
For udviklere: Tage stilling til, hvordan forskellige kategorier af brugere skal få adgang til at manipulere indholdet.
Undgå at blokere for eller ignorere alternative manipulationer med indholdet. (BCD)
For udviklere: Tag stilling til, hvordan den supplerende information skal kommunikeres til forskellige grupper af brugere. Alternativ tekst til billedet (alt og longdesc), billedtekst eller knap med oplæsning. (BCD)
For forfattere: Der laves supplerende tekstinformation til alle billeder.
Se endvidere under betjeningsfunktioner.
For udviklere: Undgå at blokere for eller ignorere systeminformationer. (BCD)
For forfattere: Undgå at benytte mange forskellige attributter.
Undgå også at benytte nestede attributter.
For udviklere: Hvis fokus flyttes uden for tekstfeltet, skal det let eller automatisk flyttes tilbage, når den kaldte funktion er startet eller afsluttet. Den skal desuden kunne positioneres frit i teksten.
For udviklere: Tage stilling til, hvorledes forskellige grupper af brugere skal kunne markere dele af indholdsteksten, samt kopiere og indsætte tekster.
Følg standarder og anvend helst flere end én mulighed, f.eks. både mus og genvejstaster. (BCD)
For udviklere: Om muligt bestemme et sæt grænser for zoom af indholdstekst samt placering af evt. rullepaneler.
For udviklere: Afsætte plads i skærmbilledet til placering af et videovindue.
Give mulighed for kald til eksternt program/plugin til præsentation af videoklip, eventuelt i særskilt vindue, med mulighed for at udskifte den valgte player.
For udviklere: Skabe forbindelse til styrefunktioner i evt. intern player, herunder evt. designe styreknapper eller tastaturgenveje til styring af afvikling af video. Video skal evt. deles i mindre sekvenser, som kaldes i rækkefølge. (BCD)
For forfatter: Overvej altid at have alternative opgaver, hvis der skal laves opgaver, der kun kan løses ud fra billedopfattelse/-billedforståelse eller lydopfattelse/-forståelse. (BCD)
For udviklere: Tage stilling til, om mængden af læst tekst afhænger af faste indstillinger, markeringer eller klik på ord, sætninger eller særlige betjeningsknapper.
Skal tekstvisningen styre oplæsningen, eller skal oplæsningen styre tekstvisningen?
Synkroniser om muligt speak og tekstvisning. (BCD)
For udviklere: Tage stilling til, om mængden af læst tekst afhænger af faste indstillinger, markeringer eller klik på ord, sætninger eller særlige betjeningsknapper.
For udviklere: Overvej brugen af orddelinger i indholdstekster sammen med forfatter.
For forfattere: Indholdstekster skal være logiske og enkelt opbygget.
Ordvalget skal ligeledes være enkelt og i et direkte almindeligt sprog.
Korte sætninger og afsnit.
Indholdet skal være alderstilpasset både med hensyn til tema og sværhedsgrad. (BCD)
For udviklere: Det skal være muligt at anbringe evt. illustrationer i logisk tilknytning til indholdsteksten.
For forfattere: Billeder skal være enkle i deres opbygning.
Billederne bruges kun til at forklare/uddybe tekstens indhold (BCD)
For udviklere: Lyd/speak skal være tydelig, letforståelig med passende hastighed osv.
Lydenhederne skal have en passende længde, og de må aldrig stå alene.
For forfattere: Når tekster skal kunne læses op, bør de eksempelvis ikke indeholde større tabeller, og sproget bør være tilpasset til talesproget.
Evt. bør der laves både en skriftlig indholdstekst og et særligt manus til speak. (BCD)