Řešení přístupnosti v rámci jednotlivých kroků životního cyklu IS

V rámci jednotlivých fází životního cyklu informačního systému či technického řešení jsou definovány určité povinné kroky, kupříkladu dle vyhlášky 360/2023 Sb. (vyhláška o dlouhodobém řízení). Některé tyto kroky mají vazbu i na přístupnost služby jako takové, ale i na technickou přístupnost řešení.

Rozdělení a podrobnosti vychází z Detailnější rozpad přípravných fází životního cyklu IS/ICT řešení a Jak řešit přístupnost a potřeby OZP v jednotlivých fázích životního cyklu IS a ICT řešení

Níže je uvedeno, na co obecně myslet a kde a jakým způsobem se přístupnost má v rámci těchto kroků řešit:

• Fáze 1: Strategické plánování vytvoření a rozvoje řešení
  • Krok Vznik a analýza potřeby
    • Po celou dobu se nezapomíná na to, že defacto jakoukoliv službu a jakoukoliv interakci s veřejnou správou mohou rovnoprávně činit i OZP a musí se na to myslet ve všech fázích a počítat s tím
  • Krok První architektonické posouzení potřeby a souladu potřeby s architekturou
    • V rámci jakéhokoliv záměru či architektonického rozmýšlení se přístupnost zmiňuje jako jeden z klíčových principů a to včetně souladu s IKČR, ale především v souladu se zákonnými požadavky
    • Do legislativního rámce se nezapomene uvést i povinnost přístupnosti podle zákona 99/2019 a § 93 ZZVZ
  • Výstup Architektonický záměr nebo koncept
    • Ani v první architektuře na to nezapomínáme. Máme-li kdekoliv jako byznys nebo motivační prvek člověka, jde také automaticky o OZP.
    • Do motivace nezapomeneme uvést příslušné architektonické principy včetně principu 3 z IKČR. Dále do architektury na motivační vrstvu dáme princip přístuposti řešení a jako cíl i Naplnění potřeb osob se zdravotním postižením
  • Výstup Investiční záměr
    • V IZ se uvede, že se od počátku myslí na přístupnost a ta bude součástí dodávky a výsledku, tedy přístupnost nebude znamenat pozdější neoprávněné navyšování finančních prostředků na řešení
  • Výstup Formulář OHA
    • V rámci souladu s IKČR je nutné zodpovědět soulad s principem č. 3
    • U technického řešení, třeba portálu nebo informačního systému se posuzuje, zda se myslí na přístupnost
    • V rámci otázek na uživatelské rozhraní se řeší také UX, shoda s národním designsystémem a to včetně přístupnosti
    • Je vhodné popsat i to, že dbáte na přístupnost u všech veřejných zakázek (povinnost podle § 93 ZZVZ)
    • U testování a spolupráce se stakeholdery a to včetně uživatelů deklarujete i to, jak jste řešili potřeby OZP
• Fáze 2: Plánování a příprava vytvoření a rozvoje řešení
  • Krok Seznam požadavků na řešení
    • Obecným klíčovým požadavkem je přístupnost. A to zejména přístupnost u výrobnků, zařízení informačních systémů, jakýchkoliv rozhraní, dokumentů a výpisů apod.
    • Základní požadavky na naplnění povinností přístupnosti zejména podle zákona 99/2019, 499/2004 a případně 424/2023
    • V požadavcích na testování a ověření jsou i požadavky na otestování přístupnosti dle požadavků příslušných technických norem a rámců
  • Výstup Studie proveditelnosti
    • Ve studii proveditelnosti se posoudí možný rozsah využívání i osobami se zdravotním postižením, vychází se přitom z maximální varianty a z předpokladu, že OZP budou využívat služby či systém v maximální míře
    • Přístupnost se zmiňuje jako jeden ze základních principů, studie proveditelnosti obsahuje popis potřeby přístupnsoti a to pro jednotlivé oblasti (webové rozhraní, aplikace, dokumenty, výstupy, uživatelská rozhraní, procesy služby apod,)
    • Nesplnění přístupnosti se považuje za riziko s významným dopadem v rámci řízení rizik projektu
  • Krok Návrhy řešení a výběr řešení
    • Přístupnost sama neovlivňuje způsob řešení. Pouze je nutné u jakéhokoliv navrhovaného a pak vybraného řešení mít vyřešenou i přístupnost. Teoreticky je možné, že třeba nedostatečné znalosti vnitřních vývojářů k přístupnosti mohou ovlivnit, zda se bude realizovat vlastním vývojem, nebo externí dodávkou apod.
  • Krok Formalizovaný exit plán
    • Nepřístupné řešení je důvodem pro okamžitý exit
  • Krok Architektura řešení
    • Přístupnost zohledníme na všech vrstvách architektury
• Fáze 3: Realizace vytvoření a rozvoje řešení
  • Krok Zadávací dokumentace
    • Povinným požadavkem je přístupnost podle § 93ZZVZ
    • U uživatelských rozhraní, webových stránek a rozhraní a u mobilních aplikací povinné požadavky na přístupnost a soulad s rámcem WCAG a případně dalšími technickými normami
    • Konkrétní funkcni a technické požadavky na přístupnost pro vsegny relevantní oblasti řešení
    • Nezapomenout na přístupnost digitálních dokumentů, zejména u dokumentů vytvářených a generovaných řešením
  • Krok Veřejná zakázka nebo vývoj
    • Obecná deklarace povinné přístupnosti podle § 93 ZZVZ
    • Pokud uchazeč nedeklaruje přístupnost, bude vyloučen pro nesplnění obecných závazných podmínek
    • Při kvalifikaci požadovat reference jen na zakázky splňující § 93
  • Krok Smluvní zajištění dodávek
    • Požadavek na přístupnost je součástí smlouvy
    • Ve smlouvě se přímo deklaruje přístupnost podle § 93 ZZVZ a dalších relevantních předpisů
    • V rámci smlouvy se zajišťuje i dodání dokumentace k přístupnosti a to včetně testů a výsledků testů
  • Krok Realizace
    • V realizačním projektu se na úrovni řízení projektu i běžných pracovních balíčků myslí na přístupnost, včetně plnění konkrétních požadavků
    • O přístupnosti se jedná s dodavatelem průběžně a nenechává se to až na akceptační fázi
    • Průběžně v etapách vývoje se sleduje a testuje přístupnost
    • Přístupnost je oblastí pro součinnost a spolupráci zadavatele s dodavatelem
  • Krok Posouzení výsledku s požadavky
    • V rámci testování se provádí testy přístupnosti a to jak automatizované, tak i uživatelské testy
  • Krok Vytvoření provozní dokumentace
    • V provozní dokumentaci se v části architektury zmíní i architektonické znalosti v souvislosti s OZP
    • U dokumentace uživatelského rozhraní se uvede posouzení přístupnosti a případné speciality
    • V Provozním řádu pro uživatele se zmíní možnosti nastavení přístupnosti na úrovni uživatele v uživatelském rozhraní systému
    • V části s testováním a výsledky testů se uvede i výsledek testování na splnění požadavků přístupnosti
  • Krok Zkušební provoz
    • V rámci testování ve zkušebním provozu se realizuje také testování přístupnosti daných uživatelských rozhraní a to jak automatizovaně, tak i uživatelsky
    • Výsledky testování přístupnosti se uvedou v rámci testovací dokumentace jako součást dokumentace zkušebního provozu jako podklad pro kolaudační stanovisko OHA
  • Krok Akceptace produkčního prostředí
    • Při vývoji, testování a akceptaci zahrnout přístupnost
    • Bez otestované přístupnosti nelze akceptovat
    • Nedodržení přístupnosti není dílčí ani nezávažná vada pro akceptaci s výhradou
• Fáze 4: Produkční provoz řešení
  • Krok Řízení požadavků a změn
    • Mezi spravované a řešené požadavky patří i požadavky související s přístupností (tedy ne jen samotné požadavky na přístupnost)
    • Požadavky související s přístupností se vedou v rámci jejich správy a vyřizování jako samostatná kapitola, nebo s příslušným příznakem, aby je bylo možno vyhodnocovat najednou
    • Požadavky na přístupnost jsme povinni považovat za rizikové a za prioritní v rámci splnění legislativních povinností a tak se k nim i chovat
  • Krok Zajištění a vyhodnocování testů
    • Součástí jsou i testy přístupnosti a testy UX
  • Krok Školení uživatelů
    • Součástí školení je i problematika přístupnosti
    • U školení nezapomínáme na školení jak tvořit přístupný obsah, protože jedna věc je platforma, ale daleko důležitější je jednotlivý obsah
    • Součástí musí být i přístupnost dokumentů
  • Krok Podpora uživatelů
    • Musíme myslet na to, že u většiny systémů jsou našimi uživateli i úředníci a zaměstnanci úřadu, na to se často dostatečně nemyslí. I oni mohou být OZP a někdy jsou potřeby interních OZP doslova ignorovány.
    • Mezi procesy podpory uživatelů patří i reakce na požadavky a dotazy stran přístupnosti, nebo i obecné dotazy od OZP
• Fáze 5: Vyhodnocení životního cyklu řešení
  • Krok Zpětná vazba od uživatelů a náměty na změny
    • Pozor na připomínky, podněty a stížnosti na přístupnost od uživatelů. Ty jsme povinni řešit a to vlastně přednostně, abychom neprohlubovali diskriminační chování.
    • V rámci zpětné vazby se sledují i podněty a připomínky OZP a to jak z pohledu uživatelského rozhraní, tak i z pohledu technického řešení, nezapomínáme uvádět i související opravy a nápravy přístupnosti
    • V rámci prohlášení o přístupnosti nezapomeneme poskytnout jednoduše dosažitelné kontakty, kam se mají vznášet stížnosti a náměty od uživatelů
  • Krok Průběžné vyhodnocování funkčnosti řešení
    • Sleduje se i přístupnost a to jak z pohledu uživatelského rozhraní, tak i z pohledu technického řešení
    • Sleduje se i přístupnost dokumentů a výstupů
    • Sbírají se také anonymizované statistické údaje o používání rozhraní uživateli, u kterých prohlížeč deklaruje příznak používání asistivní technologie
  • Krok Vyhodnocování efektivity provozu a prostředků
    • Sledují se i potřebné průběžné úpravy spojené se zlepšením přístupnosti