Samarbeidsverktøy, tilgjengelighet og brukerkrav (W3C/WAI)

Skrevet av: Morten Tollefsen

I denne artikkelen har jeg oversatt med Google translate og bare gjort noen få språklige forbedringer. Teksten er altså ikke på noen måte en offisiell norsk versjon.

Digitalt samarbeid er en selvfølge for mange av oss i dag. Det gir noen funksjonshemmede bedre muligheter til å delta, men andre for enda flere utfordringer. Krav til universell utforming slik vi kjenner det fra WCAG er ikke tilstrekkelig. Derfor har WAI publisert arbeidsnotatet Collaboration Tools Accessibility User Requirements som beskriver krav til samarbeidsverktøy.

I notatet legges hovedvekten på tekstsamarbeid, men sekvensielt innhold som lyd og video er også nevnt. Visuelle samarbeidsverktøy (for eksempel elektroniske tavler) introduserer enda større utfordringer enn det W3C har tatt tak i foreløpig. Likevel er alt i «Collaboration Tools Accessibility User Requirements» også viktige forutsetninger for at slike verktøy skal kunne brukes av flest mulig.

Etter hvert vet veldig mange utviklere om WCAG. Arbeidsnotatet om samarbeid er nok veldig mye mindre kjent. Det er imidlertid et viktig notat siden mer og mer av det vi utvikler er samarbeidsverktøy eller har sammenliknbar funksjonalitet. Les gjennom denne artikkelen så får du en rask introduksjon på norsk, så kan du lese originalen og tilhørende informasjon for å gå dypere inn i problemstillingene.

Avgrensing

Slik beskrives samarbeidsverktøy i arbeidsnotatet:

Samarbeidsverktøy er all programvare som støtter funksjoner designet for å lette interaktiv oppretting, redigering eller merknader av innhold med flere bidragsytere, enten de jobber samtidig eller asynkront. Eksempler på samarbeidsverktøy inkluderer:

• En nettbasert editor eller tekstbehandler som gjør det mulig for flere forfattere å redigere innhold samtidig mens de diskuterer i en videokonferanse, Der hver bidragsyters endringer blir integrert i den resulterende teksten og formidlet i sanntid til samarbeidspartnerne.
• En nettbasert tekstredigerer eller tekstbehandler som gjør det mulig for flere forfattere å redigere innhold asynkront over mange dager og uker. Hver bidragsyters endringer integreres i den resulterende teksten og vises ved neste lasting til samarbeidspartnerne.
• Et verktøy som gjør det mulig å kommentere nettsider med kommentarer som automatisk gjøres tilgjengelig for andre brukere av kommentartjenesten som får tilgang til de samme sidene med passende programvare. Programvaren kan være inkludert i en brukeragent, eller den kan leveres som en utvidelse.
• Et integrert utviklingsmiljø (IDE) som støtter samarbeidsredigering av programkildekode i sanntid (eller asynkront).
• En wiki som støtter versjonskontroll, for eksempel ved å gjøre det mulig for forfattere å gå tilbake til tidligere versjoner av en side eller se forskjellene mellom to versjoner.
• En midi- eller lydredigeringsapplikasjon som tillater synkron redigering av lydinnhold i sanntid, eller asynkron innholdsredigering. Samarbeidspartnere hører redigert innhold på forespørsel under en redigeringsøkt for telekonferanser eller ved innholdsoppdatering når de redigerer asynkront.

Innledningsvis i arbeidsnotatet står dette, og det er ekstremt viktig! Jeg har sett mange forsøk på å gjøre programvare universelt utformet som faktisk er gode forsøk, men som likevel funker dårlig fordi det krever for mye spesialkunnskap fra brukere med hjelpeteknologi:

Noen samarbeidsverktøy støtter tilgjengelighet ved å benytte spesialiserte tastaturkommandoer. Noen organiserer også funksjonsalternativene sine i spesialiserte tilgjengelighets-menyer eller unikt plasserte menyer. Vi foretrekker samarbeidsverktøy som bruker standard menyorganisering og typiske tastaturkommandoer som nå er godt kjent for brukere fra skrivebordsmiljøet. Standardkontroller krever langt mindre læring fra brukeren, mens spesifikke tilgjengelighetsmoduser med tilpassede tastaturkommandoer og menyer som skifter plassering på skjermen utgjør betydelige læringsutfordringer for de fleste brukere med funksjonshemminger, ikke bare brukere med kognitive og lærevansker.

I forhold til å vurdere egnethet og tilgjengelighet i praktisk bruk er følgende også viktig (kapittel 1.3 i notatet):

Spesifikke brukerbehov er definert både av oppgave som kreves for å oppnå et bestemt mål og av miljøforhold. Kontekst betyr noe. For eksempel avhenger de kognitive kravene som stilles ved å samhandle med de samarbeidsrelaterte funksjonene til en applikasjon, ikke bare av brukerens behov og evner, inkludert mulig tilstedeværelse av hjelpemidler, men også av konteksten. En samarbeidsoppgave som brukeren kan utføre selvstendig mens han arbeider alene i et distraksjonsfritt miljø, kan raskt bli kognitivt belastende når den utføres under en videokonferanse. Å jobbe med kommentarer og foreslåtte endringer blir mer kognitivt krevende når andre forfattere samtidig redigerer det samme innholdet, og brukeren må være klar over sine aktiviteter (f.eks. for å unngå å introdusere motstridende endringer) mens de fortsatt utfører redigeringsoppgaven. Bruken av ulike inputtyper og metoder, for eksempel taleinndata eller bryterbasert input, kan i betydelig grad påvirke hvor lang tid det tar å legge inn og redigere tekst, samt brukerens evne til å reagere på potensielt forstyrrende endringer introdusert av samarbeidspartnere.

Nedenfor er de 19 brukerbehovene.

Redigeringssamarbeid i sanntid

Brukerbehov 1: Brukere må kunne oppdage tilstedeværelsen av samarbeidspartnere som leser eller redigerer innholdet.

Krav 1: Tilby modus der statusmeldinger varsler brukeren når en samarbeidspartner åpner eller lukker en interaktiv økt som involverer det samme innholdet som brukeren har tilgang til (f.eks. det samme dokumentet).

Brukerbehov 2: En bruker av hjelpemidler må informeres i sanntid om endringer i innholdet som gjøres av samarbeidspartnere.

Krav 2: Gi en driftsmodus der statusmeldinger informerer hjelpemiddelbrukeren om innsettinger, slettinger eller formateringsrelaterte endringer gjort av samarbeidspartnere etter hvert som de oppstår. Å begrense disse varslene til et innholdsspenn som for øyeblikket er fokusert av brukeren er også et tilrådelig alternativ.

Brukerbehov 3: Brukere av hjelpeteknologi trenger muligheten til å lese eller redigere uten å bli distrahert av statusmeldinger.

Krav 3: Gi en driftsmodus der statusmeldinger som informerer brukeren om tilstedeværelsen eller aktiviteter til samarbeidspartnere undertrykkes. Dette kan oppnås ved å tillate brukeren selektivt å aktivere og deaktivere spesifikke typer statusmeldinger, meldinger som er relatert til et spesifikt innholdsområde, eller alle slike meldinger.

Brukerbehov 4: En hjelpeteknologibruker trenger muligheten til å spore endringer introdusert av en spesifikk samarbeidspartner etter hvert som de gjøres.

Krav 4: Gi en funksjon som flytter og sporer brukerens fokus til stedet der en spesifikk samarbeidspartner redigerer. Hvis det er flere aktive samarbeidspartnere, bør flere slike kommandoer, eller en meny med aktive innholdsredigerere, være tilgjengelige.

Brukerbehov 5: Brukere med syns, kognitive eller fysiske funksjonshemminger må kunne redigere innhold uten distraksjon av endringer introdusert av samarbeidspartnere.

Krav 5A: Gi en driftsmodus der endringer gjort av samarbeidspartnere ikke vises mens brukeren redigerer, eller

Krav 5B: Gi en driftsmodus der komponenten av innholdet som brukeren redigerer (f.eks. avsnittet, seksjonen, semantisk enhet av kildekode eller grafisk objekt) bare kan endres av én samarbeidspartner om gangen, og forhindrer andre fra å gjøre samtidige modifikasjoner på samme komponent.

Merknader

Brukerbehov 6: En hjelpemiddelbruker må informeres om tilstedeværelsen av merknader sammen med den spesifikke delen av innholdet som kommenteres, for eksempel ord, setninger eller avsnitt. Dette gjelder også kodelinjer i et programvareutviklingsprosjekt.

Krav 6: Sørg for at informasjon om merknader formidles til hjelpeteknologier, sammen med grensene for teksten som merknaden gjelder for, sammen med eventuelle metadata knyttet til merknaden, og eventuell kommentartekst.

Brukerbehov 7: Brukere av hjelpeteknologi må kunne lese tekst uten å bli distrahert av informasjon om merknader.

Krav 7: Gi en driftsmodus der informasjon om merknader undertrykkes. Denne modusen kan aktiveres av en programinnstilling, for eksempel en toggle som kontrollerer tilstedeværelse eller fravær av merknader.

Brukerbehov 8: En bruker av hjelpemiddelteknologi må kunne navigere mellom merknader (fra forrige til neste) og for å få en navigerbar liste over merknader (f.eks. en liste over kommentarer i et tekstbehandlerdokument eller på en webside), i for å kunne lese og svare på merknader effektivt. Krav 8: Gi navigasjonsfunksjoner og en mekanisme for å få en liste over alle merknader knyttet til innholdet.

Brukerbehov 9: Brukere av hjelpeteknologi må kunne kontrollere mengden informasjon som presenteres om merknader for å unngå å bli overveldet mens de leser, navigerer og redigerer innhold.

Krav 9: Gi brukeren alternativer for å begrense mengden detaljer som presenteres når hver merknad påtreffes. For eksempel bør det være mulig å undertrykke presentasjon av metadata, eller svar på kommentarer, eller å varsle brukeren kun om tilstedeværelsen av merknaden uten å presentere metadata eller kommentartekst.

Brukerbehov 10: Brukere av hjelpemiddelteknologi og brukere med lærevansker eller kognitive funksjonshemninger trenger noen ganger støtte til å forstå og navigere i merknader som representerer kommentarer organisert som samtaletråder.

Krav 10A: Sørg for at strukturen til kommentartrådene er entydig presentert i brukergrensesnittet, både via visuelle signaler som ikoner og fargeendringer, og til hjelpeteknologier.

Krav 10B: Gjør det mulig å utvide eller kollapse tråder av brukeren, og sikre at den utvidede eller kollapsede tilstanden blir formidlet til hjelpeteknologier.

Versjonskontrollfunksjoner

Foreslåtte endringer

Brukerbehov 11: Brukere av hjelpeteknologi må kunne lese teksten med informasjon inkludert om foreslåtte endringer (dvs. innsettinger, slettinger eller formateringsendringer foreslått av samarbeidspartnere).

Krav 11: Gi en driftsmodus der detaljer om innsettinger, slettinger og formateringsendringer presenteres på riktig måte av hjelpeteknologien når brukeren leser innholdet.

Brukerbehov 12: Brukere med fargeblindhet må være i stand til å skille innsettinger, slettinger og uendret tekst effektivt.

Krav 12: Bruk andre distinksjoner enn farge for å identifisere innsatt og slettet tekst i det visuelle grensesnittet som kreves av WCAG 2.2 Suksesskriterium 1.4.1: Bruk av farge.

Presentere forskjeller mellom revisjoner

Brukerbehov 13: Brukere må kunne sammenligne revisjoner i meningsfulle enheter (ord, setninger, linjer osv.), i henhold til innholdets art, for å maksimere forståelsen.

Krav 13: Presenter forskjeller på en måte som passer til typen innhold. For eksempel kan programvarekildekoden presenteres med linje-for-linje-forskjeller, mens dokumenter med naturlig språk kan presenteres med forskjeller vist ord-for-ord eller setning-for-setning.

Oppsummeringer

Brukerbehov 14: Brukere med lærevansker eller kognitive funksjonshemminger, og brukere av hjelpeteknologier trenger noen ganger støtte til å identifisere revisjoner og forstå effektene deres.

Krav 14A: Gi en mekanisme for å identifisere og oppsummere en rekke endringer i innhold. Når kunstig intelligens (AI) i stedet for menneskelig forfatterskap brukes til å generere sammendrag, gi muligheten til å redigere det genererte sammendraget.

Krav 14B: Gi en mekanisme for å identifisere og oppsummere individuelle kommentartråder. Når AI i stedet for menneskelig forfatterskap brukes til å generere sammendrag, gi muligheten til å redigere det genererte sammendraget.

Krav 14C: Gi, hvis det er teknisk mulig, en mekanisme som lar enhver bruker automatisk generere et sammendrag for seg selv av innhold eller en kommentartråd når som helst. Prosjektredaktører bør ha evnen til å revidere og forplikte en oppsummering av innholdet i samarbeidsutvikling som en fast del av samarbeidet.

Varsler og meldinger

Brukerbehov 15: Brukere som lett lar seg distrahere trenger kun å motta varsler som er avgjørende for deres samarbeidsaktivitet.

Krav 15: Sikre at brukere kan velge hvilke typer varsling som skal leveres, og hvilke som blir undertrykt, i henhold til informasjonen som formidles.

Brukerbehov 16: Brukere som leser sakte eller har problemer med tekstlesing, trenger at informasjon som er viktig for oppgaven skilles klart ut og prioriteres.

Krav 16A: Gi en driftsmodus der varslene er korte, og lenker til mer detaljert informasjon er inkludert. I denne modusen er ikke fullstendige detaljer gitt i varselet. En bruker kan for eksempel bli varslet om at en kommentar eller et problem har blitt opprettet, der hele teksten kun er tilgjengelig via en lenke i stedet for som en del av selve varslingsmeldingen.

Krav 16B: Hvis e-post eller lignende medier brukes til å levere varsler, sørg for at emnet for meldingen tydelig spesifiserer prosjektet, dokumentet eller problemstillingen som er relevant for meldingen.

Krav 16C: Hvis flere varsler leveres sammen (f.eks. i en enkelt melding), sørg for at brukeren kan sortere varslene i henhold til rimelige preferanser, for eksempel den nyeste først eller den eldste først. Dette gjelder for eksempel en serie kommentarer organisert som diskusjonstråder, alle levert i en enkelt oppsummeringsmelding til brukeren.

Tilgangskontroll

Brukerbehov 17: Brukere av hjelpemidler og de med kognitive eller lærevansker må kunne finne ut om de har tillatelse til å redigere innhold, helt eller delvis.

Krav 17: Sørg for at den gjeldende tillatelsen (f.eks. skrivebeskyttet tilstand) som påvirker innholdet som er i fokus er tydelig presentert i brukergrensesnittet, og at det gjøres tilgjengelig for hjelpeteknologier.

Brukerbehov 18: Brukere, inkludert de med lærevansker eller kognitive funksjonshemninger og de med hjelpeteknologier, må informeres om endringer som er gjort for tilgangstillatelser som trer i kraft under en redigeringsøkt.

Krav 18: Hvis en tilgangskontroll som påvirker innholdet som er i fokus endres under en redigeringsøkt, for eksempel av en samarbeidspartner, presenteres et varsel om endringen i brukergrensesnittet og gjøres tilgjengelig for hjelpeteknologier.

Generell veiledning om implementering av tilgjengelighetsfunksjoner i samarbeidsmiljøer

Brukerbehov 19: Brukere med lærevansker eller kognitive funksjonshemninger eller som bruker hjelpeteknologier, må kunne lære samarbeidsverktøy effektivt, inkludert programvare som de ikke er kjent med og som er nødvendig for oppgaven.

Krav 19A: Ved implementering av samarbeidsfunksjoner, følg etablerte brukergrensesnittkonvensjoner og designmønstre. Bruk for eksempel konvensjonell terminologi, etiketter eller ikoner for funksjonalitet som kan være kjent for brukerne.

Krav 19B: Støtt de tilgjengelighetsrelaterte funksjonene til brukerens operativsystem, brukeragent og hjelpeteknologi. Noen hjelpeteknologier, som skjermlesere, har for eksempel funksjoner som er utviklet spesielt for å lese kommentarer og foreslåtte endringer i tekstinnhold, som bør støttes i stedet for å definere applikasjonsspesifikk funksjonalitet eller tastaturkommandoer som oppnår samme formål. Krav 19C: Gjør samarbeidsfunksjoner tilgjengelig via et API for å tillate interoperabilitet med verktøy som brukeren kan være kjent med, og som bedre kan tilfredsstille en persons spesifikke tilgjengelighetsrelaterte behov. For eksempel kan et revisjonskontrollsystem fungere sammen via en API med en brukers valgte tekstredigerer eller integrerte utviklingsmiljø.