Checklist WCAG dla strony firmowej przed publikacją

Publikacja nowej lub odświeżonej witryny bez weryfikacji dostępności często kończy się poprawkami wykonywanymi już po starcie, kiedy błędy są droższe i bardziej uciążliwe dla użytkowników. Dobrze przygotowana Checklist WCAG dla strony firmowej przed publikacją pomaga sprawdzić nie tylko zgodność techniczną, ale też realną użyteczność serwisu dla osób korzystających z klawiatury, czytnika ekranu, powiększenia treści czy napisów do multimediów. Poniżej znajdziesz praktyczne kryteria, które warto przejść przed uruchomieniem strony, niezależnie od tego, czy odpowiadasz za biznes, treść, UX, UI czy development.

Co naprawdę oznacza gotowość strony do publikacji w standardzie WCAG

W praktyce gotowość do publikacji nie oznacza jedynie tego, że strona „przechodzi skaner”. WCAG to zbiór zasad, które mają sprawić, że treści i funkcje będą postrzegalne, zrozumiałe, operowalne i kompatybilne z różnymi sposobami korzystania z internetu. Dla strony firmowej najczęściej celem jest poziom AA zgodnie z aktualnym podejściem opartym o WCAG 2.2, choć część organizacji wdraża również wybrane wymagania ponad minimum, gdy wynika to z charakteru usługi, grupy odbiorców lub polityki jakości. Checklist WCAG dla strony firmowej przed publikacją powinna więc obejmować nie tylko kod, ale też projekt, treści, multimedia, dokumenty, procesy formularzy i sposób utrzymania serwisu po premierze.

Warto też oddzielić marketingowe hasła od realnej jakości. Sama wtyczka „accessibility”, jednorazowy automatyczny test dostępności strony albo deklaracja zgodności nie tworzą dostępnej strony internetowej. Narzędzia automatyczne pomagają wychwycić część problemów, na przykład brak atrybutu alt, niski kontrast kolorów czy puste etykiety, ale nie ocenią, czy treść linku ma sens, czy kolejność nagłówków wspiera orientację, czy formularz da się zrozumieć bez wzroku albo czy interfejs działa logicznie przy obsłudze klawiaturą. Dlatego przed publikacją potrzebny jest zestaw działań: analiza ekspercka, testy ręczne, przegląd treści i sprawdzenie najważniejszych scenariuszy użytkownika.

Masz pytania? Porozmawiajmy o Twoim marketingu

Skontaktuj się ze mną!

---

Katarzyna Toboła

575 032 600

Wyślij wiadomość

Dlaczego strona firmowa wymaga szerszego sprawdzenia niż landing page

Strona firmowa zwykle łączy kilka warstw ryzyka. Zawiera ofertę, formularze kontaktowe, blog, dokumenty do pobrania, mapy, pliki PDF, materiały wideo, integracje z CRM, narzędzia analityczne i komponenty zewnętrzne. Każdy z tych elementów może obniżyć dostępność cyfrową, nawet jeśli sam szablon wizualny wygląda poprawnie. Użytkownik nie ocenia osobno kodu i treści; dla niego liczy się to, czy potrafi znaleźć usługę, zrozumieć warunki współpracy, wysłać zapytanie i odebrać odpowiedź bez barier.

Z tego powodu sprawdzanie przed publikacją powinno obejmować całą ścieżkę, a nie tylko stronę główną. Jeśli osoba korzystająca z czytnika ekranu bez problemu wejdzie na homepage, ale utknie na formularzu wyceny albo nie odczyta załączonego cennika, organizacja nadal ma problem z dostępnością serwisu. To szczególnie istotne dla e-commerce, usług B2B, podmiotów publicznych i firm objętych obowiązkami wynikającymi z przepisów dotyczących usług cyfrowych, w tym z trendów związanych z Europejskim Aktem o Dostępności i rosnącymi wymaganiami wobec kanałów online.

Jak rozumieć zgodność z WCAG w praktyce biznesowej i projektowej

Zgodność z WCAG nie polega na „odhaczeniu normy” dla samej formalności. To sposób ograniczania ryzyka biznesowego, wizerunkowego i operacyjnego. Serwis, który ma poprawny semantyczny HTML, czytelny kontrast, jasne komunikaty i przewidywalne zachowanie interfejsu, zwykle działa lepiej także dla użytkowników mobilnych, seniorów, osób zmęczonych, klientów w słabym oświetleniu lub pracowników korzystających z laptopa bez myszy. Właśnie tutaj spotykają się UX i dostępność oraz UI i dostępność: dobre wzorce dostępności poprawiają skuteczność strony, skracają czas wykonania zadania i zmniejszają liczbę porzuceń.

W praktyce oznacza to konieczność podejmowania decyzji jeszcze przed publikacją. Jeśli przycisk wygląda jak dekoracja, jeśli ważna informacja jest przekazywana wyłącznie kolorem, jeśli menu rozwijane nie działa z klawiatury albo jeśli popup zasłania treść i blokuje fokus, to problemem nie jest wyłącznie brak formalnej zgodności. Problemem jest źle zaprojektowana interakcja. Dlatego dobra checklista nie kończy się na kodzie. Powinna pytać, czy użytkownik rozumie interfejs, czy odczyta treść bez domysłów i czy zrealizuje cel niezależnie od używanej technologii.

Checklist WCAG dla strony firmowej przed publikacją: treści, struktura i semantyka

Najwięcej błędów ujawnia się tam, gdzie treść spotyka się z kodem. Checklist WCAG dla strony firmowej przed publikacją powinna zaczynać się od pytań o strukturę strony, znaczenie elementów HTML i jakość redakcyjną treści. Nawet atrakcyjny wizualnie serwis może być trudny w użyciu, jeśli ma niespójną strukturę nagłówków, nieprecyzyjne linki, zduplikowane tytuły stron, brak logicznego porządku sekcji lub elementy klikalne zbudowane z przypadkowych znaczników. To obszar, w którym poprawa dostępności strony zwykle daje szybkie efekty i nie wymaga kosztownej przebudowy.

Dobra praktyka polega na tym, aby każdy komponent strony miał jednoznaczną rolę. Nagłówki mają porządkować treść, linki mają prowadzić i informować, przyciski mają wykonywać akcję, a tabele mają prezentować dane, nie służyć do układu graficznego. Użytkownik korzystający z klawiatury lub czytnika ekranu często porusza się po stronie „warstwowo”, przeskakując po nagłówkach, linkach i formularzach. Jeśli kod nie oddaje prawdziwej struktury, interfejs staje się nieczytelny mimo poprawnego wyglądu dla osoby widzącej.

Nagłówki, tytuły i kolejność treści, które ułatwiają orientację

Każda podstrona powinna mieć unikalny i sensowny tytuł oraz jeden główny nagłówek opisujący zawartość. Dalej liczy się logiczna struktura nagłówków, bez przeskakiwania poziomów wyłącznie z powodów wizualnych. Nagłówek nie służy do powiększania fontu, tylko do budowy hierarchii informacji. Dla osób korzystających z technologii asystujących to odpowiednik spisu treści, który pozwala szybko zorientować się w układzie strony.

Przed publikacją warto sprawdzić, czy treść da się zrozumieć po samych nagłówkach i czy ich kolejność odpowiada rzeczywistej logice biznesowej. Częstym błędem jest sytuacja, w której sekcja z formularzem poprzedza opis usługi, a cennik jest ukryty pod ogólnym nagłówkiem „Więcej”. W takim układzie problem dotyczy jednocześnie SEO, użyteczności i dostępności WCAG. Warto też upewnić się, że linki mają sens poza kontekstem, więc zamiast wielu odnośników „czytaj więcej” lepiej stosować opisy wskazujące, dokąd użytkownik przejdzie.

Obrazy, ikony i tekst alternatywny bez automatyzmu i zgadywania

Tekst alternatywny nie jest obowiązkowym dodatkiem do każdego pliku graficznego, tylko opisem celu obrazu z punktu widzenia użytkownika. Jeśli zdjęcie prezentuje produkt, zespół, wykres lub przycisk graficzny, powinno mieć sensowną alternatywę tekstową. Jeśli grafika pełni funkcję czysto dekoracyjną, nie należy zmuszać czytnika ekranu do jej odczytywania. Sam atrybut alt jest więc ważny, ale jeszcze ważniejsza jest decyzja, co dany obraz komunikuje.

Przed publikacją warto przejrzeć wszystkie banery, ikony, grafiki w kafelkach, miniatury wpisów i obrazy osadzone w treści. Typowy błąd to kopiowanie nazw plików, wpisywanie „obrazek”, generowanie automatycznych opisów AI bez weryfikacji lub dublowanie treści podpisu. Jeśli ikona lupy otwiera wyszukiwarkę, a ikona koperty uruchamia formularz kontaktowy, opis powinien przekazywać funkcję, nie wygląd. W tym obszarze pomocne bywa użycie ARIA, ale tylko tam, gdzie natywne HTML nie wystarcza. ARIA nie powinna maskować błędnej struktury, lecz wspierać elementy niestandardowe.

Język, czytelność i kontrast jako warunek zrozumiałej komunikacji

Dostępność treści to nie tylko brak literówek. Równie ważne są prosty język, przewidywalne nazwy sekcji, rozwijanie skrótów przy pierwszym użyciu i unikanie komunikatów, które wymagają specjalistycznej wiedzy wewnętrznej. Strona firmowa często zawiera teksty sprzedażowe, prawne i techniczne, dlatego trzeba zadbać o to, by użytkownik rozumiał, co ma zrobić i jakie będą skutki tej czynności. Im bardziej złożona usługa, tym większe znaczenie mają jasne śródtytuły, podział treści na mniejsze bloki i precyzyjne etykiety działań.

Drugim filarem jest kontrast tekstu i ogólnie kontrast kolorów. Zbyt jasny szary na białym tle, link rozróżniany tylko kolorem albo przycisk z tekstem na gradientowym tle mogą wyglądać estetycznie, ale obniżają czytelność dla osób słabowidzących, starszych i korzystających ze strony w mniej sprzyjających warunkach. Przed publikacją należy sprawdzić nie tylko główne bloki treści, lecz także etykiety formularzy, stany hover, komunikaty błędów, tekst w banerach cookie, napisy w sliderach i każdą informację przekazywaną przez kolor. Dostępność strony internetowej wymaga, aby różnice były czytelne wzrokowo i jednocześnie zrozumiałe bez samego koloru.

Interakcje, formularze i multimedia, które trzeba sprawdzić ręcznie

Najwięcej krytycznych błędów przed publikacją ujawnia analiza scenariuszy użytkownika. Dotyczy to szczególnie menu, popupów, zakładek, akordeonów, wyszukiwarki, koszyka, logowania, zapisów na newsletter i formularzy kontaktowych. Automatyczny skan nie pokaże, czy modal przejmuje fokus prawidłowo, czy da się zamknąć okno bez myszy, czy komunikat pojawia się we właściwym momencie i czy użytkownik wie, co poprawić po błędzie. Dlatego checklista powinna obejmować testy manualne z klawiaturą i w miarę możliwości przynajmniej podstawowe sprawdzenie w czytniku ekranu.

To również obszar, w którym najłatwiej odróżnić powierzchowną zgodność od realnej jakości. Firma może mieć poprawnie opisane obrazy i nadal blokować kontakt, jeśli kluczowy formularz jest nieczytelny albo pole captcha nie ma sensownej alternatywy. Z punktu widzenia użytkownika właśnie te momenty decydują o tym, czy serwis jest dostępny.

Obsługa klawiaturą, fokus i przewidywalność komponentów

Każdy interaktywny element powinien działać przy użyciu samej klawiatury. Oznacza to możliwość przejścia przez menu, linki, przyciski, pola formularza, filtry, zakładki i elementy modali bez konieczności klikania myszą. Widoczny fokus klawiatury jest tu absolutnie kluczowy: użytkownik musi widzieć, gdzie aktualnie się znajduje. Jeśli projekt ukrywa fokus dla estetyki, strona staje się praktycznie nieużywalna dla części odbiorców.

Przed publikacją warto przejść całą stronę klawiszem Tab, Shift+Tab, Enter, Spacja i strzałkami tam, gdzie komponent tego wymaga. Sprawdź, czy kolejność fokusu jest logiczna, czy nie wpada on w pułapki, czy otwarcie menu nie przeskakuje w nieoczekiwane miejsce, czy zamknięcie modalu zwraca użytkownika tam, skąd rozpoczął akcję. Jeśli komponent jest budowany niestandardowo w JavaScript, trzeba zweryfikować, czy jego role, stany i nazwy są prawidłowo komunikowane przez czytnik ekranu. To dobry przykład sytuacji, kiedy odpowiednie użycie technologii asystujących w testach pokazuje problemy niewidoczne gołym okiem.

Formularze firmowe: etykiety, instrukcje i komunikaty błędów

Dostępne formularze to jeden z najważniejszych elementów strony firmowej, bo właśnie tam użytkownik wykonuje działanie biznesowe. Pole powinno mieć jednoznaczną etykietę, a nie tylko placeholder znikający po wpisaniu pierwszej litery. Jeśli formularz wymaga określonego formatu danych, informacja o tym musi pojawić się zawczasu, nie dopiero po wysłaniu. Kolejność pól powinna być logiczna, a grupy powiązanych opcji odpowiednio oznaczone.

Szczególną uwagę trzeba poświęcić temu, jak działają komunikaty błędów. Powinny wskazywać, które pole wymaga poprawy, co dokładnie jest nie tak i jak to naprawić. Komunikat „Błąd formularza” nie wystarcza. Dobrze, gdy status po wysłaniu formularza jest przekazywany także programowo, aby osoba korzystająca z czytnika ekranu od razu usłyszała informację o sukcesie lub problemie. Jeśli stosujesz walidację w czasie rzeczywistym, nie może ona rozpraszać użytkownika ani blokować wpisywania danych. Trzeba też unikać zależności od rozwiązań, które nie mają dostępnej alternatywy, na przykład źle wdrożonych zabezpieczeń wizualnych lub nieczytelnych wyborów daty.

Wideo, audio i osadzone treści zewnętrzne

Jeżeli strona firmowa zawiera filmy promocyjne, webinary, prezentacje produktu lub nagrania wypowiedzi ekspertów, trzeba sprawdzić ich dostępność jeszcze przed publikacją. Minimum to napisy do filmów dla materiałów z dźwiękiem, a w zależności od charakteru treści także transkrypcja lub audiodeskrypcja. Ważne jest również sterowanie odtwarzaczem: użytkownik powinien móc uruchomić, zatrzymać i przewinąć materiał bez pułapek klawiaturowych oraz bez automatycznego odtwarzania dźwięku bez kontroli.

Osobna kwestia to osadzone mapy, iframe’y, zewnętrzne widgety czatu, karuzele opinii i wtyczki społecznościowe. To częste źródła naruszeń dostępności aplikacji i dostępności serwisu, ponieważ organizacja korzysta z gotowego rozwiązania, nad którym nie ma pełnej kontroli. Przed publikacją warto ocenić, czy dany komponent jest naprawdę potrzebny i czy istnieje prostsza alternatywa. Jeśli nie można zapewnić pełnej dostępności zewnętrznego rozwiązania, trzeba przynajmniej przygotować równoważną drogę wykonania zadania, na przykład alternatywny kontakt lub czytelną wersję treści.

Audyt przed startem: jak testować stronę, aby nie opierać się wyłącznie na automacie

Dobrze wykonany audyt WCAG przed publikacją pozwala wykryć błędy wtedy, gdy są jeszcze tanie w naprawie. Najsłabszy możliwy scenariusz to uruchomienie serwisu, zebranie leadów i dopiero potem odkrycie, że użytkownicy nie mogą przejść formularza albo nawigacja mobilna nie jest dostępna z klawiatury. Dlatego testowanie powinno być etapem obowiązkowym, a nie dodatkiem wykonywanym tylko wtedy, gdy „zostanie czas”. Checklist WCAG dla strony firmowej przed publikacją ma sens tylko wtedy, gdy ktoś realnie ją przechodzi i dokumentuje wyniki.

Rzetelny audyt dostępności łączy kilka metod. Jedna osoba z narzędziem online nie zastąpi pełnej oceny. Potrzebne są automatyczne testy do szybkiego wychwycenia części błędów, analiza ekspercka kodu i interfejsu, testy klawiaturą, podstawowa weryfikacja z czytnikiem ekranu oraz przegląd treści, dokumentów i procesów. W organizacjach bardziej dojrzałych dochodzą też testy z udziałem użytkowników i włączenie zasad accessible design do systemu projektowego.

Co wykryje skaner, a czego nie pokaże nawet najlepsze narzędzie

Automatyczny test dostępności strony jest przydatny, ale jego skuteczność ma granice. Narzędzie wykryje część problemów technicznych, takich jak brak etykiet, puste przyciski, niektóre błędy relacji w formularzach czy niezgodności kontrastu. Nie rozpozna jednak, czy tekst linku „sprawdź” ma sens, czy opis alternatywny jest adekwatny, czy instrukcja jest zrozumiała albo czy treść błędu pomaga wykonać kolejną próbę. Nie oceni też jakości doświadczenia użytkownika w złożonym procesie.

Dlatego wyniki skanera trzeba traktować jako fragment obrazu, a nie dowód pełnej zgodności. Jeżeli raport pokazuje zero błędów, nie znaczy to, że osiągnięto pełną dostępność WCAG. Szczególnie ostrożnie należy podchodzić do narzędzi, które obiecują „naprawę dostępności jednym skryptem”. Tego typu rozwiązania mogą maskować część problemów, ale nie naprawiają błędnych decyzji projektowych, słabej semantyki, nieczytelnych treści ani źle zaprojektowanych procesów formularzy.

Jak przeprowadzić przegląd ręczny przed publikacją

Przegląd ręczny najlepiej oprzeć na najważniejszych zadaniach użytkownika. Dla strony firmowej będą to zwykle: znalezienie oferty, odczytanie informacji kontaktowych, pobranie dokumentu, obejrzenie materiału wideo, wysłanie formularza, zapis na newsletter, przejście do polityki prywatności lub cennika. Każdy z tych scenariuszy warto sprawdzić na desktopie i mobile, przy powiększeniu treści, bez używania myszy oraz z aktywnym czytnikiem ekranu w podstawowym zakresie.

Weryfikacja ręczna powinna objąć również stan pusty, stan błędu, stan sukcesu i zachowanie komponetów dynamicznych. Częstym przeoczeniem jest poprawne działanie tylko „idealnej ścieżki”, podczas gdy problemy pojawiają się przy walidacji formularza, filtrowaniu treści, zmianie orientacji ekranu, otwieraniu menu hamburgerowego albo po powiększeniu strony do 200%. Jeśli organizacja przygotowuje deklarację lub publiczne zapewnienia o zgodności, dokumentowanie takich testów jest szczególnie ważne, bo pokazuje rzeczywisty zakres weryfikacji.

Dokumenty, deklaracja dostępności i odpowiedzialność organizacji

Dla wielu firm i instytucji strona internetowa nie kończy się na HTML. Częścią usługi są regulaminy, cenniki, raporty, formularze do pobrania i broszury. Dostępność dokumentów PDF wymaga czegoś więcej niż zapisania pliku z Worda do PDF. Dokument powinien mieć warstwę tekstową, poprawną strukturę tagów, logiczną kolejność odczytu, nagłówki, opisy tabel i odpowiednio oznaczone elementy graficzne. Skan dokumentu jako obraz jest dla wielu użytkowników po prostu nieczytelny.

Jeśli podmiot publikuje deklarację dostępności albo działa w reżimie przepisów publicznych lub sektorowych, trzeba pamiętać, że dokument ten nie zastępuje faktycznych działań. Podobnie obowiązki wynikające z przepisów, takich jak ustawa o dostępności cyfrowej w odpowiednich zastosowaniach czy wymogi rynkowe wzmacniane przez EAA, nie sprowadzają się do umieszczenia jednej podstrony z oświadczeniem. Odpowiedzialność organizacji obejmuje proces projektowania, zakupu rozwiązań, publikacji treści, obsługi zgłoszeń i utrzymania zmian. To informacja ogólna, nie indywidualna porada prawna, ale z perspektywy zarządczej warto traktować dostępność jako element jakości usługi, a nie samo zadanie compliance.

Jak wdrożyć poprawki i utrzymać dostępność po publikacji strony

Nawet bardzo dobra checklista nie będzie miała wartości, jeśli kończy się na pliku z uwagami. Najważniejszy etap zaczyna się wtedy, gdy zidentyfikowane problemy trzeba przypisać do konkretnych osób, ustalić priorytety oraz wprowadzić poprawki w projekcie, treści i kodzie. Wdrożenie WCAG jest procesem ciągłym, bo strona firmowa żyje: pojawiają się nowe aktualności, kampanie, landing pages, formularze, banery i integracje. Bez modelu utrzymania nawet dobrze przygotowany start szybko traci jakość.

W praktyce najlepiej działa podejście oparte na odpowiedzialności rozproszonej, ale jasno opisanej. Projektant dba o wzorce interakcji, kontrast i komponenty. Redaktor odpowiada za nagłówki, linki, język i tekst alternatywny. Programista wdraża semantykę, logikę fokusu i kompatybilność z technologiami asystującymi. Właściciel biznesowy pilnuje, aby terminy i zakres projektu uwzględniały poprawki dostępności, a nie traktowały ich jako opcjonalnego dodatku po launchu.

Priorytetyzacja błędów: co naprawiać najpierw

Nie każdy problem ma tę samą wagę. Najpierw warto usuwać bariery blokujące wykonanie zadania: niedziałające menu, brak dostępnego formularza, pułapki klawiaturowe, nieczytelne komunikaty błędów, krytyczne problemy kontrastu i brak możliwości odczytu podstawowych treści. Dopiero później przechodzi się do kwestii mniej krytycznych, choć nadal ważnych, jak dopracowanie opisów dekoracyjnych grafik czy porządkowanie mniej istotnych sekcji archiwalnych.

Takie podejście pomaga skuteczniej planować budżet i prace wdrożeniowe. Poprawa dostępności strony nie polega na losowym usuwaniu błędów z raportu, lecz na świadomym zmniejszaniu ryzyka dla użytkownika i organizacji. Jeżeli strona ma wejść na produkcję w określonym terminie, warto ustalić, które obszary są warunkiem publikacji, a które mogą zostać dopracowane w krótkim harmonogramie powdrożeniowym wraz z ponowną weryfikacją.

Jak współpracować z UX, UI, redakcją i developmentem

Najwięcej problemów bierze się z tego, że dostępność trafia tylko do jednej roli, zwykle programisty albo specjalisty SEO. Tymczasem projektowanie dostępne zaczyna się od makiet, architektury informacji i decyzji o komponentach. Jeśli designer przygotuje przycisk bez wyraźnego stanu fokusu, redaktor wstawi niejednoznaczne linki, a programista zbuduje niestandardowy dropdown bez natywnych mechanizmów, końcowy problem będzie wspólny. Dobre procesy ograniczają takie sytuacje przez checklisty dla ról, biblioteki komponentów i wspólne kryteria akceptacji.

Warto ustalić proste zasady operacyjne. Każdy nowy komponent powinien być oceniony pod kątem klawiatury i czytnika ekranu. Każda nowa podstrona powinna mieć sprawdzoną strukturę nagłówków i sensowne tytuły. Każdy formularz powinien przejść próbę z błędnymi danymi. Każdy film powinien mieć ustalone wymagania dotyczące napisów. Taki model pracy wspiera zarówno biznes, jak i dostępność aplikacji oraz stron, bo ogranicza konieczność kosztownych napraw po publikacji.

Utrzymanie zgodności przy kolejnych aktualizacjach

Po starcie strony warto zaplanować regularny przegląd zmian. Nowy slider kampanijny, zmiana szablonu wpisów, przeprojektowanie nawigacji, dołożenie chatu AI albo podmiana systemu formularzy mogą naruszyć wcześniej osiągniętą zgodność. Dlatego organizacja potrzebuje prostego procesu kontroli jakości: krótkich testów regresji, okresowych przeglądów eksperckich i jasnych wytycznych dla osób publikujących treści. Bez tego nawet dobrze przeprowadzony standard WCAG na etapie wdrożenia przestaje działać w praktyce operacyjnej.

Coraz większe znaczenie ma też ocena nowych narzędzi opartych o AI i automatyzację marketingową. Chatbot, generator formularzy, personalizacja treści czy automatycznie osadzane komponenty powinny być oceniane nie tylko pod kątem konwersji, ale również tego, czy są kompatybilne z obsługą klawiaturą, odczytem przez czytnik ekranu i zasadami przewidywalnego interfejsu. W 2026 roku odpowiedzialność za dostępność usług cyfrowych będzie jeszcze wyraźniej dotyczyć pełnego ekosystemu kontaktu z klientem, nie tylko statycznej strony www.

Masz pytania? Porozmawiajmy o Twoim marketingu

Skontaktuj się ze mną!

---

Jacek Kałuża

501 728 660

Wyślij wiadomość