Usługi IT dla sektora publicznego

Instytucje publiczne rzadko przychodzą do nas po „stronę w Laravelu”. Przychodzą z problemem. Ktoś zgłosił, że strona jest niedostępna. Albo przetarg wymaga zgodności z WCAG, a nikt w urzędzie nie wie, co to znaczy w praktyce. Albo strona stoi od dziesięciu lat, wykonawca dawno zniknął, a wtyczek do WordPressa boją się dotknąć nawet ci, którzy ją prowadzą.

Od 2019 roku instytucje publiczne w Polsce podlegają ustawie o dostępności cyfrowej, więc to już nie jest „miłe do posiadania”. Dobra wiadomość: da się to zrobić spokojnie, krok po kroku, i zwykle bez pisania całej strony od zera. Poniżej opisujemy, z czym najczęściej się spotykamy i jak to rozwiązujemy. Technologie, których używamy, zostawiliśmy na końcu, bo urząd zwykle bardziej obchodzi to, czy odbiór przejdzie bez nerwów, niż to, w czym napisano szablon :)

Z czym zwykle przychodzą instytucje

„Mamy obowiązek, ale nie wiemy, od czego zacząć”

To najczęstsza sytuacja i jedna z łatwiejszych do rozwiązania. Zaczynamy od rozmowy: ile macie stron i aplikacji, kto je utrzymuje, czy jest już deklaracja dostępności. Dopiero potem audyt. Nie wyceniamy „na oko”, bo między stroną na trzydzieści podstron a portalem z e-usługami jest taka różnica jak między remontem łazienki a budową domu.

Raport nie jest sztuką dla sztuki. Dostajecie listę błędów z priorytetami: co blokuje korzystanie ze strony już teraz, a co może poczekać do następnego kwartału. Poprawki wdroży nasz zespół albo Wasz dotychczasowy dostawca, i wtedy raport jest dla niego zwykłą specyfikacją. Na końcu pomagamy napisać deklarację dostępności. Taka deklaracja nie powinna być wzorem wypełnionym na szybko, tylko opisem tego, co faktycznie działa. I trzeba ją aktualizować po zmianach na stronie, więc nie jest to dokument do odłożenia do szuflady.

„Strona działa, ale nikt jej nie rusza”

Stary serwis, nieaktualne wtyczki, szablon po poprzednim wykonawcy i pytanie: czy to w ogóle da się uratować? Zwykle tak. Przykładem są Wodociągi Raciborskie. Strona już istniała, więc nie budowaliśmy jej od nowa. Najpierw audyt zgodności z WCAG 2.1, potem druga faza: korekty w strukturze HTML, poprawki w stylach CSS i tryb wysokiego kontrastu. Efekt? Strona spełnia wymagania ustawy, a zgłoszenie awarii zajmuje użytkownikom mniej czasu, co dla wodociągów jest akurat ważniejsze niż kolejny ładny baner.

Czasem uczciwie mówimy co innego: tej strony nie opłaca się łatać. Gdy szablon jest poskładany tak, że poprawka jednego błędu psuje trzy inne, lepiej zaplanować nową wersję. Powiemy to po audycie, na podstawie raportu, a nie z góry, żeby sprzedać nową stronę.

„Wykonawca poprawił kod, a problemy wróciły”

To zaskakuje najbardziej. Audyt wyszedł dobrze, a trzy miesiące później redaktor wrzucił skan uchwały jako obrazek w PDF-ie. Dostępność ma trzy warstwy: kod, wygląd i treść. O tej trzeciej zwykle zapomina się zaraz po odbiorze.

Dlatego oferujemy też szkolenia dla zespołów redakcyjnych: jak opisywać zdjęcia, układać nagłówki, pisać linki inaczej niż „kliknij tutaj” i przygotowywać dokumenty tak, żeby czytnik ekranu w ogóle miał co czytać. Dzięki temu strona, za którą zapłaciliście, zostaje dostępna również po tym, jak wykonawca skończy pracę.

Test, który możecie zrobić sami

Odłóżcie mysz i przejdźcie przez własną stronę samym klawiszem Tab. Widać, gdzie jesteście? Da się wejść do menu, wyszukiwarki i formularza kontaktowego, a potem z nich wyjść? Jeśli w którymś momencie tracicie orientację, to samo spotyka każdego, kto nie używa myszy: osoby z niepełnosprawnością ruchową, ze złamaną ręką, ale też zwykłych użytkowników, którzy po prostu wolą klawiaturę.

Ten test nie zastąpi audytu, ale po pół minuty wiecie, czy rozmowa z nami będzie krótka, czy długa.

Co najczęściej znajdujemy w audytach

Lista jest do bólu powtarzalna i dotyczy zarówno małych, jak i dużych serwisów:

• zdjęcia i grafiki bez opisu alternatywnego albo z opisem w stylu „IMG_2043.jpg”
• zbyt niski kontrast tekstu: szare na jasnoszarym wygląda elegancko, dopóki ktoś nie spróbuje przeczytać tego na słońcu
• niewidoczny fokus klawiatury, czyli dokładnie to, co pokazuje powyższy schemat
• formularze bez powiązanych etykiet i błędy oznaczone samym kolorem
• nagłówki dobrane „bo ładnie wyglądają”, a nie po to, żeby zbudować strukturę strony
• dokumenty w PDF-ach będących skanami, których nie przeczyta żaden czytnik ekranu
• linki „więcej” i „kliknij tutaj”, które bez otoczenia nic nie mówią

Dobra wiadomość jest taka, że większość tych rzeczy da się poprawić bez zmiany wyglądu strony. Wasi odbiorcy zauważą tylko, że wreszcie wszystko działa.

BIP, e-usługi i formularze: kiedy wystarczy CMS, a kiedy potrzebna jest aplikacja

Strona instytucji to zwykle dwie różne rzeczy sklejone w jedną: treści (aktualności, ogłoszenia, BIP) oraz funkcje (rejestracja, logowanie, składanie wniosków). Pierwsze świetnie obsłuży system zarządzania treścią, drugie często wymaga osobnego modułu. Błąd popełnia się w obie strony: albo buduje się aplikację tam, gdzie wystarczyłby WordPress, albo w WordPressie dokleja się kolejne wtyczki do rejestracji i płatności, aż całość przestaje być możliwa do utrzymania.

Tak zrobiliśmy w Szpitalu Wojewódzkim im. św. Łukasza w Tarnowie. Nowa strona, zgodna z WCAG, ma Biuletyn Informacji Publicznej, który automatycznie aktualizuje dokumenty i ogłoszenia, oraz moduł e-rejestracji pacjentów. Treści prowadzi się wygodnie w WordPressie, a to, co wymaga własnej logiki, powstało w Laravelu i Vue. Pacjent widzi jeden serwis. Zamiast wydzwaniać rano do rejestracji, może umówić wizytę online, i to jest akurat efekt, który widać po obu stronach: pacjent ma spokój, a rejestracja mniej telefonów.

Nasza zasada jest prosta: najtańszy system to ten, którego nie trzeba budować. Jeśli Wasze potrzeby mieszczą się w dobrze skonfigurowanym CMS, tak Wam powiemy, nawet jeśli wolelibyśmy zrobić coś większego :)

Aplikacje mobilne też podlegają ustawie

O tym wiele instytucji przypomina sobie na końcu. Dla Komendy Wojewódzkiej Policji w Katowicach audytowaliśmy nie tylko stronę internetową, ale także aplikację mobilną „Śląska Policja”. Aplikację sprawdza się inaczej niż stronę: na prawdziwym telefonie, z czytnikiem ekranu systemu, z palcem zamiast myszy i bez luksusu dużego monitora. Po stronie zamawiającego opinia była krótka i konkretna: audyt przeprowadzono sprawnie i terminowo. Przyznajemy, że dla firmy usługowej to jedna z fajniejszych rekomendacji, jakie można dostać.

Przetarg i odbiór: jak nie dać się zaskoczyć

Jeśli kupujecie stronę lub aplikację w przetargu, zapis „zgodność z WCAG” to za mało. Dopiszcie poziom zgodności (zwykle AA), wersję wytycznych, sposób odbioru i to, kto przygotuje deklarację dostępności. Bez tego odbiór zamienia się w dyskusję na zasadzie „u nas wszystko działa”, a wykonawca i zamawiający mają dwa różne wyobrażenia o tym, co znaczy „dostępne”.

Najlepszym kryterium odbioru jest raport z audytu zrobionego niezależnie od wykonawcy. Możemy go przygotować, kiedy stronę buduje ktoś inny, a Wy chcecie mieć spokojną głowę. Na życzenie przejrzymy też zapisy o dostępności w opisie przedmiotu zamówienia, zanim trafi do ogłoszenia, bo poprawianie ich po rozstrzygnięciu jest znacznie droższe.

Czego nie obiecujemy

Nie obiecujemy, że po audycie wszystko będzie naprawione w tydzień. Nie obiecujemy też „zgodności na zawsze”, bo strony się zmieniają, a dostępność trzeba pilnować tak samo jak bezpieczeństwo. Obiecujemy za to konkretny, czytelny raport, uczciwą wycenę i terminowość. Ta ostatnia powtarza się w rekomendacjach, które dostajemy od klientów z sektora publicznego, więc chyba nie jest to przypadek :)

Co dla Was robimy

Audyty WCAG

Przeprowadzamy audyty zgodności z WCAG (Web Content Accessibility Guidelines), żeby sprawdzić, czy Wasza strona spełnia standardy dostępności cyfrowej. Audyt obejmuje identyfikację i ocenę błędów oraz wskazówki, jak je naprawić. Szczegóły procesu opisaliśmy na stronie Audyty dostępności WCAG.

Dostosowanie stron do dostępności cyfrowej

Modernizujemy i dostosowujemy istniejące strony internetowe do wytycznych dostępności cyfrowej. Dzięki temu serwis staje się przyjazny dla osób z różnymi potrzebami, a Wy spełniacie wymagania ustawy.

Tworzenie stron WWW dla sektora publicznego

Tworzymy zaawansowane strony internetowe, także dla instytucji publicznych. Korzystamy z PHP (Laravel / WordPress), HTML i CSS, żeby dostarczyć rozwiązania dopasowane do potrzeb użytkowników Waszego serwisu.

Przykładowe realizacje

Dostosowanie witryny Wodociągi Raciborskie do wymagań dostępności cyfrowej WCAG

• #s-publiczny
• #wcag

• #WCAG
• #HTML
• #CSS

Zobacz realizację: Dostosowanie witryny Wodociągi Raciborskie do wymagań dostępności cyfrowej WCAG

Strona internetowa Szpitala Wojewódzkiego im. Św. Łukasza w Tarnowie

• #medycyna
• #s-publiczny

• #Wordpress
• #Laravel
• #PHP
• #MySQL
• #JavaScript
• #VUE.JS

Zobacz realizację: Strona internetowa Szpitala Wojewódzkiego im. Św. Łukasza w Tarnowie

Audyt dostępności cyfrowej WCAG aplikacji mobilnej

• #s-publiczny
• #wcag

• #WCAG
• #HTML
• #CSS

Zobacz realizację: Audyt dostępności cyfrowej WCAG aplikacji mobilnej

Technologie, których używamy

Dla porządku, bo przetargi i działy IT zwykle o to pytają, to nasze podstawowe narzędzia przy budowie stron sektora publicznego.

PHP

PHP to popularny język programowania serwerowego wykorzystywany do tworzenia dynamicznych stron internetowych. W desi9n.pl korzystamy z PHP do dostarczania spersonalizowanych rozwiązań IT dla sektora publicznego. Oferujemy:

• Tworzenie efektywnych i skalowalnych aplikacji webowych
• Wsparcie dla serwerów baz danych i integrację z różnymi systemami
• Rozwinięte możliwości programowania dostosowane do unikalnych potrzeb klienta

HTML

HTML (Hypertext Markup Language) jest fundamentalnym językiem do tworzenia struktur stron internetowych. W naszej pracy korzystamy z HTML, aby zapewnić:

• Tworzenie semantycznych i dostępnych treści
• Zgodność z najlepszymi praktykami dostępności i kompatybilności przeglądarek
• inkluzywność treści dla osób ze specjalnymi potrzebami

CSS

CSS (Cascading Style Sheets) to technologia służąca do definiowania wyglądu i stylu stron internetowych. Nasz zespół wykorzystuje CSS, aby dostarczyć:

• Intuicyjny i atrakcyjny interfejs użytkownika
• Dopasowanie stron do indywidualnych preferencji wizualnych
• Optymalizację responsywności strony na różnych urządzeniach
• Tryb wysokiego konstrastu i powiększonych fontów dla osób słabowidzących

Wordpress

Wordpress to popularny system zarządzania treścią, który stosujemy do tworzenia stron internetowych dla sektora publicznego. Nasze usługi oparte na Wordpress obejmują:

• Szybkie wdrożenie i konfigurację strony internetowej
• Stworzenie dedykowanego szablonu i funkcjonalności pod unikalne potrzeby klienta
• Łatwe zarządzanie treścią i aktualizacje witryny

Laravel

Laravel to popularny framework PHP wykorzystywany do tworzenia aplikacji webowych. W przypadku większych wdrożeń, korzystamy z spersonalizowanych rozwiązań opartych na Laravel, co zapewnia:

• Skalowalność i wydajność aplikacji
• Bezpieczeństwo i zaawansowane funkcje programistyczne
• Tworzenie spersonalizowanych aplikacji dostosowanych do unikalnych potrzeb klienta
• Otwartość na integrację z innymi systemami