Tilgængelighed af undervisningsmaterialer

Ovenstående påstand om programmører er for så vidt rigtig. De læser nødigt generelle retningslinjer for udvikling af programmer - førend de bliver tvunget til det.

Af retningslinjer vedr. kompensation for et tilgængelighedshandicap kan her nævnes nogle få:

• Trace software guidelines: Application Software Design Guidelines
• W3C: Web Content Accessibility Guidelines 1.0 og Access to Software and Information
• Microsoft Accessibility
• IBM Accessibility Center: Software Accessibility, Web Accessibility og Java Accessibility.
• Statens Information: Hjemmesiders tilgængelighed

Man kan hurtigt sætte flere meter hyldeplads af til retningslinjer, og i mange tilfælde er der tale om gentagelser, så det er forståeligt, at guidelines først læses, når det er ved at være for sent.

Derfor er der heller ikke indtil nu udviklet ret mange programmer, som følger de eksisterende retningslinjer for udvikling af software, der kompenserer for et tilgængelighedshandicap.

TAU (Tilpasning Af Undervisningsprogrammer for elever med funktionsnedsættelser) er et samarbejde mellem Hjælpemiddelinstituttet og UNI-C med støtte fra Undervisningsministeriet, Mediesektionen og Den Kommunale Momsfond.

Projektet har på flere forskellige måder arbejdet med kravene til undervisningsprogrammer, som skal kompensere for funktionsnedsættelser ved at gøre programmernes funktioner og indhold tilgængelige også for handicappede elever.

Med udgangspunkt i de mange eksisterende retningslinjer har vi i TAU-projektet forsøgt at lave et nyt sæt kravspecifikationer, som var så korte og konkrete, at de ville blive anvendt og læst - også af programmørerne.

Ud over at henlede programmørens opmærksomhed på problematikken skulle specifikationerne fungere som et brugbart redskab for beslutninger om tilgængeligheden i det program-produkt, som vi skulle udvikle.

Resultatet af dette arbejde er vedlagte guidelines: Krav vedr. tilgængelighed af undervisningsmaterialer.

Guidelines er udarbejdet i et samarbejde mellem Kirsten Marie Hansen, Hjælpemiddelinstituttet; Michael Viskum og Jørgen H. Christiansen, UNI-C.

De følgende oversigter kan give et indtryk af det problemområde, som vi har bevæget os i inden for TAU-projektet.

Funktionsnedsættelser

• Blinde
• Svagsynede
• Hørehæmmede
• Døve
• Døvblinde
• Mennesker med motoriske funktionsnedsættelser (tastaturbrugere, musebrugere, kontaktbrugere)
• Mennesker med kognitive funktionsnedsættelser
• Mennesker med mere end én funktionsnedsættelse
• Ordblinde/dyslektikere og andre med nedsat læsefunktion

Generelle design guidelines

• Anvend systemværktøjer, hvor det er muligt
• Understøt et konsistent layout og en forudsigelig opførsel. Følg systemstandarder, typografier og konventioner
• Lav tastaturadgang til alle dialoger, menuer og værktøjsbokse
• Minimer de færdigheder og forudsætninger, der skal til for at anvende programmet
• Udnyt evt. specielle adgangsforhold i OS og til kompenserende SW og HW (undgå at blokere)
• Benyt en Open Systems tilgang

Specifikke problemområder

• Tekst på skærmen
• Cursorer, pile, fremhævning og andre fokuseringsteknikker
• Farve og kontrast
• Skærmformat og layout
• Tastatur
• Kontroller
• Menuer, paletter og værktøjsbjælker
• Dialogbokse
• Objekters størrelse
• Lyd
• Andet

Vi har først gennemlæst en stor del af de eksisterende retningslinjer og herunder noteret de punkter, som vi fandt relevante ved udviklingen af et elektronisk undervisningsmateriale til distribution på cd-rom eller via internettet.

Mange af de retningslinjer, som vi har haft til overvejelse, har på forhånd været delt op i forhold til bestemte typer af funktionsnedsættelser. Men vi besluttede ikke at lave en sådan forhåndsbegrænsning og i stedet udskyde beslutninger vedr. typer af funktionsnedsættelser, så de kunne træffes i sammenhæng med et konkret udviklingsprojekt.

Analysen af de eksisterende retningslinjer resulterede i en bruttoliste med ca. 300 punkter, som vi derefter har gennemdrøftet og skrevet sammen specielt med henblik på at gøre de enkelte punkter operationelle for en projektgruppe med et konkret projekt. Den endelige liste indeholder kun godt 50 punkter.

Det operationelle kommer bl.a. frem i den omstændighed, at punkterne er opstillet i et skema, hvor et kryds ud for et punkt kan angive en beslutning om, at programmet skal indeholde denne funktionalitet.

Ved siden af beskrivelsen af funktionaliteten har vi forsøgt at beskrive konsekvenserne, som beslutningen får for de medarbejdere, der er involveret i udviklingen af programmet. I starten havde vi mange forskellige grupper af medarbejdere i kikkerten, men efterhånden blev de skåret ned til ganske få grupper.

En enkelt gruppe blev meget bred, nemlig gruppen "udviklere". Den dækkede oprindeligt både programdesignere og programmører, men det kunne af og til være svært at afgøre om det var den ene eller den anden kategori, der skulle tage sig af det.

Med vores valg af punkter har vi været påvirket af, at vi har haft en række konkrete projekter for øje. Det er derfor meget muligt, at vi har overset punkter, som andre ville finde vigtige. Eller vi har måske vægtet punkterne anderledes, end vi ville gøre, hvis vi havde set på andre produkter, som skulle udvikles til andre teknologier.

Vi har eksempelvis besluttet at udvikle et konkret programprodukt, som skal henvende sig til en bestemt målgruppe, som igen forventes at kunne få et bestemt udbytte af at anvende produktet.

Allerede her kan man sandsynligvis indskrænke målgruppen til ikke at indeholde visse kategorier af funktionshæmmede. Ex døve i forhold til et program, der træner udtale.

Herefter gennemarbejdes listen med guidelines af hele den udviklingsgruppe, der er knyttet til projektet - inklusive deltagere fra Usability-gruppen, som jo har en særlig viden på dette område.

Sættes der f.eks. x ved punkt 29 betyder det, at man har besluttet, at der i programmet skal være:
Mulighed for under brugerindstillinger at slå programmets værktøjslinjer og menuer til og fra.
Dette får som konsekvens:
For udviklere: Tag højde for i designet, at værktøjslinjer og menuer kan være slået fra. Skaf mulighed for at brugeren igen kan slå disse til uden brug af værktøjslinje henholdsvis menuer.

Ved at involvere hele projektteamet i udvælgelsesprocessen sikres en fælles forståelse af problematikken, hvilket måske også kan betyde, at yderligere kravpunkter kan føjes til listen.

Efterhånden som en række muligheder krydses af i listen, diskuteres det, hvilke konsekvenser dette får for udviklingsprocessen. Herunder bør der også tages beslutning om en testprocedure, der kan sikre, at produktet nu også bliver tilgængeligt på den ønskede måde.

Ved udvikling af produkter, der skal benyttes af funktionshæmmede, vil der være god ræson i at inddrage brugere fra målgruppen både i designprocessen og aftestningen af produktet. Flere steder i listen med krav og tilhørende konsekvenser har vi understreget dette ved at pege på, at en beslutning vedr. et krav kan betyde, at man bør involvere repræsentanter for brugerne, Bruger Centreret Design (BCD).

Sammen med vores guidelines (Krav vedr. tilgængelighed af undervisningsmaterialer) ligger en ordliste, som forklarer den betydning, som vi har lagt i brugen af nogle ord, som kan misforstås. I virkeligheden burde hvert enkelt punkt i vores guidelines have været ledsaget af en udførlig forklaring med beskrivelse af, hvorfra kravet oprindeligt stammer, så man der kan læse mere om, hvordan en opfyldelse af det pågældende krav (evt. med hjælp fra supplerende teknologi) kan hjælpe en person med en bestem funktionsnedsættelse.

Indtil videre må man i stedet lade sig nøje med følgende liste over kilder:

1. Trace Software Guidelines
   Application Software Design Guidelines: Increasing the Accessibility of Application Software to People with Disabilities and Older Users trace.wisc.edu/docs/software_guidelines/software.htm
   Trace Research & Development Center www.tracecenter.org/about
2. Web Content Accessibility Guidelines 1.0
   Internationale standarder for tilgængelighed på nettet - WAI.
   W3C Recommendation 5 May 1999
   www.w3.org/TR/WAI-WEBCONTENT/
3. Authoring Tool Accessibility Guidelines 1.0
   W3C Recommendation 3 February 2000
   www.w3.org/TR/ATAG10
4. User Agent Accessibility Guidelines 1.0
   W3C Working Draft, 22 June 2001
   www.w3.org/TR/UAAG10
5. Microsoft Accessibility
   www.microsoft.com/enable
6. IBM Accessibility Center:
   Software: http://www-3.ibm.com/able/accesssoftware.html Web: http://www-3.ibm.com/able/accessweb.html Java: http://www-3.ibm.com/able/accessjava.html
7. Statens Information
   Retningslinjer ved publicering på nettet
   http://www.si.dk/netsteder/publ/index.html
8. Statens Information
   Hjemmesiders tilgængelighed
   http://www.si.dk/netsteder/publ/tilgaeng/
9. Nordic Guidelines for Computer Accessibility
   http://trace.wisc.edu/docs/nordic_guidelines/nordic_guidelines.htm
10. At utforma pedagogiske programvare
    - tips om enkla åtgärder för att öka tillgängligheten för elever med funktionshinder, (SIH)
    http://www.sih.se/laromit/pedprog_closed/pedbros.htm
11. Update: Assistive Technology for Students with Special Needs, Technology & Learning
    Nov - Dec 1998, Michael Lyman and Mary Anne Mather
    www.techlearning.com
12. Userfit
    A Practical Handbook on User-Centred Design for Assistive Technology
    TIDE USER Consortium, Bruxelles, 1996
13. Requirements specification and evaluation for user groups with special needs
    Report from Telematics Application Project TE2010, RESPECT
    M.C. Maguire, J. Heim, J.H. Skjetne and N. Vereker
    http://www.lboro.ac.uk/eusc/guide/special_needs.doc (Word-dokument)