Pevná lhůta pro plán zlepšení neexistuje. Nařízení předepisuje, abyste problematická místa zmapovali a napravili, ale neuvedl žádný počet týdnů nebo měsíců, ve kterých to musí být provedeno. Doba trvání procesu v praxi závisí na třech věcech: na počtu problematických míst, na tom, kdo je řeší, a na tom, jak si daná osoba nebo kancelář to časově organizuje vedle bežné činnosti.
Co je pevně stanoveno, je pořadí. Nejprve zmapujete problematická místa, pak je prioritizujete, pak je napravíte a nakonec zaznamenáte, co se stalo a co ještě zbývá. Každá fáze má své tempo a právě přechody mezi těmito fázemi jsou místa, kde se projekty v praxi zasekávají.
Fáze mapování obvykle probíhá rychle
Kontrola klíčových stránek a důležitých procesů — nákupní krok, přihlašovací tok, kontaktní formulář — je obvykle věc dnů, ne týdnů. Automatizované testování odhaluje značnou část běžných problémů: chybějící alternativní texty, pole formuláře bez popisu, nedostatečný kontrast. Část požadavků se nedá testovat automaticky a je to uvedeno v každé zprávě; tyto problémy vyžadují pohled někoho, kdo stránku skutečně projde. Chcete-li nejprve vědět, zda je to pro vaši organizaci relevantní, než se do kontroly pustíte, poskytne krátký dotazník s přímou indikací tam přehled.
Prioritizace zabere čas, ne proto, že by byla obtížná, ale proto, že vyžaduje rozhodnutí
Seznam akcí s deseti až třiceti body vypadá přehledně, ale každý bod vyžaduje rozhodnutí: kdo se toho ujme, kdy, a jak naléhavé to je ve srovnání s ostatní prací. Toto je fáze, kde se mnoho projektů zpomaluje — ne kvůli technice, ale proto, že interně nikdo není vlastníkem seznamu. Seznam akcí v běžném jazyce bez WCAG-žargonu pomáhá: vedoucí kanceláře nebo odpovědný pracovník z HR nemusí vědět, co je ARIA-label, aby pochopit, že kontaktní formulář má problém. Co prioritizaci často zpomaluje, není obsah, ale chybějící jasná lhůta pro každý bod — přesně to, k čemu je určen plán zlepšení s termíny.
Provádění závisí na vývojáři, ne na právní úpravě
Skutečné opravy — úprava kódu, psaní alternativních textů, zvýšení kontrastu — leží mimo to, co provádí testovací služba. Axessia testuje, prioritizuje, zaznamenává a sleduje, ale neprovidí opravy. Doba trvání této fáze proto závisí na kapacitě vašeho vlastního vývojáře nebo kanceláře, která vaši stránku spravuje, a na tom, jak se tyto opravy vešly do sprintu nebo plánování. U e-shopu s jednoduchým motivem to může být do několika týdnů; u na míru vytvořeného řešení se složitým nákupním procesem se to snadno prodlužuje na měsíce, zvláště když opravy zasahují checkout nebo přihlašovací tok a vyžadují tedy další testovací cykly.
Zde také leží past překrytí-widgetu: ten slibuje rychlé řešení během jednoho dne, ale nesplňuje základní požadavek a nic nemění na základním kódu. Kdo si časem poradí s překrytím, ten čas později ztratí, když se ukáže, že problémy tam pořád jsou.
Zaznamenání a vysvětlení je nejkratší krok, pokud je vše ostatní správné
Jakmile jsou problémy vyřešeny, je vypracování prohlášení samo o sobě relativně rychlé — jde především o řádné zdokumentování vlastního posouzení. Tento krok se zasekne až tehdy, nejsou-li předchozí kroky řádně zaznamenány: bez průkazného posouzení není co pro prohlášení základovat. Více o tom, co je potřeba, je v znalostní bázi podle tématu.
A pak: každá změna otevírá cyklus znovu
Největším omylem ohledně doby trvání je, že se proces končí po zveřejnění prohlášení. Nová stránka, upravený proces objednávky nebo jiná aktualizace designu mohou představovat nová úzká místa, která znovu spouští cyklus testování, stanovení priorit a nápravy. To dělá z otázky "jak dlouho to trvá" vlastně otázku o opakujícím se procesu místo jednorázového projektu.
Chcete vědět, kde se vaše organizace nyní nachází a jaké konkrétní kroky jsou možné? Proveďte bezplatnou rychlou kontrolu nebo se podívejte, jak informace v sestavě vznikají a co přidává předplatné prostřednictvím přehledu cen.