Vad är en VPAT? En ACR-guide

Om du säljer programvara till en myndighet, ett universitet, ett sjukhusnätverk eller ett stort företag kommer förr eller senare en inköpare att be dig om “er VPAT”. För många leverantörer är detta första gången de stöter på dokumentet, och begäran kommer med knapphändig förklaring och en snäv deadline. Den här guiden avmystifierar VPAT:en och det Accessibility Conformance Report (ACR) den blir till: vad dokumentet är, hur de två termerna förhåller sig till varandra, vilken av de fyra utgåvorna du bör ta fram, hur konformitet bedöms, och varför en ärlig, evidensbaserad rapport är en av de mest värdefulla tillgänglighetstillgångar din organisation kan äga.

En VPAT är inget certifikat, ingen märkning och ingen marknadsföringspåstående. När den är som bäst är den en noggrann redogörelse, kriterium för kriterium, för hur din produkt står sig mot erkända tillgänglighetsstandarder. När den är som sämst är den en stämplad fiktion som utsätter dig för juridisk och anseendemässig risk i samma stund som en köpares tillgänglighetsteam testar din produkt. Skillnaden mellan dessa två utfall är testarbetet bakom dokumentet — och det är precis där QualiBooth lägger fokus.

Vad en VPAT egentligen är

VPAT står för Voluntary Product Accessibility Template. Det är ett standardiserat dokument, skapat och underhållet av Information Technology Industry Council (ITI, genom dess ITIC-gren), som leverantörer använder för att beskriva hur en produkt eller tjänst inom informations- och kommunikationsteknik (IKT) uppfyller en uppsättning tillgänglighetsstandarder.

Ordet “voluntary” (frivillig) är något missvisande i dag. Mallen uppstod för att hjälpa leverantörer att frivilligt lämna tillgänglighetsinformation till amerikanska federala köpare, men i praktiken är det numera ett hårt krav att fylla i en i otaliga upphandlingsprocesser. Delen “template” är mer bokstavlig: VPAT:en är ett tomt formulär med en definierad struktur — tabeller över framgångskriterier, en kolumn för konformitetsnivå och en kolumn för förklarande kommentarer.

Tre saker är värda att lägga på minnet från början:

En VPAT beskriver en specifik version av en specifik produkt på specifika plattformar. En VPAT för “vår app” utan versionsnummer är meningslös.
En VPAT är självrapporterad. Inget externt organ certifierar den. Just därför hänger en VPAT:s trovärdighet helt på noggrannheten i testarbetet bakom den.
Den nuvarande allmänt använda mallfamiljen är VPAT 2.5. Utgå alltid från den senaste versionen av ITI-mallen snarare än en gammal kopia som flyter omkring på er delade enhet.

VPAT kontra ACR: skillnaden som folk snubblar på

Folk använder “VPAT” och “ACR” omväxlande, men de är inte samma sak — och att förstå skillnaden signalerar till en kunnig köpare att du tar processen på allvar.

En VPAT är den tomma mallen. Det är det tomma formulär som ITI publicerar.
Ett ACR — Accessibility Conformance Report — är det ifyllda dokumentet. När du har fyllt i mallen för din faktiska produkt, med verkliga konformitetsbedömningar och kommentarer, blir resultatet ett ACR.

Med andra ord är VPAT:en pepparkaksformen och ACR:en pepparkakan. När en köpare ber om “er VPAT” är det egentligen ert ACR de vill ha: den ifyllda rapporten. De flesta team fortsätter säga “VPAT” i vardagligt tal, och det är okej, men i formell dokumentation är det korrekt att kalla den färdiga filen för ett Accessibility Conformance Report.

Detta handlar om mer än pedanteri. En köpare som tar emot en fil med titeln bokstavligen “VPAT 2.5 Template” med tomma tabeller — något som händer oftare än man kan tro — vet omedelbart att leverantören inte har gjort jobbet. Ett korrekt ifyllt ACR, namngivet och daterat efter den produktversion det täcker, förmedlar kompetens innan köparen läst en enda rad.

VPAT 2.5-mallens fyra utgåvor

En av de vanligaste förvirringspunkterna är att VPAT 2.5-mallen finns i fyra utgåvor, var och en anpassad till en annan standard eller kombination av standarder. Att välja fel utgåva kan stoppa en affär eller fälla en granskning, så välj medvetet utifrån var du säljer.

1. WCAG-utgåvan

Den här utgåvan utvärderar din produkt enbart mot Web Content Accessibility Guidelines — vanligtvis WCAG 2.2 (eller den version din köpare anger, ofta på nivå A och AA). Det är rätt val när en köpare helt enkelt vill ha WCAG-konformitetsinformation och inte har något lagstadgat ramverk ovanpå. Det är också den mest avskalade utgåvan, vilket gör den till en rimlig utgångspunkt för produkter som främst säljs till den privata sektorn. Om WCAG i sig är okänt territorium förklarar vår översikt över WCAG-efterlevnad och vår guide om att göra en webbplats WCAG-kompatibel den underliggande standarden.

2. Section 508-utgåvan

Den här utgåvan kopplar din produkt till de Section 508-standarder som används vid amerikanska federala upphandlingar. Eftersom de reviderade Section 508-standarderna införlivar WCAG 2.0 nivå A och AA genom hänvisning, innehåller den här utgåvan WCAG-tabellerna plus ytterligare 508-specifika krav som omfattar hårdvara, programvara, supportdokumentation och tjänster. Om du säljer till en amerikansk federal myndighet — eller till delstatliga myndigheter som speglar federala regler — är det vanligtvis den här utgåvan du behöver. Se vår Section 508-efterlevnadsguide för det regulatoriska sammanhanget.

3. EU-utgåvan (EN 301 549)

Den här utgåvan är anpassad till EN 301 549, den europeiska harmoniserade standarden för IKT-tillgänglighet som ligger till grund för offentlig upphandling i hela EU och i allt högre grad de skyldigheter för den privata sektorn som införts genom European Accessibility Act. EN 301 549 införlivar WCAG och lägger till krav som är specifika för det europeiska sammanhanget, inklusive uttalanden om funktionell prestanda. Om du säljer till den europeiska offentliga sektorn — eller behöver visa beredskap för European Accessibility Act — ta fram EU-utgåvan.

4. INT-utgåvan (internationell)

INT-utgåvan kombinerar alla tre ramverken — WCAG, Section 508 och EN 301 549 — i ett enda dokument. Den är den mest omfattande och kräver mest arbete att ta fram, men den är ovärderlig för leverantörer som säljer på flera marknader, eftersom en rapport tillfredsställer köpare på båda sidor av Atlanten. Om din kundbas spänner över den amerikanska offentliga sektorn och Europa sparar INT-utgåvan dig vanligtvis från att underhålla tre separata dokument.

När kunder är osäkra hjälper vi dem att välja under avgränsningen. Att ta fram en enda INT-utgåva är ofta mer effektivt än att mitt i en affär upptäcka att du har fel regional utgåva. Du kan läsa mer om hur vi arbetar med detta på vår tjänstesida för VPAT-rapporter.

Konformitetsnivåer: rapportens kärna

Varje tillämpligt framgångskriterium i ett ACR får en av en liten uppsättning konformitetsnivåer. Att få dessa bedömningar rätt — och motstå frestelsen att blåsa upp dem — är den allra viktigaste delen av arbetet.

Supports (Uppfyller) — funktionaliteten uppfyller kriteriet utan betydande tillgänglighetshinder. Detta betyder inte “perfekt”; det betyder att en användare som är beroende av hjälpmedelsteknik kan utföra uppgiften utan hinder.
Partially Supports (Uppfyller delvis) — viss funktionalitet uppfyller kriteriet men det finns undantag eller kända hinder. Detta är en ärlig och mycket vanlig bedömning; kommentarskolumnen bör förklara exakt vad som fungerar och vad som inte gör det.
Does Not Support (Uppfyller inte) — merparten av funktionaliteten uppfyller inte kriteriet. Även här bör kommentarerna vara specifika.
Not Applicable (Ej tillämpligt) — kriteriet gäller inte för produkten (till exempel kriterier om ljudinnehåll för en produkt som inte innehåller något ljud).
Not Evaluated (Ej utvärderat) — används endast i Section 508-rapportens nivå AAA-tabeller, eftersom AAA-utvärdering inte krävs.

Två principer skiljer en trovärdig rapport från en värdelös. För det första: kommentarskolumnen bär den verkliga informationen. “Partially Supports” utan förklaring är nästan värdelös; “Partially Supports — datumväljare går att hantera med tangentbord men meddelar inte det valda datumet till skärmläsare; åtgärd planerad till v4.2” talar om för köparen exakt vad de behöver veta. För det andra: bedömningar måste förtjänas genom test, inte tilldelas av optimism. Ett kriterium som markerats “Supports” bör ha verifierats, helst inklusive test utfört av användare av hjälpmedelsteknik.

Varför ärliga, evidensbaserade VPAT:er spelar roll

Det är frestande att behandla VPAT:en som en formalitet att pricka av och markera allt som “Supports” för att snabbt ta sig igenom upphandlingen. Detta är ett allvarligt misstag, av flera sammanlöpande skäl.

Inköpsteam verifierar

Mogna köpare — federala myndigheter, stora universitet, sjukvårdssystem, banker — har i allt högre grad tillgänglighetsspecialister som inte tar ett ACR för givet. De stickprovskontrollerar påståenden genom att testa din produkt med skärmläsare och tangentbord. När en “Supports”-bedömning faller samman under en fem minuters skärmläsarutvärdering förlorar du inte bara raden; du förlorar köparens förtroende för hela dokumentet, och ofta affären.

Juridisk risk ackumuleras

En överdriven VPAT är ett skriftligt påstående om din produkts tillgänglighet. I en jurisdiktion med exponering för tillgänglighetstvister — under ADA i USA, AODA i Ontario, eller European Accessibility Act i EU — blir ett dokument som hävdar en konformitet som din produkt inte levererar till bevis mot dig. Ett ärligt ACR som öppet rapporterar “Partially Supports” med en tidsplan för åtgärd är långt mer försvarbart än ett uppblåst som hävdar perfektion.

En ärlig rapport är mer användbar internt

Ett sanningsenligt ACR fungerar samtidigt som en backlog. Varje “Partially Supports” och “Does Not Support” är en prioriterad åtgärdspunkt för ditt utvecklingsteam. Team som behandlar VPAT:en som en levande förteckning över tillgänglighetsskuld gör stadiga, mätbara framsteg; team som fuskar samlar på sig dold risk.

Det är därför en VPAT aldrig får förväxlas med ett tillgänglighetsöverlägg eller en enradig “tillgänglighetswidget”. Överlägg åtgärdar inte den underliggande koden, producerar inte försvarbart konformitetsbevis och kan inte ersätta ett verkligt ACR. QualiBooth rekommenderar inte överlägg av just detta skäl — de skapar ett sken av efterlevnad utan substansen, vilket är motsatsen till vad en ärlig VPAT representerar.

Så tar du fram en VPAT, steg för steg

Ett pålitligt ACR är resultatet av en disciplinerad process. Här är den ordning vi följer, och den du bör förvänta dig av varje kompetent leverantör.

Definiera omfattningen. Identifiera den exakta produkten, versionen och plattformarna (webb, iOS, Android, dator) som rapporten ska täcka. Bestäm vilken utgåva — WCAG, Section 508, EU eller INT — utifrån dina målmarknader.
Kör automatiserade tester. Automatiserade skannrar är snabba och utmärkta på att fånga vissa kategorier av problem — saknad alternativtext, låg kontrast, omärkta formulärfält. Vår programvara för tillgänglighetsskanning ger denna baslinje, och du kan prova den gratis med en snabbskanning. Men kom ihåg att automatisering tillförlitligt bara upptäcker en del av WCAG-problemen.
Genomför manuell testning. Merparten av framgångskriterierna kräver mänsklig bedömning: meningsfull fokusordning, logisk läsordning, vettiga felmeddelanden, tillgängliga anpassade widgetar. En grundlig manuell tillgänglighetsgranskning är ovillkorlig för en trovärdig rapport.
Testa med användare av hjälpmedelsteknik. De mest försvarbara bedömningarna kommer från granskningar utförda av personer med funktionsnedsättning som dagligen använder skärmläsare, förstoring och kontaktstyrning. De synliggör verkliga hinder som seende testare missar.
Tilldela bedömningar och skriv kommentarer. Översätt fynden till Supports / Partially Supports / Does Not Support för varje kriterium, med specifika, användbara kommentarer.
Sammanställ och granska ACR:en. Formatera den färdiga rapporten snyggt, märk den med produktversion och datum, och låt den granskas för korrekthet och konsekvens innan den lämnar huset.
Kombinera den med en åtgärdsplan. En bra leverantör lämnar inte bara rapporten utan även en prioriterad plan för att flytta “Partially Supports” mot “Supports”.

Om ditt team saknar den interna expertisen för steg två till fem är det snarare regel än undantag. Det är precis det arbete som vår VPAT-rapporttjänst och bredare tillgänglighetsrådgivning täcker. För en fylligare bild av vad rådgivningsuppdrag innebär, se vår förklaring om tillgänglighetsrådgivning.

Att underhålla en VPAT över tid

En VPAT är en ögonblicksbild av ett rörligt mål. Den dag du lanserar en ny version börjar ditt ACR glida ifrån verkligheten. Att behandla dokumentet som en engångsleverans är ett av de vanligaste — och mest skadliga — misstag leverantörer gör.

Uppdatera vid väsentlig förändring. Varje lansering som på ett betydande sätt förändrar användargränssnittet eller lägger till ny funktionalitet bör utlösa en översyn av de berörda kriterierna.
Förnya minst årligen. Även utan större förändringar utvecklas standarder och köpare förväntar sig ett aktuellt datum på dokumentet. Ett ACR daterat tre år tillbaka inbjuder till skepsis.
Knyt det till löpande testning. Det mest tillförlitliga sättet att hålla ett ACR sanningsenligt är att fortsätta testa produkten kontinuerligt. Återkommande tillgänglighetsgranskningar fångar regressioner innan de ogiltigförklarar dina påståenden, så att rapporten du lämnar till en köpare alltid matchar produkten de kommer att testa.

QualiBooth kombinerar en skanningsplattform med expertdriven mänsklig utvärdering just för att beviset bakom ditt ACR ska hållas aktuellt. Skannern bevakar regressioner mellan formella granskningar; den mänskliga testningen håller de nyanserade, bedömningsbaserade betygen ärliga. Du kan jämföra hela vårt utbud på sidan tillgänglighetstjänster och granska alternativ på vår pris-sida.

Vanliga frågor

Är en VPAT lagstadgad?

Mallen i sig är frivillig, men att tillhandahålla en är ofta ett obligatoriskt villkor i ett inköpsavtal, särskilt vid amerikanska federala och delstatliga upphandlingar och inom den offentliga sektorn i hela EU. Separat är de underliggande tillgänglighetsskyldigheterna — Section 508, EAA, ADA — i högsta grad obligatoriska, och en VPAT är hur du visar din position gentemot dem.

Kan jag fylla i en VPAT själv?

Det kan du, och inget förbjuder egen ifyllning. Risken är noggrannheten. En självbedömning skriven utan grundlig testning — eller med ett incitament att se bra ut — tenderar att överdriva konformitet, vilket skapar juridisk exponering och urholkar köparens förtroende i samma stund som påståendena testas. Många organisationer tar in en oberoende leverantör av just detta skäl.

Hur lång tid tar det att ta fram en VPAT?

Det beror på produktens storlek och komplexitet samt vilken utgåva som krävs. En webbapplikation för en plattform kan ta ett par veckor när testningen väl är igång; en stor svit för flera plattformar som behöver INT-utgåvan tar längre tid. Ett avgränsningssamtal ger dig en realistisk tidsplan.

Vad är skillnaden mellan WCAG-konformitet och en VPAT?

WCAG är standarden — uppsättningen framgångskriterier. En VPAT/ACR är det dokument som registrerar, kriterium för kriterium, hur din produkt presterar mot den standarden (och, beroende på utgåva, mot Section 508 och EN 301 549 också). Du måste faktiskt uppfylla WCAG för att hävda konformitet; ACR:en är hur du kommunicerar var du står.

Sammanfattningsvis

En VPAT, ifylld som ett Accessibility Conformance Report, är långt mer än ett upphandlingshinder. Gjord ärligt är den en trovärdig redogörelse för hur din produkt betjänar personer med funktionsnedsättning, en försvarbar dokumentation som minskar juridisk risk, och en arbetande backlog som driver verklig förbättring. Gjord oärligt är den ett ansvar som väntar på att avslöjas.

Den avgörande faktorn är alltid testarbetet bakom bedömningarna. Om du behöver ett ACR du kan sätta ditt namn på — ett som är grundat i automatiserad skanning, manuella granskningar och utvärdering av personer med funktionsnedsättning — utforska vår VPAT-rapporttjänst, eller boka en demo för att se hur QualiBooth tar fram rapporter som håller vid närmare granskning.