{{tag>hotovo}} # Řešení přístupnosti v rámci jednotlivých kroků životního cyklu IS ---- dataentry ---- Typ_tags: Část Anotace: Detailní uvedení konkrétních kroků a souvislostí přístupnosti v rámci kroků fází cyklu ISVS respektive ICT řešení ve veřejné správě Téma_tags: Přístupnost informací, Přístupnost veřejné správy, wmaa---- Stav: Vydáno ---- 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 [[predpis:360/2023]]. 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 [[egdilna:detailni-rozpad-prvnich-fazi-zivotniho-cyklu-is-ict|]] a [[ga:wmaa:reseni-pristupnosti-v-ramci-fazi-zivotniho-cyklu-is]] 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