Tato stránka je pouze pro čtení. Můžete si pouze prohlédnout zdrojový kód, ale ne ho měnit. Zeptejte se správce, pokud si myslíte, že něco není v pořádku.
{{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
Správa Detach Close
Stránka s tímto názvem ještě neexistuje

Odkaz vás zavedl na stránku, která ještě neexistuje. Můžete ji vytvořit stisknutím tlačítka Vytvořit stránku.