Ř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