Nowy standard. Twoje centrum tworzenia inteligentnego, szybkiego i zrównoważonego oprogramowania AI
Table of Contents
Projektowanie inkluzywne w ochronie zdrowia oznacza tworzenie produktów cyfrowych, z których może korzystać jak najszersza grupa osób, także użytkownicy starsi, chorzy, zestresowani i z niepełnosprawnościami. W projektowaniu UX dla ochrony zdrowia jeden niedostępny ekran może zablokować przypomnienie o dawce leku, logowanie do portalu pacjenta albo wizytę telemedyczną. Europejski Akt o Dostępności obowiązuje od 28 czerwca 2025 roku, a terminy w USA przypadają na lata 2027 i 2028. W tym przewodniku wyjaśniamy, które przepisy będą dotyczyć aplikacji zdrowotnych w 2026 roku i jak projektować oraz testować rozwiązania tak, by wykraczać poza ich wymagania. Tekst powstał z myślą o Product Ownerach, projektantach i developerach HealthTech, którzy tworzą dostępny UX/UI w tym obszarze.
Podsumowanie
Projektowanie inkluzywne w HealthTech łączy bazowy poziom WCAG 2.2 AA z projektowaniem pod kątem codziennych warunków użytkowania. Ten poziom ma oparcie w prawie: Europejski Akt o Dostępności obowiązuje od czerwca 2025 roku, a amerykańskie przepisy dotyczące świadczeniodawców finansowanych przez HHS i podmiotów publicznych wejdą w życie w 2027 i 2028 roku. WCAG wyznacza techniczne granice, takie jak współczynniki kontrastu i rozmiary elementów interaktywnych, ale wiek, choroba, stres i język wpływają na to, jak pacjenci korzystają z każdego ekranu. Starszy pacjent z drżeniem rąk potrzebuje dużych, wyrozumiałych kontrolek w przypomnieniu o lekach, a pacjent czytający portal w drugim języku potrzebuje prostych sformułowań. Projektowanie doświadczeń użytkownika w HealthTech, które od pierwszego prototypu uwzględnia starsze osoby i użytkowników technologii asystujących, pozwala dotrzeć do większej liczby pacjentów.
Jak starzenie się społeczeństwa wpływa na projektowanie UX/UI w HealthTech?
Starzenie się społeczeństwa stawia starszych pacjentów w centrum projektowania UX/UI w HealthTech: stanowią oni coraz większą część populacji, a jednocześnie rzadziej korzystają z portali pacjenta. ONZ prognozuje, że do 2050 roku jedna na sześć osób będzie mieć ponad 65 lat, podczas gdy w 2019 roku była to jedna na 11. W USA osoby 65+ stanowiły 18% populacji w 2024 roku, a do 2040 roku będzie to około 22%.
Dostęp do internetowej dokumentacji medycznej jest oferowany szerzej, niż jest faktycznie wykorzystywany. W 2024 roku 77% Amerykanów otrzymało taki dostęp, a 65% z niego skorzystało; starsi pacjenci, osoby o niższych dochodach, z niższym poziomem kompetencji czytania i pisania oraz z ograniczoną znajomością angielskiego korzystali z niego rzadziej.
Projektowanie UX dla starszych osób w cyfrowej ochronie zdrowia zaczyna się od tej luki w użytkowaniu. Przepisy dotyczące dostępności obejmują tylko część problemu: wskazują, co aplikacja zdrowotna musi wspierać, na przykład czytniki ekranu i odpowiedni kontrast. Projektowanie inkluzywne i dostępność różnią się zakresem: projektowanie inkluzywne obejmuje też to, jak pacjenci korzystają z produktu na co dzień. Wymagania dotyczące dostępności mają dziś konkretne terminy prawne w UE i USA.
Jakie przepisy dotyczące dostępności obejmują aplikacje zdrowotne w 2026 roku?
Zgodność z wymaganiami dostępności w ochronie zdrowia wyznaczają trzy akty prawne: Europejski Akt o Dostępności w UE oraz Section 504 HHS i Title II ADA w USA. Wszystkie trzy opierają się na WCAG, czyli technicznym standardzie dostępnych produktów cyfrowych.
Amerykańskie przepisy wskazują WCAG 2.1 AA. WCAG 2.2 AA zachowuje niemal wszystkie kryteria WCAG 2.1 i dodaje sześć nowych, dlatego jest bezpieczniejszym wyborem wśród wytycznych dostępności dla oprogramowania medycznego.
Tabela pokazuje, które przepisy obejmują dostępność cyfrową w aplikacjach medycznych i od kiedy każdy z nich obowiązuje.
Przepisy | Kogo obejmują | Standard | Data |
|---|---|---|---|
Europejski Akt o Dostępności (UE) | Produkty i usługi konsumenckie, w tym rejestracja i zakładanie konta w aplikacji zdrowotnej | EN 301 549 (odzwierciedla WCAG 2.1) | Obowiązuje od 28 czerwca 2025 roku |
Section 504 HHS (USA) | Podmioty otrzymujące finansowanie z HHS i ich dostawcy | WCAG 2.1 AA | 11 maja 2027 roku (15+ pracowników); 10 maja 2028 roku (poniżej 15) |
Title II ADA (USA) | Władze stanowe i lokalne | WCAG 2.1 AA | 26 kwietnia 2027 roku (populacja 50 000+); 26 kwietnia 2028 roku (poniżej 50 000, specjalne okręgi) |
Section 508 (USA) | Technologie używane przez agencje federalne | Obowiązuje |
Zespoły telemedyczne mogą dodać też standard dostępności telemedycyny WHO-ITU, opublikowany w 2022 roku. Aplikacje zdrowotne, które są klasyfikowane jako oprogramowanie wyrobu medycznego, podlegają także unijnemu rozporządzeniu MDR dotyczącym wyrobów medycznych, które wymaga od producentów projektowania z myślą o osobach z niepełnosprawnościami.
Które kryteria WCAG 2.2 mają zastosowanie do aplikacji zdrowotnych?
WCAG 2.2 dodał sześć kryteriów poziomu A i AA, a wszystkie sześć ma znaczenie dla aplikacji zdrowotnych, od przycisków dawkowania po ekrany logowania. Każde z nich powinno znaleźć się w dobrych praktykach UI/UX dla oprogramowania medycznego.
Kryterium | Poziom | Przykład w aplikacji zdrowotnej |
|---|---|---|
2.5.8 Rozmiar celu (minimum) | AA | Przyciski dawki i odnowienia recepty o rozmiarze co najmniej 24x24 CSS px, możliwe do użycia przy drżeniu rąk |
2.5.7 Ruchy przeciągania | AA | Suwaki bólu lub dawkowania z alternatywą w postaci stuknięcia |
3.3.8 Dostępne uwierzytelnianie (minimum) | AA | Logowanie bez testów pamięciowych i zagadek |
3.3.7 Powtarzanie wprowadzania danych | A | Historia medyczna wpisywana tylko raz podczas wizyty |
3.2.6 Spójna pomoc | A | Link do pomocy w tym samym miejscu na każdym ekranie |
2.4.11 Fokus nie jest zasłonięty (minimum) | AA | Przyklejone bannery, które nigdy nie zasłaniają aktywnego pola formularza |
WCAG 2.2 usunął kryterium 4.1.1 Parsing. Kontrast tekstu pozostaje na poziomie 4,5:1 dla zwykłego tekstu i 3:1 dla dużego tekstu.
Jakie kary grożą za niedostępne aplikacje zdrowotne?
Kary obejmują zarówno pozwy i ryzyko utraty finansowania w USA, jak i krajowe grzywny oraz zakazy dystrybucji w UE. W 2025 roku powodowie w USA złożyli 3117 federalnych pozwów dotyczących dostępności stron internetowych, czyli o 27% więcej niż 2452 w 2024 roku; stanowiły one 36% spraw wnoszonych na podstawie Title III. W ramach Section 504 HHS Office for Civil Rights bada skargi, prowadzi przeglądy zgodności z przepisami i może kierować sprawy do Department of Justice. Zagrożone może być także finansowanie federalne.
Państwa członkowskie UE same ustalają wysokość grzywien za pośrednictwem organów nadzoru rynku. W Niemczech możliwe są grzywny do 100 000 euro. W Hiszpanii kary mogą sięgać do 1 mln euro za bardzo poważne naruszenia. Organy mogą też ograniczyć dystrybucję lub nakazać wycofanie produktu z rynku, a konsumenci mogą pozywać bezpośrednio w Irlandii i Holandii.
Jak zespoły HealthTech mogą wykazać zgodność z wymaganiami dostępności?
Zespoły wykazują zgodność za pomocą deklaracji dostępności, audytów kolejnych wydań, klauzul dotyczących dostępności w umowach z dostawcami oraz rejestru poprawek i ponownych testów.
Cztery zalecane praktyki dają audytorom i regulatorom jasny zapis działań:
Opublikuj deklarację dostępności z kanałem kontaktu do zgłaszania barier.
Audytuj każde wydanie za pomocą kontroli automatycznych i manualnych.
Dodaj wymagania dotyczące dostępności do umów z dostawcami, ponieważ przepis HHS obejmuje także dostawców.
Prowadź rejestr poprawek i ponownych testów, aby postępy były udokumentowane.
Czego standardy dostępności nie obejmują w aplikacjach zdrowotnych?
Standardy nie obejmują czterech obszarów: procesów prywatności, dostępu w sytuacjach nagłych, kompatybilności z urządzeniami i wyników działania AI. Każdy z nich wymaga decyzji produktowych wykraczających poza checklistę WCAG, szczególnie w kontekście technologii asystujących w HealthTech.
Procesy związane z prywatnością, takie jak ekrany zgody i logowanie, muszą działać z czytnikami ekranu i nawigacją klawiaturą. RODO wymaga wyraźnej, świadomej i jednoznacznej zgody.
Ścieżki awaryjne powinny być dostępne w kilku krokach, głosowo i za pomocą technologii asystujących.
Kompatybilność z urządzeniami wymaga osobnych testów, ponieważ aplikacje zdrowotne łączą się z czytnikami ekranu, przełącznikami sterującymi i urządzeniami ubieralnymi. W przypadku sprzętu zacznij od tworzenia połączonych wyrobów medycznych.
Teksty, podsumowania i napisy generowane przez AI wymagają takich samych kontroli dostępności jak każdy inny ekran.
Czy projektowanie inkluzywne poprawia wyniki pacjentów w aplikacjach zdrowotnych?
Korzystanie z portalu pacjenta poprawia przestrzeganie zaleceń dotyczących przyjmowania leków, natomiast wyniki dla wskaźników klinicznych są niejednoznaczne. Systematyczny przegląd 24 badań wykazał też częstsze korzystanie z usług profilaktycznych, a autorzy uznali, że dowody dotyczące ciśnienia krwi i poziomu glukozy są niewystarczające. Te korzyści zależą jednak od tego, czy pacjenci potrafią się zalogować, zrozumieć każdy ekran i wykonać zadania, takie jak odnowienie recepty.
Większość uczestników tych badań mówiła po angielsku i miała wysokie wykształcenie, więc wyniki mogą nie odnosić się do grup, które najrzadziej korzystają z portali: starszych pacjentów, osób o niższych dochodach, z niższym poziomem kompetencji czytania i pisania oraz z ograniczoną znajomością angielskiego. Zespoły produktowe mogą wypełnić tę lukę własnymi danymi, śledząc wykonanie zadań i korzystanie z portalu w tych grupach. Zespoły tworzące rozwiązania HealthTech dla chorób przewlekłych mogą zacząć od ścieżek odnowienia recept i przypomnień, ponieważ nieprzestrzeganie zaleceń dotyczących przyjmowania leków wiąże się co roku z kosztami od 100 do 300 mld USD w amerykańskiej ochronie zdrowia.
Jak uwzględnić dostępność w procesie projektowym w HealthTech?
Prace nad dostępnością zaczynają się na etapie discovery i trwają w każdym sprincie. Projektowanie zorientowane na człowieka w HealthTech zaczyna się od wywiadów z pacjentami i klinicystami, a potem te same grupy testują prototypy. Co-design rozszerza zespół o osoby korzystające z technologii asystujących, które pomagają kształtować ścieżki i treści.
W3C zaleca angażowanie użytkowników na każdym etapie projektowania i tworzenia oprogramowania oraz łączenie ich informacji zwrotnych ze sprawdzaniem zgodności ze standardami. Standardy wychwytują brakujące etykiety i zbyt niski kontrast. Użytkownicy wychwytują niejasne ścieżki, a czasem także błędne założenia produktowe: w projekcie Monterail Camino smart walker po wywiadach z użytkownikami zrezygnowano z planowanego dashboardu pacjenta, bo ludzie chcieli siedziska, czyli rozkładanego miejsca odpoczynku, gdy się męczyli.
Jakie są najlepsze praktyki w projektowaniu UX dla ochrony zdrowia?
Najlepsze praktyki w projektowaniu UX dla ochrony zdrowia łączą wymagania WCAG z prostym językiem i ścieżkami, które wymagają od użytkownika jak najmniej wysiłku. Obejmują dostępne projektowanie w ochronie zdrowia, w tym interfejsy dla osób z zaburzeniami poznawczymi.
Praktyka | Dlaczego to ważne |
|---|---|
Kontrast 4,5:1 (3:1 dla dużego tekstu) | Zapewnia czytelność tekstu osobom słabowidzącym |
Cele dotykowe o rozmiarze 24x24 CSS px lub większym | Pomagają użytkownikom z drżeniem rąk lub ograniczoną sprawnością manualną |
Pełna obsługa za pomocą klawiatury | Pozwala osobom niewidomym oraz użytkownikom sterowania głosem, klawiatur ekranowych i oprogramowania skanującego wykonać każde zadanie |
Zmniejsza obciążenie poznawcze, ponieważ wytyczne W3C dotyczące dostępności poznawczej zalecają minimalną liczbę prostych kroków | |
Działanie offline z synchronizacją | Pozwala korzystać z aplikacji także przy słabym połączeniu |
Prosty język sprawdzany za pomocą CDC Clear Communication Index | Pozwala mierzyć czytelność |
Ograniczona liczba trybów interfejsu | Assistive Access od Apple ogranicza aplikacje do tego, co najważniejsze, by zmniejszyć obciążenie poznawcze |
Jeśli szukasz pełnych ścieżek, zobacz przewodnik Monterail po projektowaniu UX aplikacji zdrowotnych z prototypowaniem AI.
Jakie są przykłady projektowania inkluzywnego w aplikacjach zdrowotnych?
Pięć przykładów inkluzywnych interfejsów w HealthTech pokazuje, jak usuwać konkretne bariery: Personal Voice od Apple przy utracie mowy, przypomnienia Medisafe w chorobach przewlekłych, proces parowania w Eargo dla starszych użytkowników, współprojektowanie szpitalnych usług w Dignity Project oraz napisy na żywo i telepresence wspierające osoby z problemami ze słuchem i ograniczeniami związanymi z odległością.
Jak interfejsy głosowe pomagają pacjentom zagrożonym utratą mowy?
Interfejsy głosowe pozwalają pacjentom tracącym mowę nadal komunikować się własnym głosem. Funkcja Personal Voice od Apple, ogłoszona w maju 2023 roku, została zaprojektowana z myślą o takich schorzeniach jak ALS. Dopóki pacjenci mogą jeszcze mówić, przez 15 minut odczytują na głos podpowiedzi, a iPhone tworzy kopię ich głosu. Później funkcja Live Speech pozwala wpisać wiadomość, która zostaje wypowiedziana tym głosem podczas połączeń telefonicznych i FaceTime. Kopia głosu powstaje na urządzeniu, co pozwala zachować prywatność nagrania. Funkcje głosowe w aplikacjach zdrowotnych opierają się na projektowaniu konwersacyjnym.
Jak przypomnienia pomagają użytkownikom aplikacji do przyjmowania leków?
Przypomnienia pomagają pacjentom trzymać się harmonogramu przyjmowania leków. Badanie ankietowe JMIR Human Factors z 2025 roku objęło aplikację Medisafe do przypominania o lekach i 30 dorosłych z chorobami przewlekłymi, którzy korzystają z opieki w federally qualified health center w północno-wschodnich Stanach Zjednoczonych. Po miesiącu korzystania wszystkie 30 osób zgodziło się, że poleciłoby aplikację innym, a 28 zdecydowanie zgodziło się ze stwierdzeniem, że przypomnienia pomogły im przyjmować leki na czas. Pięć na sześć osób miało ubezpieczenie publiczne, a taki sam odsetek chorował na co najmniej dwie choroby przewlekłe. Randomizowane badanie stojące za tą ankietą wykazało, że użytkownicy aplikacji lepiej przestrzegali zaleceń dotyczących przyjmowania leków niż osoby otrzymujące standardową opiekę. Przypomnienia o odnowieniu recept były w dużej mierze nieużywane, często dlatego, że uczestnicy już dostawali SMS-y z apteki.
Jak prostsze elementy sterujące pomagają starszym użytkownikom urządzeń?
Prostsze elementy sterujące pomagają starszym użytkownikom przejść przez najtrudniejszy etap, czyli parowanie urządzenia, a potem umożliwiają jego codzienną regulację. Case study Eargo od Monterail opisuje aplikacje do aparatów słuchowych regulowanych przez FDA, zaprojektowane z myślą o starszych użytkownikach o mniejszym obyciu technologicznym. Dwa tygodnie badań zmieniły kierunek projektu jeszcze zanim zespół zaprojektował jakikolwiek ekran. W grupie docelowej była między innymi 75-letnia osoba po raz pierwszy korzystająca z aparatu słuchowego, z ograniczonym obyciem technicznym, możliwymi ograniczeniami ruchowymi i bez doświadczenia w parowaniu medycznych urządzeń Bluetooth. Zespół stworzył niestandardowy proces parowania, wykraczający poza standardowe wzorce iOS i Androida, dostosowany do starszych użytkowników i obsługujący zarówno połączenia ultradźwiękowe, jak i Bluetooth. Profile słuchowe oraz inne proste mobilne kontrolki pozwalają potem użytkownikom dostosować urządzenie do różnych warunków otoczenia.
Jak wygląda współprojektowanie prowadzone przez osoby z niepełnosprawnościami w szpitalu?
Współprojektowanie prowadzone przez osoby z niepełnosprawnościami oddaje pacjentom z niepełnosprawnościami decydujący głos w nazywaniu problemów i kształtowaniu rozwiązań na każdym etapie pobytu w szpitalu. Griffith University i Metro South Health zastosowały to podejście w projekcie Dignity Project. Projekt zaplanowany na okres od lutego 2023 do lutego 2025 roku wykorzystywał platformę internetową, na której uczestnicy, szczególnie osoby z zaburzeniami poznawczymi, wskazywali główne wyzwania na każdym etapie ścieżki pacjenta. Celem było współprojektowanie rozwiązań dotyczących przyjęcia, opieki stacjonarnej i wypisu w placówkach Metro South Health. To projektowanie empatyczne w ochronie zdrowia w skali całego szpitala: osoby, których dotyczy usługa, kształtują ją od samego początku.
Jak AI i telepresence poszerzają dostęp pacjentów?
AI i telepresence poszerzają dostęp, usuwając bariery związane ze słuchem i odległością. AI w dostępnym UX obejmuje napisy na żywo i transkrypcje, dzięki którym wizyty wideo stają się użyteczne dla osób z ubytkiem słuchu. Tekst nadal musi być jasny, bo użytkownicy przestają ufać rekomendacjom, których nie rozumieją. Telepresence wyprzedza AI: system PEBBLES łączył hospitalizowane dziecko z jego zwykłą klasą w czasie rzeczywistym przez wideokonferencję, a autorzy badania odnotowali bardzo pozytywny ogólny efekt, najsilniejszy właśnie w przypadku tego dziecka.
Jakie wyzwania wiążą się z wdrażaniem projektowania inkluzywnego w aplikacjach zdrowotnych?
Cztery wyzwania spowalniają projektowanie inkluzywne w aplikacjach zdrowotnych: integracje z dostawcami, niski poziom kompetencji czytania i pisania oraz słaba łączność, obsługa języków i testowanie z odpowiednimi użytkownikami. Zaplanowanie każdego z tych obszarów jest częścią projektowania dostępnych aplikacji HealthTech.
Zakres wyznacza budżet. WCAG odradza wymaganie poziomu AAA jako ogólnej polityki dla całych serwisów, dlatego praktyczny plan zakłada poziom AA w całym produkcie i dodaje bardziej rygorystyczne kontrole tylko w ścieżkach o wysokiej wadze, takich jak dawkowanie, zgoda i dostęp awaryjny. Znaczenie ma też moment wdrożenia: W3C przywołuje badanie Forrester zlecone przez Microsoft, z którego wynika, że dostępność może przyczyniać się do oszczędności kosztów, jeśli jest częścią ciągłych cykli rozwoju oprogramowania.
Które integracje w aplikacjach zdrowotnych wymagają kontroli dostępności?
Każdy ekran dostawcy w ścieżce pacjenta wymaga sprawdzenia. Przepis HHS obejmuje treści internetowe i aplikacje dostarczane na podstawie umów z dostawcami, więc jeden niedostępny ekran dostawcy może przerwać całą ścieżkę i naruszyć zgodność świadczeniodawcy z przepisami. Przepis wyłącza treści stron trzecich tylko wtedy, gdy zostały opublikowane poza umową lub licencją ze świadczeniodawcą. Dlatego ekrany planowania wizyt, płatności rachunków i telemedycyny dostarczane przez vendorów powinny wchodzić do każdego audytu, a umowy z nimi powinny wymagać co najmniej WCAG 2.1 AA.
Jak niski poziom kompetencji czytania i pisania oraz słaba łączność zmieniają projektowanie aplikacji zdrowotnych?
Niski poziom kompetencji czytania i pisania wymaga prostych sformułowań i prostej nawigacji, a słaba łączność wymaga dostępu offline. Artykuł National Academy of Medicine z 2014 roku wskazuje, że prosty język pomaga użytkownikom znaleźć to, czego potrzebują, zrozumieć to i podjąć działanie. Ten sam artykuł zaleca spójną nawigację, ponieważ bez niej użytkownicy o niższych kompetencjach czytania i pisania mogą się pogubić albo utknąć. Działanie offline i synchronizacja pozwalają zachować dostęp do kluczowych funkcji bez stabilnego połączenia.
Jak różnice językowe wpływają na projektowanie aplikacji zdrowotnych?
Język kształtuje pierwszy ekran, który widzi pacjent. W badaniu JAMA Network Open z października 2025 roku, obejmującym 511 szpitali, 29% placówek oferowało logowanie do portalu wyłącznie po angielsku, 60% po angielsku i hiszpańsku, a 11% dodawało jeszcze jeden język. Mniej niż 5% oferowało najczęściej używany w swojej okolicy inny język.
National CLAS Standards, w sumie 15 standardów, obejmują kulturę, język i kompetencje zdrowotne. Standardy od 5 do 8 wymagają od organizacji ochrony zdrowia zapewnienia wsparcia językowego oraz zrozumiałych materiałów cyfrowych i drukowanych w powszechnie używanych językach. Dla zespołów tworzących aplikacje oznacza to przetłumaczone ekrany logowania i prosty język we wszystkich obsługiwanych wersjach językowych.
Jak zespoły powinny testować aplikacje zdrowotne z udziałem starszych osób?
Prowadź testy użyteczności nieformalnie przez cały proces tworzenia oprogramowania, zaczynając od prototypu, zamiast czekać na końcową rundę. W3C sugeruje, by uwzględniać kilka osób z niepełnosprawnościami oraz, zależnie od grupy odbiorców, starszych użytkowników. Zaleca też dopasowanie umiejętności korzystania z technologii asystujących do grupy docelowej, a publicznie dostępna aplikacja dla pacjentów wymaga udziału początkujących użytkowników. Jeden uczestnik nie reprezentuje wszystkich, więc w każdej rundzie potrzeba kilku różnych osób. Każda metoda testowania wykrywa inne problemy, dlatego plan testów powinien łączyć wszystkie trzy:
Metoda | Co wykrywa | Kiedy wykonywać |
|---|---|---|
Automatyczne kontrole | Problemy możliwe do wykrycia maszynowo, takie jak brakujące etykiety i zbyt niski kontrast | Przy każdej kompilacji |
Ręczny przegląd ekspercki | Kryteria, które wymagają oceny człowieka, takie jak korzystanie z klawiatury i czytnika ekranu | Przy każdym wydaniu |
Testy użyteczności z udziałem starszych użytkowników i osób z niepełnosprawnościami | Niejasne ścieżki i sformułowania | Od pierwszego prototypu |
Najważniejsze wnioski
Przepisy dotyczące dostępności obejmują dziś wiele aplikacji zdrowotnych: w UE jest to European Accessibility Act, obowiązujący od czerwca 2025 roku, a w USA przepisy dla świadczeniodawców finansowanych przez HHS i podmiotów publicznych z terminami w 2027 i 2028 roku. Najbezpieczniejszym celem przy tworzeniu produktu jest WCAG 2.2 AA.
Cztery obszary wymagają decyzji dotyczących dostępności wykraczających poza WCAG: przepływy związane z prywatnością i zgodą, dostęp w sytuacjach nagłych, zgodność z urządzeniami oraz wyniki generowane przez AI.
Pacjenci o niskich kompetencjach czytania, z ograniczoną znajomością angielskiego albo słabym połączeniem mogą korzystać z aplikacji, jeśli oferuje ona prosty język, przetłumaczone ekrany logowania i dostęp offline.
Korzystanie z portalu pacjenta wiąże się z lepszym przestrzeganiem zaleceń dotyczących leków, ale dane o efektach klinicznych są niejednoznaczne, więc zespoły powinny mierzyć realizację zadań we własnym produkcie.
Testy użyteczności pokazują to, czego nie wychwytuje sprawdzanie zgodności ze standardami, dlatego warto prowadzić je nieformalnie z udziałem starszych osób i użytkowników technologii asystujących już od etapu prototypu.
Jak zespoły HealthTech mogą przekuć projektowanie inkluzywne w przewagę produktu?
Zespoły HealthTech przekuwają projektowanie inkluzywne w przewagę produktu, gdy od etapu discovery finansują dwie warstwy: zgodność z przepisami i codzienną użyteczność. Warstwa prawna, czyli WCAG 2.2 AA oraz obowiązujące przepisy UE i USA, wyznacza minimum, którego potrzebuje każdy produkt. Warstwa użyteczności obejmuje prosty język, krótkie ścieżki, obsługę języków i testy z udziałem starszych osób, a także wpływa na to, jak łatwo pacjenci wykonują zadania takie jak przedłużanie recept czy umawianie wizyt.
Monterail projektuje i tworzy produkty zdrowotne, uwzględniając zgodność z przepisami w całym cyklu tworzenia oprogramowania, czego przykładem jest sześcioletnia współpraca z Eargo przy trzech generacjach urządzeń dopuszczonych przez FDA. Porozmawiaj z naszymi ekspertami HealthTech o tym, jak zadbać o dostępność już od etapu discovery.



)

