Szkolenia techniczne (Dev / QA / UX)

Twój zespół przestanie powtarzać
te same błędy.

Szkolenia z dostępności dla programistów, QA i UX, dopasowane do roli. Zespół ćwiczy na komponentach, które psują się najczęściej, z klawiaturą i czytnikiem ekranu, i wychodzi wiedząc, jak sprawdzić własną pracę.

Przeszkol zespół

Dlaczego te same błędy wracają
po każdym wydaniu

Audyt pokazuje stan produktu w dniu testów. Wyłapuje to, co w nim wtedy jest. W kolejnym sprincie dochodzą modal, panel filtrów i tabela danych. Znajdzie je dopiero następny audyt.

Po poprawce zostaje nawyk, który doprowadził do błędu

Testujemy widoki i ścieżki objęte zakresem. Komponentu, który powstanie za tydzień, wśród nich nie ma. Kiedy ten sam programista podejmie tę samą decyzję przy własnym dropdownie, trafi ona do kolejnego raportu.

Testy automatyczne zostawiają trudne decyzje zespołowi

Skaner automatyczny wyłapie brakującą etykietę. Czy istniejąca etykieta ma sens i gdzie trafił fokus po zamknięciu okna dialogowego, musi ocenić ktoś z zespołu, kto wie, co nacisnąć i czego słuchać.

Szkolenie z dostępności cyfrowej dla programistów

O tym, co psuje czytnik ekranu, decyduje najczęściej sam HTML.

Po szkoleniu programista spojrzy na HTML komponentu, przewidzi, co odczyta NVDA, i sprawdzi to w samym czytniku.

Zapytaj o szkolenie dla programistów

Semantyczny HTML: co <button> ma wbudowane, a co przy <div role="button"> trzeba dopisać ręcznie
Wyliczanie dostępnej nazwy i to, jak aria-label na linku po cichu zastępuje jego widoczny tekst
Role ARIA: dlaczego <h2 role="button"> znika z listy nagłówków i kiedy ARIA mimo wszystko jest dobrym wyborem
Obsługa z klawiatury poza Tabem: strzałki w zakładkach i menu, Escape, Home i End
Zarządzanie fokusem: gdzie ma trafić fokus po usunięciu wiersza, zamknięciu okna dialogowego albo zmianie widoku w routerze
Comboboxy, modale, zakładki i sekcje rozwijane oraz przypadki, w których wystarczy wbudowany <dialog> albo <details>
Błędy w formularzach i aria-describedby: dlaczego czytnik często pomija komunikat, który pojawia się, gdy pole ma fokus
Stany ARIA, np. aria-expanded, aria-pressed i aria-current, oraz to, co odczyta NVDA, gdy użyjesz niewłaściwego
Live regions: dlaczego region dodany do strony razem z komunikatem często milczy
Tryb przeglądania w NVDA: dlaczego handler strzałek może nigdy nie dostać zdarzenia
forced-colors: wskaźniki fokusu z box-shadow i tła z gradientem, które Windows usuwa, gdy narzuca własną paletę

Szkolenie z dostępności cyfrowej dla projektantów UX

Najtańsza poprawka dostępności to zmiana w makiecie.

Kontrast, stany fokusu, obsługa błędów i reflow to decyzje projektowe. Każdy problem, który wyjdzie dopiero w gotowym komponencie, oznacza ticket, zmianę w kodzie i retest.

Zapytaj o szkolenie dla UX

Kontrast tekstu: cienkie, drobne litery, które mają 4,5:1, a i tak źle się je czyta, oraz to, co inaczej mierzy APCA
Kontrast elementów nietekstowych (WCAG 1.4.11): obramowania pól, ikony i wskaźniki fokusu, które wymagają kontrastu 3:1 względem tła
Tekst na zdjęciach i gradientach: kontrast mierzony tam, gdzie tło za literami wypada najgorzej
Odstępy w tekście (WCAG 1.4.12): przyciski i karty o stałej wysokości, które ucinają tekst, gdy użytkownik zwiększy odstępy
Wskaźniki fokusu dla każdego komponentu, bo stanu, którego brakuje w makiecie, zwykle brakuje też w kodzie
Przyciski z samą ikoną: dostępna nazwa dla każdego z nich, zapisana w projekcie, żeby programista nie musiał jej zgadywać
Nagłówki: struktura, po której porusza się użytkownik czytnika ekranu, często inna niż skala typograficzna
Reflow przy 320 px: które treści mogą się przewijać w poziomie, np. tabele danych i mapy, a które muszą się zawijać
Powiększenie 400%: na laptopie 1280 × 800 zostaje najwyżej 320 × 200 pikseli CSS. Przyklejony nagłówek może wtedy zająć jedną trzecią wysokości, a przycisk zamykania okna dialogowego wylądować poza ekranem
Tryb wysokiego kontrastu (Windows High Contrast Mode): zaznaczone zakładki i przełączniki wyróżnione tylko kolorem tła, który ten tryb podmienia
Stany ładowania, braku danych i błędu oraz to, co słyszy użytkownik czytnika ekranu, kiedy kręci się spinner
Adnotacje dostępności, według których programista zbuduje interfejs: kolejność fokusu, nazwy, poziomy nagłówków i to, co czytnik odczyta w każdym stanie

Szkolenie z dostępności cyfrowej dla QA i testerów

W teście brytyjskiego rządu najlepsze narzędzie automatyczne znalazło 41% barier, które celowo umieszczono na jednej stronie. Pokażemy Wam, jak znaleźć resztę.

Jeśli axe nic nie znalazł, spełnione są reguły, które da się sprawdzić automatycznie. Gdzie trafia fokus, co odczytuje NVDA i czy użytkownik klawiatury dotrze do ekranu potwierdzenia, musi sprawdzić tester.

Zapytaj o szkolenie dla QA

Kryteria sukcesu WCAG jako przypadki testowe z warunkiem zaliczenia, który dwie różne osoby ocenią tak samo
Testy z samą klawiaturą: czy da się dojść do każdej kontrolki, obsłużyć ją, wyjść z niej i potem odnaleźć fokus
Fokus po usunięciu elementu lub wysłaniu formularza: jak go znaleźć przez document.activeElement albo NVDA+Tab, kiedy na ekranie go nie widać
Testy z czytnikiem ekranu: NVDA w Firefoksie i Chromie, VoiceOver w Safari i dlaczego wynik dotyczy konkretnej pary czytnika z przeglądarką
Tryb przeglądania i tryb formularza, czyli dlaczego jedna strona zachowuje się jak dwie
Nagłówki, punkty orientacyjne i lista elementów w NVDA: tak przegląda stronę użytkownik czytnika ekranu
Dostępne nazwy: co odczytuje czytnik, kiedy różni się to od widocznej etykiety i kiedy ta różnica łamie kryterium WCAG 2.5.3, ważne dla osób sterujących głosem
Stany ARIA i live regions: czy czytnik w ogóle odczytał zmianę
Błędy w formularzach: czy czytnik odczytuje każdy z nich, czy jest powiązany z polem i czy da się do niego dotrzeć po wysłaniu
Powiększenie 400%: tekst, który trzeba przewijać w poziomie (WCAG 1.4.10), i pole z fokusem schowane pod przyklejoną stopką (WCAG 2.4.11)
Emulacja wymuszonych kolorów i ograniczenia ruchu w DevTools oraz to, kiedy potrzebny jest jednak Windows z włączonym motywem kontrastu
Co axe zgłasza, czego nie wykryje i jak opisać błąd, żeby programista mógł go naprawić

Sprawdzamy, co psuje się najczęściej

Mówicie nam, kto będzie na sali, na czym pracujecie i jakie problemy powtarzają się w zespole. Jeśli macie już audyt, czytamy go przed szkoleniem.

Budujemy program wokół tego

Ćwiczenia dobieramy do problemów, o których nam powiedzieliście. Jeśli kłopot sprawiają tabele danych, całe szkolenie może być o tabelach.

Prowadzimy warsztat

Tłumaczymy, pokazujemy na czytniku ekranu, a potem oddajemy ćwiczenie. Zespół pracuje sam, na swoich komputerach. Zdalnie albo na miejscu.

Materiały zostają w zespole

Slajdy, odnośniki i pliki z ćwiczeniami zostają w zespole, więc kolejna osoba w projekcie przejdzie przez te same przykłady.

Trzy formaty szkolenia z dostępności cyfrowej

Jedna rola, w głąb

Sesja dla programistów, UX albo QA, poświęcona decyzjom, które ta rola podejmuje codziennie.

Cały zespół produktowy

Projektanci, programiści i testerzy w jednej sali. Najpierw wspólne podstawy, potem część dla każdej roli, żeby dostępność przestała ginąć przy przekazywaniu pracy.

Jeden problem, szczegółowo

Pracujecie już nad dostępnością i utknęliście na czymś konkretnym? Szkolenie może dotyczyć właśnie tego: tabel danych, zarządzania fokusem w SPA albo jednego typu komponentu, np. comboboxa.

Audyt mówi, co jest zepsute w tym kwartale. Po szkoleniu kolejne wydanie nie powiększy listy błędów. Jeśli zaczniecie od audytu, oprzemy szkolenie na jego wynikach, a ćwiczenia skupimy na takich błędach, jakie zespół już wypuścił na produkcję.

Co ustalić przed zamówieniem szkolenia z dostępności

Ile trwa szkolenie z dostępności?

Szkolenie z dostępności trwa od czterech godzin do trzech dni, zależnie od ścieżki i od tego, ile w nim ćwiczeń. Gdy na sali są osoby w tej samej roli, wszyscy robią to samo ćwiczenie i w jeden dzień przerabiamy tyle, ile z grupą mieszaną w dwa. Kiedy brakuje czasu, skracamy listę tematów, a ćwiczenia zostają.

Ile kosztuje szkolenie z dostępności?

Cenę szkolenia z dostępności podajemy jako jedną stałą kwotę. Zależy od ścieżki, uczestników i liczby dni, które ustalamy z Wami na początku. Cztery godziny z projektantami i trzy dni z całym zespołem produktowym to dwie osobne wyceny.

Ile osób może wziąć udział w szkoleniu?

Zwykle cały zespół. Każdy musi mieć czas, żeby samodzielnie zrobić ćwiczenia i popracować z czytnikiem ekranu. Dlatego wielkość grupy dobieramy razem z Wami, kiedy planujemy szkolenie.

Czy uczestnicy dostają zaświadczenie?

Tak. Każda osoba, która brała udział w szkoleniu, może dostać zaświadczenie o jego ukończeniu.

Czy to kurs WCAG?

Szkolenie obejmuje WCAG 2.2 AA, a samych wytycznych uczymy na przykładzie decyzji, które zespół podejmuje przy budowaniu produktu. Programista może wiedzieć, że istnieje kryterium 2.4.7, i wciąż nie mieć pojęcia, co zrobić ze wskaźnikiem fokusu. Dlatego najpierw uczymy, jak podjąć decyzję, a potem pokazujemy kryterium, które ją reguluje.

Czy Europejski Akt o Dostępności wymaga szkoleń z dostępności?

Od zespołów produktowych nie. W Europejskim Akcie o Dostępności szkolenia pojawiają się tylko w motywie 20, który nie ma mocy wiążącej. Chodzi w nim o to, żeby pracownicy wiedzieli, jak korzystać z dostępnych produktów i usług. Przepisy rozliczają z efektu: usługa musi spełniać wymagania dostępności. Inaczej jest w sektorze publicznym. Zgodnie z dyrektywą w sprawie dostępności stron internetowych państwa członkowskie mają wspierać szkolenia pracowników instytucji publicznych (art. 7 ust. 4).

Czy szkolenie nadaje się dla początkujących?

Tak. Możemy zacząć od semantycznego HTML-a. Jeśli zespół zna już WCAG, cały dzień poświęcimy na zarządzanie fokusem i live regions. Dajcie znać, która opcja Wam odpowiada, a jeszcze przed szkoleniem dostosujemy poziom.

Szkolicie zdalnie czy stacjonarnie?

Oba warianty wchodzą w grę. Zdalnie dobrze pracuje się z programistami i testerami, bo każdy ćwiczy na komputerze i z czytnikiem ekranu, których używa na co dzień. Stacjonarnie łatwiej poprowadzić warsztat dla grupy mieszanej.

Co dalej po szkoleniu?

Po szkoleniu zostają Wam slajdy, linki do źródeł i pliki z ćwiczeniami. Na pytania, które pojawią się później, odpowiadamy w ramach wsparcia wdrożeniowego na Slacku, w Teamsach albo w Google Chacie. Czy zespół trzyma się nowych nawyków, sprawdzi audyt.

Odkryj swój pełny potencjał

Masz produkt do zbudowania. Nie masz czasu, aby stać się ekspertem WCAG. Pozwól nam zająć się technikaliami, aby Twój zespół mógł wrócić do tego, co robi najlepiej.

Omówmy Twój projekt

Dlaczego te same błędy wracają po każdym wydaniu