Bra praxis för specifikation av tjänster

Upptäckta utmaningar i praktiska projekt

Tillgänglighetskraven uppfylls effektivt i serviceutvecklingsprojekt endast om tillgängligheten beaktas under hela serviceutvecklingsprocessen. Skälet till detta är att även om WCAG-kriterierna i regel koncentrerar sig på funktionella krav som syns bland annat för hjälpmedelsanvändare via tjänstens tekniska genomförande, har största delen av WCAG- och användbarhetsbristerna sitt ursprung redan i specificeringen som sker innan kodningen eller till och med avsaknaden av den.

Bristande specifikation

Ett svagt specifikationsarbete leder till situationer där utvecklarna och planerarna rentav väldigt spontant och med få bakgrundsuppgifter blir tvungna att utföra tämligen avgörande specifikationsarbete och därigenom serviceutformning, så att man får ihop den önskade funktionaliteten i önskad tidtabell. Projektledningen förutsätter att utvecklaren vet på vilket sätt varje funktionalitet ska genomföras, så länge hen är medveten om de allmänna ramarna, eftersom det är hens uppgift. Serviceutformning bör dock inte ingå i utvecklarens uppgifter när det inte uttryckligen står i hens arbetsbeskrivning och när hen inte har tillräckligt med information om allt specifikationsmaterial för tjänsten.

Följ upp om utförandet av användargränssnittslösningar glider ända till utvecklaren, eftersom hen är den sista etappen där man måste ta ställning till många frågor för att kunna genomföra funktionaliteten. Exempel på sådana lösningar är den tekniska läsordningen för innehåll, användningen av tekniska modalstrukturer samt hur användarens läsinriktning bör behandlas i olika slags funktioner i anslutning till webbformulär. Utvecklaren kan även behöva besluta hur sidans olika logiska innehållsområden bör presenteras ur hjälpmedlens perspektiv, när ingen ens har kommit att tänka på saken innan kodningen – och plötsligt måste man bara skriva in landmärkena i koden för att få ut testversionen.

Effekter

Sådana beslut har emellertid en stor effekt på tjänstens användbarhet och de bör fattas inom ramen för tjänstens specifikation och det därpå följande planeringsarbetet, så att de personer som bäst känner till respektive krav deltar i beslutsfattandet. Problemet verkar gälla lika mycket i en agil som en mer traditionell utvecklingsprocess.

Det kan förekomma mer omfattande oklarhet i arbetsfördelningen för specifikation. Om till exempel serviceutformaren har dokumenterat användargränssnittets struktur som är kopplad till en viss funktion (innehållens logiska ordning, elementtyper, områden), kan den visuella planeraren avvika från anvisningarna och om hen kan, inom vilka ramar och med vems mandat? Om båda planerarna är olika underleverantörer, vem av dem har auktoritet? Om grafikern har rätt till dispens avseende serviceutformningen, kan riskerna bland annat i genomförandet av tillgänglighetskraven och tjänstens användarbarhet vara betydande, eftersom hen nödvändigtvis inte har information om de grunder som använts för serviceutformningen i respektive situation och på grund av vilka även en liten avvikelse kan vara kritisk.

När en sådan ”visu” eller prototyp sedan anländer till utvecklaren, kan hen nu för sin del bli tvungen att brottas med dokumentation som är inkonsekvent sinsemellan eller åter göra en helt ny tolkning av funktionalitetens krav (redan den tredje personen att göra detta).

Det är tydligt att uppfyllandet av tillgänglighetskraven inte kan garanteras med otydlig arbetsfördelning och specifikation. Tyvärr är dessa problem vanliga inom praktiska utvecklingsprojekt.

Bra praxis

1. Ta med tillgänglighetskraven direkt från början

Tillgänglighet är inte ett isolerat område eller projektskede, som genomförs åtskilt från det övriga arbetet, utan tillgänglighetskraven bildar en fast del av tjänstens normala kravgrupp, som omfattar både funktionella (enskilda funktioner som kan utföras i tjänsten) och icke-funktionella (t.ex. prestanda, responsivitet, stöd för läsversioner) krav.

2. Dra nytta av användarberättelserna och backa upp specifikationen med användningsfall

Användningsfall och användarberättelser är effektiva verktyg vid specifikation av digitala tjänster. Dessa beskrivs mer ingående i modul 2. De är en utmärkt hjälp om det känns svårt att uppfatta vilka olika tillgänglighetskrav som är kopplade till respektive funktion. Ett vanligt misstag är att börja specificera krav via alla WCAG-kriterier med tanken att man ska kryssa av allt som kommer att behövas. Det funkar vanligtvis inte. Ett bättre sätt är att fundera över krav via funktioner och funktionsberättelser som användaren utför i tjänsten. Då är det enklare att hitta kriterier.

3. Specificera roller och ansvar

Redan innan du upprättar eller itererar användningsfall bör du säkerställa att oklarheter om ansvar som beskrivs i början inte uppstår, när specifikationen, planeringen och prototypskapandet startar (ofta sida vid sida i en agil utveckling). Fundera på och anteckna:

  • Specificera hur serviceutformningen, den visuella planeringen och det tekniska genomförandet fördelas mellan olika leverantörer eller resurser
    • Sätt en övre auktoritet för serviceutformningen, som det grafiska och tekniska genomförandet måste följa, så att brister i planeringen som upptäcks i genomförandet alltid cirkuleras via planeringen och att man inte gör några självständiga betydande variationer i genomförandet i relation till serviceutformningens anvisningar utan tillstånd från planeraren eller styrgruppen som konsulterar planeraren.
    • Även om serviceutformaren och/eller utvecklaren och/eller grafikern kan vara samma person, ska betydande ändringar under utvecklingen ändå alltid dokumenteras, så att projektets underhåll och vidareutveckling, som kan ligga hos andra yrkespersoner, lyckas på ett effektivt sätt och man inte i vidareutvecklingen låter bli att beakta exempelvis centrala, tillgänglighetsrelaterade lösningsmetoder, som var ”självklara” i genomförandeskedet.
  • Sträva efter att serviceutformare, grafiker och utvecklare sitter vid samma bord när tjänsten specificeras.
    • Det skulle vara bra att man skapar en öppen kommunikationskanal för yrkespersonerna, till exempel Slack, som de kan använda för att även utanför mötena utan onödig byråkrati diskutera saker som påverkar beslut inom tjänstens utveckling. Till exempel bör grafikern och serviceutformaren kunna fråga kodaren om det förekommer problem eller egenskaper i anslutning till genomförandet av den föreslagna planen som påverkar om det lönar sig att gå vidare till en prototyp eller användartestning; eller är lösningsmetod A mer kostnadseffektiv än metod B, och så vidare. Om utvecklaren för sin del upplever att metod C är den smartaste, bör hen snabbt kunna kontrollera med grafikern om den därtill kopplade CSS-ändringen är OK, och så vidare.
    • Arbetsmetoden kan förutsätta att den beaktas redan i samband med konkurrensutsättningen och budgeteringen avseende såväl tidsanvändning som kalenderreservationer. Alla parter bör åtminstone på något sätt vara tillgängliga under hela projektet, inte bara under enskilda livscykelskeden, för att samarbetet ska kunna vara möjligt.
    • Å andra sidan har erfarenhet visat att ju tätare projektets olika yrkespersoner kan samarbeta, desto mer effektiv är utvecklingen, så kostnadseffekten kan på det hela taget vara mycket positiv.
    • En särskilt stor inverkan på effektiviteten sker alltid när man kan förhindra tillgänglighetsöverträdelser på förhand redan i utvecklingsskedet, så att de inte längre finns kvar och behöver åtgärdas i auditeringsskedet.
  • Läs mer om anvisningarna för tillgänglighetsauditering i modul 6. Förbered dig för auditeringen. Specificera vem som ansvarar för eventuella tillgänglighetsbristers åtgärdsarbeten och -kostnader.

4. Förbered dig på att upprätthålla tillgängligheten efter att tjänsten har publicerats.

  • Utse en ägare för tjänstens tillgänglighet. Personen ansvarar för att tjänstens tillgänglighetskrav inte glöms bort eller försummas, när man skapar innehåll för tjänsten och utvecklar den.
    • Erfarenhet har visat att tjänsternas tillgänglighet inte automatiskt bibehålls på publiceringsskedets nivå. Till exempel kan nya innehåll, såsom nya HTML-sidor eller PDF-dokument, oavsiktligt förstöra tjänstens egen specifikation. Å andra sidan bör vidareutvecklingen alltid vara lika noggrann som tjänstens ursprungliga genomförande, eftersom kraven på lagenlighet gäller lika mycket för den. Avslutningsvis bör du komma ihåg att tjänstens tillgänglighetsutlåtande ska uppdateras regelbundet.
    • Tillgänglighetens ägare har som uppgift att observera att tjänstens innehållsproduktion följer de anvisningar som getts för den och att tjänstens eventuella vidareutveckling inte förbigår kraven i tillgänglighetslagen.
    • Om man använder ett automatiskt verktyg för att övervaka tjänstens tillgänglighet, bör ägaren ha behörighet och utbildning för det.
    • Ägaren är också den som i första hand tar emot och behandlar tillgänglighetsrespons som levereras via tillgänglighetsutlåtandet.
  • Bedöm om det behövs övervakningsverktyg för tillgänglighet för att upprätthålla tjänsten och om det är möjligt att smidigt få ett sådant via ett ramavtal.
    • Om du kan dra nytta av automatisk övervakning av tillgänglighet, ska du specificera vem som använder verktyget samt vilka resurser och skyldigheter som är kopplade till det.
    • Om övervakningsverktyget till exempel meddelar om specifikationsöverträdelser i innehållsproduktionen (det har skapats sidor i tjänsten som saknar tekniska rubrikspecifikationer eller en länk som går till en extern tjänst inte är rätt markerad på en ny sida e.d.), ska du på förhand specificera hur verktygets användare, såsom ägaren av tjänstens tillgänglighet, kan ingripa i situationen.

Ursprunglig version: Tero Pesonen/Siteimprove
Skapad: 3.4.2021