VPAT, czyli Voluntary Product Accessibility Template, to ustandaryzowany dokument, który dostawca wypełnia, opisując, jak dobrze konkretny produkt lub usługa spełnia standardy dostępności, takie jak WCAG, Section 508 i EN 301 549, oceniane kryterium po kryterium. Kupujący z sektora korporacyjnego, rządowego i szkolnictwa wyższego powszechnie proszą o niego podczas zamówień, przed zakupem oprogramowania lub usług cyfrowych. Po wypełnieniu dla konkretnego produktu gotowy dokument nazywa się technicznie Accessibility Conformance Report (ACR), choć większość ludzi po prostu nazywa całość VPAT.
Co faktycznie zawiera VPAT
VPAT to długa, ustrukturyzowana tabela, a nie krótkie podsumowanie. Jest publikowany i utrzymywany przez Information Technology Industry Council (ITI), z edycjami obejmującymi różne standardy: edycję wyłącznie dla WCAG, edycję dla Section 508, edycję dla EN 301 549 (dla UE) oraz połączoną edycję “INT” obejmującą wszystkie trzy naraz. Dla każdego pojedynczego kryterium sukcesu dostawca oznacza produkt jako Supports, Partially Supports, Does Not Support lub Not Applicable i ma dodać konkretne uwagi wyjaśniające tę ocenę, najlepiej wskazując, co faktycznie przetestowano, a nie pozostawiając niewyjaśnione zaznaczenie.
Dlaczego kupujący go wymagają
Zespoły zakupowe korporacyjne i rządowe muszą udokumentować, że kupowane oprogramowanie spełnia prawne wymogi dostępności, zwłaszcza w kontekście Section 508 dla zakupów federalnych w USA, podobnych przepisów zamówień stanowych oraz EN 301 549 dla zakupów w sektorze publicznym UE i związanych z EAA. VPAT daje im tę dokumentację bez konieczności przeprowadzania własnego, pełnego niezależnego audytu każdego ocenianego dostawcy. Tworzy też ślad papierowy: jeśli kupiony produkt okaże się mieć istotne luki w dostępności, których VPAT nie ujawnił, kupująca organizacja ma zapis tego, co dostawca deklarował w momencie zakupu.
VPAT-y a standardy, które za nimi stoją
VPAT jest tylko tak sensowny, jak standard, względem którego jest testowany, i to, jak rzetelnie faktycznie przeprowadzono testy. Edycja Section 508 mapuje się na WCAG 2.0 A i AA, ponieważ to właśnie to włączyła przez odniesienie nowelizacja Section 508 z 2017 roku. Edycja EN 301 549 mapuje się na wymogi tego standardu, które od wersji 3.2.1 w pełni włączają WCAG 2.1 AA. Dzięki temu wspólnemu fundamentowi WCAG dostawca, który przeprowadził prawdziwe testy zgodności z WCAG 2.1 AA, jest zwykle dobrze przygotowany do dokładnego wypełnienia VPAT we wszystkich trzech edycjach bez zaczynania od zera za każdym razem.
Kto tworzy VPAT-y
| Funkcja | Deque Systems | Allyant | UserWay |
|---|---|---|---|
| Podejście | Enterprise accessibility testing and remediation company built around the open-source axe-core engine, sold as developer tooling (axe DevTools, axe Monitor, axe Auditor) plus expert manual audits and training, not a consumer widget. | Formed in 2022 by Thompson Street Capital Partners combining Accessible360, ReadSpeaker's document services and other accessibility businesses; focuses on enterprise document, PDF and publishing remediation alongside broader digital accessibility consulting, with an AI-assisted PDF remediation product launched in 2025. | AI-driven accessibility widget with an in-house automated remediation engine, sold mainly as a self-serve script install with tiered plans and a separate professional audit add-on. |
| Cennik | Enterprise quoted pricing by seats and scan volume; axe-core itself is free and open source. | Enterprise quoted engagements, typically scoped per document volume or project. | Freemium widget with paid tiers that unlock more automated checks; enterprise and professional audit services quoted separately. |
| Obsługiwane standardy | WCAG 2.0, WCAG 2.1, WCAG 2.2, Section 508, EN 301 549 | WCAG 2.1, Section 508, PDF/UA, EN 301 549 | WCAG 2.1, ADA, Section 508, EN 301 549 |
| Najlepsze dla | Engineering teams that want to test and fix code directly; Large enterprises needing audits, training and VPAT documentation | Enterprises and government agencies with large volumes of PDFs and documents to remediate | Very small sites wanting a no-cost starting point; Teams that want a widely recognized brand name |
Stworzenie wiarygodnego VPAT zależy od prawdziwych testów za nim stojących, dlatego często zajmują się tym dostawcy z dedykowaną ekspertyzą audytową, a nie jest to robione jako szybkie ćwiczenie wewnętrzne. Deque Systems prowadzi eksperckie ręczne audyty i tworzenie VPAT jako podstawową część swojej pracy konsultingowej dla przedsiębiorstw, opierając się na silniku testowym axe-core, który sam też utrzymuje. Allyant intensywnie współpracuje z klientami korporacyjnymi i rządowymi w zakresie dostępności dokumentów i szerszej dostępności cyfrowej, w tym tego rodzaju szczegółowej dokumentacji zgodności, jakiej wymagają VPAT-y. UserWay oferuje profesjonalny ręczny audyt i usługę VPAT jako dodatek obok swojego produktu widżetowego, co warto wiedzieć, jeśli firma już korzysta z UserWay i potrzebuje dokumentacji na potrzeby konkretnej sprzedaży korporacyjnej.
Częste błędy przy tworzeniu VPAT
Najbardziej szkodliwym błędem jest przygotowanie VPAT wyłącznie na podstawie skanu automatycznego, a nie prawdziwych testów ręcznych; narzędzia automatyczne wychwytują istotny podzbiór kryteriów sukcesu WCAG, ale nie potrafią wiarygodnie ocenić wszystkiego, co VPAT ma potwierdzać, więc VPAT oparty wyłącznie na skanie ryzykuje zawyżeniem zgodności w sposób, który może później wyjść na jaw jako realny problem, zarówno reputacyjnie, jak i, w pewnych okolicznościach, prawnie. Drugim częstym błędem jest pozwolenie, by VPAT się zdezaktualizował: opisuje on dostępność produktu w danym momencie, a istotny redesign lub dodanie funkcji bez odpowiedniej aktualizacji VPAT pozostawia kupujących polegających na nieaktualnych informacjach. Wreszcie, ogólnikowe kolumny uwag (“spełnia wymóg” bez szczegółów) podważają wiarygodność dokumentu; zespół zakupowy lub odpowiedzialny za dostępność u kupującego zwykle bardziej zaufa VPAT, gdy uwagi konkretnie mówią, co przetestowano i jak.
Czytanie cudzego VPAT jako kupujący
Jeśli firma jest po stronie kupującej, ocena VPAT to inna umiejętność niż jego tworzenie. Warto spojrzeć poza podsumowanie na górze i sprawdzić kolumnę uwag pod kątem kryteriów istotnych dla danego zastosowania; ocena “Partially Supports” przy obsłudze klawiatury czy etykietowaniu formularzy zasługuje na więcej uwagi niż ta sama ocena przy czymś mniej centralnym dla tego, jak faktycznie użytkownicy będą korzystać z produktu. Warto sprawdzić datę wypełnienia VPAT, a jeśli ma więcej niż rok lub dwa lata, zapytać, czy produkt istotnie się od tego czasu zmienił. I traktować VPAT bez żadnych uwag, same zaznaczenia bez wyjaśnienia, jako sygnał, by zadać dodatkowe pytania, zanim zostanie się na nim oparta decyzja zakupowa, ponieważ to w uwagach zwykle kryje się prawdziwa treść oceny.
Jak VPAT-y wpisują się w szerszy obraz zgodności
VPAT dokumentuje zgodność jednego produktu; to nie to samo co ogólna zgodność organizacji z dostępnością, a posiadanie go dla kupionego oprogramowania nie sprawia automatycznie, że wszystko, co się na nim buduje, jest dostępne. Firma kupująca dobrze udokumentowaną, opartą na VPAT platformę może wciąż zbudować na niej niedostępny, niestandardowy interfejs, więc VPAT najlepiej traktować jako jeden z elementów decyzji zakupowej i oceny ryzyka związanego z dostawcą, a nie substytut testowania własnego, finalnego produktu, strony czy aplikacji, gdy wszystko już zostanie złożone i skonfigurowane do konkretnego zastosowania.
Ile zwykle trwa proces tworzenia VPAT
Dla produktu małej lub średniej wielkości prawdziwe testy zgodności, a następnie stworzenie dobrze udokumentowanego VPAT, to nie zadanie na tydzień; warto liczyć się z kilkoma tygodniami, uwzględniając zaplanowanie testów ręcznych obejmujących istotne kryteria sukcesu, ponowne testowanie tego, co nie przeszło, oraz spisanie konkretnych uwag, a nie ogólnych oznaczeń przejścia lub niepowodzenia. Większe, bardziej złożone produkty z wieloma komponentami interaktywnymi lub szerokim zakresem funkcji zajmują jeszcze więcej czasu. Zaplanowanie takiego harmonogramu z wyprzedzeniem w cyklu sprzedażowym lub terminie zamówienia pozwala uniknąć częstej pułapki tworzenia pospiesznego, ubogiego VPAT pod presją terminu, co zwykle prowadzi do dokładnie takiej niewiarygodnej, ogólnikowej dokumentacji, która podważa, a nie buduje zaufanie kupującego.
Warto zaplanować ten harmonogram w mapie rozwoju produktu obok głównych wydań, a nie jako reakcję na pojedynczą transakcję zakupową, która nagle go wymaga. VPAT stworzony spokojnie, według własnego harmonogramu, dla produktu już rzetelnie przetestowanego, jest zasadniczo innym (i bardziej wiarygodnym) dokumentem niż taki złożony w pośpiechu, by zamknąć transakcję, a kupujący regularnie czytający VPAT-y często potrafią odróżnić jeden od drugiego już po samej jakości uwag.
Jeśli firma potrzebuje VPAT dla swojego produktu
Warto zacząć od potwierdzenia, której edycji faktycznie się potrzebuje (wyłącznie WCAG, Section 508, EN 301 549 czy połączonej edycji INT) w zależności od tego, kto pyta i na jaki rynek się sprzedaje. Następnie zlecić prawdziwe testy względem istotnych kryteriów sukcesu, poprzez wewnętrznego specjalistę ds. dostępności lub zewnętrznego dostawcę testów i audytu, zanim wypełni się sam dokument. Warto traktować gotowy VPAT jako żywy dokument, do którego trzeba wracać po istotnych zmianach w produkcie, a nie jednorazowy produkt do odłożenia na półkę po zamknięciu pierwszej sprzedaży.