Miłego świętowania 🎉!

Postanowiłem, ze nadeszła pora, by zmonetyzować swoją wiedzę. Przez wszystkie te lata dzieliłem się nią za darmo, ale być może w końcu nadszedł czas, by to zmienić.

Zadbałem o to, by reklamy nie były zbyt agresywne. Dzięki temu są dopasowane do treści i nie przeszkadzają za bardzo przy zapoznawaniu się z nią.

Również bloki kodu doczekały się własnych reklam:

const isNumber = (value: unknown): value is number => typeof value === 'number'
const isEven = (value: unknown): boolean => isNumber(value) && value % 2 === 0
const isOdd = (value: unknown): boolean => isNumber(value) && !isEven(value)

Mam nadzieję, że ta mała, nieinwazyjna zmiana się spodoba!

Dzięki za dołączenie online, żeby posłuchać!

Dla osób czytających mojego bloga mam kod rabatowy, dzięki któremu można kupić bilety w pakietach Standard i Exec o 20% taniej. Kod rabatowy to: WID26SP20. Można go użyć w trakcie kupowania biletu na oficjalnej stronie wydarzenia.

Dzięki za wpadnięcie, żeby posłuchać, i dzięki za ciekawe dyskusje w trakcie networkingu!

OLX Masterclass Frontend

3 marca 2026 o godzinie 18:00 rozpocznie się OLX Masterclass Frontend. Można w nim uczestniczyć zarówno fizycznie, w poznańskim biurze OLX, jak i dołączyć online. Wstęp na wydarzenie jest darmowy. Usłyszeć będzie można trzy prelekcje o tematyce webdevowej. Ja opowiadać będę o zmianach, jakie zaszły w nowoczesnym CSS-ie – w tym zagnieżdżaniu, warstwach czy regule @scope – oraz o tym, jak mogą one wpłynąć na to, jak piszemy i zarządzamy stylami. Dla transparentności: za tę prelekcję pobieram wynagrodzenie. Po wszystkim będzie można się napić kawy i pogadać.

Warsaw IT Days 2026

Z kolei 19 marca 2026 (online) i 20 marca 2026 (na PGE Narodowym w Warszawie) odbywa się kolejna edycja Warsaw IT Days. Można posłuchać ponad 300 prelekcji na 25 różnych ścieżkach tematycznych.

Moje wystąpienie, Giving control back to the user, będzie transmitowane online 19 marca 2026 o 14:35. Będę mówił o inkluzywnym designie, a dokładniej – o respektowaniu preferencji osób korzystających z naszej strony WWW. Bilety można kupić na stronie wydarzenia.

Obydwa wystąpienia będą w całości po angielsku. Serdecznie zapraszam!

JSX

Wypada jednak na samym początku wspomnieć, czym w ogóle jest JSX. Za oficjalną dokumentacją:

JSX is an XML-like syntax extension to ECMAScript without any defined semantics. […] It's intended to be used by various preprocessors (transpilers) to transform these tokens into standard ECMAScript.

[JSX to rozszerzenie składni ECMAScript o składnię podobną do XML-a bez definiowania konkretnej semantyki. […] Jest przeznaczone do użytku przez różnego rodzaju preprocesory (transpilery) do transformacji tych tokenów w standardową składnię ECMAScriptu.]

Przekładając to na ludzki – JSX pozwala umieszczać w kodzie JS coś, co wygląda jak kod XML:

const component = <article>
	<h1>Hello, world!</h1>
	<p>Some content</p>
</article>;

Niemniej kod w takiej postaci nie ma być rozumiany przez przeglądarki czy środowiska uruchomieniowe typu Node.js. Taki kod powinien być najpierw przepuszczony przez jakieś narzędzie (transpiler), które przetłumaczy go na zwyczajny kod JS. Praktycznie każdy szanujący się transpiler JS-a ma wsparcie dla JSX-a (np. TypeScript ma wbudowane, a Babel potrzebuje pluginu). Jeśli przepuścimy przez jeden z nich powyższy kod, powinniśmy otrzymać coś takiego:

const component = React.createElement( 'article', null, // 1
	React.createElement( 'h1', null, 'Hello, world!' ), // 2
	React.createElement( 'p', null, 'Some content' ) // 3
);

Każdy z XML-owych elementów w naszym JSX-ie został zamieniony na wywołanie funkcji React.createElement(). Jest też oddana relacja między poszczególnymi elementami – wywołania dla h1 (2) i p (3) znajdują się wewnątrz wywołania dla article (1). Dzięki temu React jest w stanie odtworzyć w swoim vDOM-ie dokładnie takie drzewko, jakie zaprojektowaliśmy w JSX-ie.

Wykorzystanie własnej funkcji

Domyślnie JSX jest zawsze tłumaczony do wywołań funkcji React.createElement(). A co jeśli nie chcemy korzystać z Reacta? Wówczas mamy dwie możliwości podmiany tej funkcji.

Pierwsza z nich, mniej elegancka, to… stworzenie funkcji React.createElement():

const React = {
	createElement() {
		// Tutaj jakiś kod
    }
};

Niemniej istnieje też bardziej elegancka metoda: nadpisanie semantyki JSX-a. Czyli powiedzenie naszemu transpilerowi, jak dokładnie ma transformować kod JSX. Minusem tej metody jest różnica w konfiguracji poszczególnych narzędzi. W przypadku jednak tych najpopularniejszych (TypeScript, Babel, esbuild) można wykorzystać pragmę – czyli komentarz wskazujący odpowiednią funkcję:

/* @jsx myFunction */
const component = <article>
	<h1>Hello, world!</h1>
	<p>Some content</p>
</article>;

W tym przypadku informujemy transpiler, że ma używać funkcji o nazwie myFunction(). Dzięki temu po transpilacji dostaniemy następujący kod:

/* @jsx myFunction */
const component = myFunction( 'article', null,
	myFunction( 'h1', null, 'Hello, world!' ),
	myFunction( 'p', null, 'Some content' )
);

Dzięki temu możemy podstawić naszą implementację React.createElement(), która czekała na ten moment niemalże 9 lat:

Ale wypluwanie elementów HTML z JSX-a jest nudne. Tak naprawdę można generować absolutnie wszystko, co da się zapisać jako drzewko elementów. Jak np. tekstowe drzewko plików:

W tym przypadku funkcja obsługująca JSX wygląda następująco:

function jsx( tag, attributes, ...children ) {
	const { name } = attributes; // 1

	const childrenContent = children.map( ( child ) => {
		return `${ child }`
			.replaceAll( /^/gm, '\n|   ' ) // 3
			.replaceAll( '\n\n', '\n' );
	} ).join( '' ); // 4

	return `| - ${ name }${ childrenContent }`;
}

Z JSX-owego elementu pobieramy atrybut name (1) – to nazwa katalogu lub pliku. Zwracamy ją (2) jako ciąg tekstowy razem z fajką (|), wskazującą aktualny poziom zagłębienia, oraz ciągami tekstowymi zwróconymi przez dzieci. Te nieco modyfikujemy, dodając do każdego pliku/katalogu brakujące fajki (3), a następnie łącząc wszystkie dzieci w jeden duży ciąg tekstowy (4).

Natomiast JSX użyty do tego przykładu wygląda następująco:

/* @jsx jsx */
const component = <directory name="/">
	<file name="README.md" />
	<directory name="src/">
		<file name="index.ts" />
	</directory>
</directory>;

Komponenty

Niemniej w JSX-ie oprócz zwyczajnych elementów istnieją również komponenty, a więc elementy, których nazwy zaczynają się wielką literą. Spójrzmy na taki przykład:

const component = <Greeting name="Comandeer" />;

Jeśli przepuścimy ten kod przez transpiler, otrzymamy mniej więcej coś takiego:

const component = React.createElement( Greeting, { name: 'Comandeer' } );

W tym przypadku do React.createElement() jako pierwszy argument nie jest przekazywana nazwa elementu, ale referencja do Greeting. Wypada zatem stworzyć taką funkcję:

function Greeting( { name } ) { // 1
	return <h1>Hello, {name}!</h1>; // 2
}

Jako parametr przyjmuje ona obiekt z atrybutami (1), z którego wyciągamy atrybut name. Następnie zwracamy element h1, wewnątrz którego wykorzystujemy ten atrybut do stworzenia powitania (2).

Wypada nieco zmodyfikować naszą funkcję do obsługi JSX-a:

function jsx( tag, attributes, ...children ) {
	if ( typeof tag === 'function' ) { // 1
		return tag( { ...attributes, children } ); // 2
	}

	const element = document.createElement( tag );

	if ( attributes && typeof attributes === 'object' ) {
		Object.entries( attributes ).forEach( ( [ name, value ] ) => {
			element.setAttribute( name, value );
		} );
	}

	children.forEach( ( child ) => {
		element.append( child ); // 3
	} );

	return element;
}

Większość logiki została taka sama, pojawił się jedynie dodatkowy warunek na początku. Sprawdza on, czy przekazany tag jest funkcją (1) i jeśli tak, to wywołuje ją, przekazując jako parametr obiekt zawierający atrybuty oraz własność children z dziećmi (2). Robimy to w taki sposób, żeby zachować Reactowy kształt API. Przy okazji, dzięki użyciu metody #append() (3) przy dodawaniu dzieci zniknęła potrzeba tworzenia węzła tekstowego. Metoda #append() bowiem, w przeciwieństwie do starszej metody #appendChild(), pozwala dodawać tekst bezpośrednio do elementu.

Nasza obsługa komponentów prezentuje się następująco:

I tak oto udało nam się przygotować własną, prostą obsługę JSX-a! Oczywiście, nie jest ona skończona, brakuje choćby sensownej obsługi fragmentów. Niemniej jest fajnym punktem wyjścia do dalszych eksperymentów.

Jeśli chodzi o rzeczy, z których jestem dumny: na tym blogu to zdecydowanie tekst Nullius in verba oraz projekt czasomierzy. I tak, zdaję sobie sprawę, że jest ukończony gdzieś w połowie, ale styczeń i luty brzmią jak dobry czas, by go dokończyć. I ruszyć w końcu z kolejnym zapowiedzianym projektem, czyli Doco! Bo nie będę ukrywał, moje projekty w tym roku leżały odłogiem i nie miałem sił do nich zaglądnąć. Ale kalendarz trochę mnie rozruszał. A bardzo mi się to przyda, bo oprócz projektów jest przecież również WebKrytyk, który ostatnio też trochę się zakurzył. W tym roku pojawiły się na nim raptem 4 teksty, z których najbardziej podoba mi się ten o odpowiadających sobie doświadczeniach. Nie można też pominąć faktu, że… WebKrytyk ma już 15 lat. Yay…!

I to w sumie tyle. Szczęśliwego Nowego Roku 🍾!

Podejście naukowe

Co to jednak znaczy, że traktuję webdev naukowo? Tak naprawdę wyróżniłbym tutaj trzy główne elementy:

1. formę treści,
2. obecność źródeł,
3. empiryczność.

Forma treści

Artykuły naukowe mają ściśle określoną strukturę. Bardzo często opisuje się ją akronimem IMRaD:

1. Introduction (wprowadzenie) – wyjaśnienie celu badania, postawienie hipotezy,
2. Methods (metody badawcze) – w jaki sposób badanie zostało wykonane, kto w nim uczestniczył,
3. Results (wyniki) – omówienie wyników badania, sprawdzenie, czy wyniki zgadzają się z postawioną hipotezą,
4. Discussion (polemika) – próba interpretacji wyników, porównanie ich z innymi badaniami z tego zakresu, zaproponowanie możliwych przyszłych kierunków badań.

Tak tworzone artykuły powinny zachowywać jak największą obiektywność, skupiając się przede wszystkim na opisie faktów, z pominięciem opinii osób autorskich.

Ja nie jestem naukowcem i siłą mojego bloga jest jednak to, że umieszczam na nim materiały o webdevie okraszone moją opinią. Więc bardziej nazwałbym swoją radosną twórczość esejami hipertekstowymi. To nic innego jak eseje, które są opublikowane w formie hipertekstu. Czyli: mogą linkować do innych esejów lub bezpośrednio do źródeł, Równocześnie jednak – raz luźniej, raz ściślej – trzymam się struktury IMRaD. Weźmy taki artykuł o Cookie Store API. Na samym początku jest wprowadzenie, w którym zaznaczam problem (relacja Sieci z ciasteczkami od zawsze była skomplikowana). Następnie następuje omówienie wyników badania (w tym wypadku: organoleptycznego sprawdzenia, jak się obsługuje ciasteczka w przeglądarkach). W przypadku artykułów z eksperymentów (jak np. jednoplikowych komponentów czy ASCSS-a) pojawiają się też sekcje z metodami (opis inspiracji i narzędzi użytych do stworzenia danego projektu) oraz polemika (w jaki sposób go dalej rozwijać, czy moje pierwotne założenia udało się spełnić, itd.).

Źródła

Niemniej to nie forma jest głównym wyznacznikiem “naukowości”. Według mnie o wiele ważniejszym jest odwoływanie się do źródeł. W końcu szansa, że opisałem coś jako pierwszy w Internecie, jest niemalże zerowa. Nawet jeśli w swoim zakątku Sieci jestem faktycznie pierwszy, to przecież o jakimś standardzie sieciowym napisała przede mną choćby… osoba pisząca jego specyfikację. Nawet jeśli już wymyślę coś absolutnie swojego (jak Headings First Principle (HFP)), to przecież to nie istnieje w próżni. Żeby mogło powstać HFP, musiał powstać HTML, a w nim nagłówki. Niezbędnymi elementami były też wszelkie dobre praktyki wokół dzielenia treści stron WWW na sekcje oraz sposób nawigowania przy pomocy nagłówków przez osoby korzystające z czytników ekranowych. Słowem: musiał istnieć cały skomplikowany ekosystem Sieci, żebym ja mógł do niego dodać swoją małą cegiełkę.

Chyba najdobitniej widać to w przypadku mojego, jak dotąd najambitniejszego, projektu, GWD. W każdym “rozdziale” na końcu znajdują się listy źródeł oraz dodatkowych materiałów. Nazbierało się ich około tysiąca. A i tak była to mocno okrojona lista. Zwłaszcza, że sporo tematów ostatecznie wypadło z tego eseju.

Niemniej samo odesłanie do źródeł to za mało. Prawdziwa praca polega na odpowiednim ich dobraniu. Bo można opisać np. element HTML bdo i odesłać do jakiejś strony-krzak czy popularnej, acz słabej jakości witryny. Zamiast tego wypada jednak dokładnie zapoznać się, do czego linkujemy, czy nie ma tam błędów merytorycznych, czy poruszone są wszystkie kwestie ważne poruszenia, itd. I tak jak w świecie nauki, w którym mamy tytuły godne zaufania (Science, Nature), tak i w webdevie jedne źródła są bezpieczniejsze od innych. Najbezpieczniejsze są, rzecz jasna, specyfikacje i standardy. Nie ma pewniejszych źródeł od nich. Jeśli chcę opisać element bdo, to specyfikacja HTML jest Kanonicznym Źródłem Prawdy™. Ale standardy często są pisane w sposób całkowicie hermetyczny i niezrozumiały dla dowolnej osoby, która nie czyta sobie RFC do poduszki. Wtedy warto sięgnąć po drugie najlepsze źródło – dokumentację MDN. Jeśli coś można by nazwać oficjalną dokumentacją platformy sieciowej, to byłoby to właśnie MDN.

Dobrej jakości źródeł jest oczywiście więcej – jak choćby Smashing Magazine, A List Apart czy blogi znanych osób ze światka webdevu. I często na tych stronach, oderwanych od “oficjalnego obiegu”, dzieją się rzeczy ciekawsze. To w końcu na łamach A List Apart powstał termin Responsive Web Design! Często też wyłuskać można na jakiejś stronie jakąś perełkę wśród całej reszty meh artykułów (hej, to zupełnie jak na moim blogu!). Tylko no właśnie – wyłuskać…

Sprawne posługiwanie się źródłami wymaga mimo wszystko wprawy i pewnego doświadczenia. Ja w swoim życiu przerobiłem już tysiące artykułów o webdevie i jestem w stanie oddzielić te faktycznie ciekawe od tych, które takie nie są. I właśnie tę umiejętność selekcji uważam za kluczową w bardziej naukowym podejściu do webdevu. Żeby ją zdobyć, to nie ma innej rady – trzeba spędzić swoje na czytaniu. Na początku będzie się czytać wszystko, jak leci, by z czasem odrzucać te najgorsze z najgorszych, aż w końcu nadejdzie moment, w którym się Po Prostu Wie™, co jest warte poświęcenia czasu, a co nie.

Niemniej z selekcją źródeł jest jeszcze jeden mały haczyk: ryzyko wpadnięcia w bańkę. Każda osoba ma jakieś poglądy i przekonania. Choćby tak błahe, jak nielubienie Reacta czy skłonność do wybierania mniej popularnych rozwiązań. I takie przekonania będą – bardziej lub mniej świadomie – wpływać na to, które źródła się dobiera. Nie sądzę, by dało się od tego całkowicie uciec, ale im bardziej się jest tego świadomym, tym mniejszy ma to wpływ na proces selekcji. Bo czasami warto wręcz sięgać po źródła, z którymi się nie zgadzamy – choćby po to, by wejść z nimi w polemikę.

Empiryczność

Wreszcie ostatni element, który widać w większości moich artykułów – zarówno tutaj, jak i na WebKrytyku. Empiryczność, czyli mówiąc inaczej: eksperymentowanie. Kiedy opisuję nowe API, fajnie byłoby, gdybym przygotował choćby krótkie demko, w którym bym zademonstrował jego podstawowe ficzery. Tym prostym sposobem można być jak Longinus Podbipięta i ściąć trzy gł odhaczyć trzy rzeczy:

1. pokazujemy osobom czytającym, że opisywane przez nas rzeczy faktycznie istnieją i działają,
2. tworzymy dla siebie samych z przyszłości źródło do linkowania, jeśli kiedyś wspomnimy znowu o tym API,
3. zapamiętujemy całą rzecz lepiej, niż gdybyśmy naskrobali jedynie teoretyczny opis.

Poza tym – ostatecznie piszę ten blog dla przyjemności. A gdzie byłby cały fun z tego, gdybym się nie bawił kodem?

Tylko po co?

Odpowiedziałem już na pytanie, jak traktować webdev bardziej naukowo. Pora zatem pochylić się nad drugim, równie ważnym – jeśli nawet nie ważniejszym – pytaniem: po co?

Bo uważam, że tego wymaga uczciwość intelektualna. Webdev nie jest jakąś bliżej niezdefiniowaną sztuką okultystyczną (mimo że czasami tak się jawi!). Wbrew pozorom zdecydowana większość platformy sieciowej jest oparta na konkretnych standardach i specyfikacjach. Bo gdyby nie była, strony WWW działałyby w jednych przeglądarkach i nie działały w innych. Te czasy już przerabialiśmy i to właśnie dzięki nim dzisiaj mamy otwarte standardy sieciowe. Jasne, nie jest idealnie, ale inicjatywy takie jak Web Platform Tests czy Interop dają nadzieję, ze będzie lepiej. A skoro Sieć oparta jest na fundamentach, które są skodyfikowane (spisane “na papierze”, z przybitą pieczątką) i możliwe do empirycznej weryfikacji (w każdej chwili mogę odpalić przeglądarkę i sprawdzić, jak ten HTML czy CSS działają), to nie widzę powodu, by moje artykuły się do tego nie odwoływały.

Uczciwość intelektualna wymaga też, by istniała pewna ciągłość między tym, co tworzymy, a tym, co zostało stworzone. Tak jak artykuł naukowy nie może istnieć bez źródeł, tak trudno stworzyć artykuł o hipertekście bez… hipertekstu. W webdevie nie ma self-made men, wszyscy budujemy na fundamentach postawionych przez innych. Nawet jeśli nasze budowanie polega na niezgadzaniu się z już istniejącymi dobrymi praktykami i proponowaniu czegoś nowego. Bo ostatecznie nie byłoby tej propozycji, gdyby nie ta praktyka! Żeby się z czymś nie zgadzać, trzeba najpierw zauważyć istnienie tego czegoś. Inaczej nasza krytyka będzie całkowicie jałowa.

Wreszcie: webdev najzwyczajniej w świecie zasługuje na bardziej naukowe – czy też po prostu merytoryczne – traktowanie. Choćby dlatego, że Sieć stanowi coraz większą część naszego codziennego życia. To wszechobecna technologia, do której dostęp ma ok. 6 miliardów ludzi. W innych dziedzinach nauki i technologii, które często dotykają mniejszej liczby osób (jak np. projekt nowego skafandra astronautycznego), zachowujemy niezwykłą precyzję i naukową rygorystyczność. Natomiast w dziedzinie, która w taki czy inny sposób zahacza o jakieś ¾ światowej populacji, mam wrażenie, że często wychodzimy z założenia, że to tylko technologia. A to przecież nieprawda. Ludzie mają różne powody, by korzystać z Internetu. Jeśli – jako osoby tworzące strony WWW – nie traktujemy Sieci wystarczająco poważnie, ostatecznie szkodzimy osobom, które z tych stron WWW następnie korzystają. I myślę, że przestawienie myślenia z to tylko technologia w kierunku webdev to nauka jest mało bolesnym sposobem na stworzenie lepszej Sieci.

I tym optymistycznym akcentem życzę Wszystkim wesołych świąt 🎄🎄🎄!

Technologia asystująca

Czym jednak jest technologia asystująca? Za definicją proponowaną przez WHO:

Assistive products help maintain or improve an individual’s functioning related to cognition, communication, hearing, mobility, self-care and vision, thus enabling their health, well-being, inclusion and participation.

[Produkty asystujące pomagają w utrzymaniu lub poprawie funkcjonowania osoby w zakresie funkcji poznawczych, komunikacji, słuchu, mobilności, samoopieki oraz wzroku, pozwalając tej osobie być zdrową fizycznie i psychicznie, włączoną w życie społeczne oraz uczestniczącą w nim.]

Ta definicja jest niezwykle szeroka i obejmuje tak naprawdę wszystkie sprzęty oraz oprogramowanie, które pomagają w codziennym funkcjonowaniu. Stąd można do niej zaliczyć np. wózek inwalidzki, czytniki ekranu, ale też choćby lupę. Swego czasu opisałem trochę przykładów takich technologii.

Systemowa technologia asystująca

Systemy operacyjne dostarczają osobom z nich korzystających wbudowanych technologii asystujących. Lista takich technologii będzie się różnić w zależności od systemu. Weźmy jako przykład macOS-a. Chyba najbardziej znaną technologią asystującą dostępną wraz z tym systemem jest czytnik ekranowy VoiceOver. Nie jest bynajmniej jedyną. Ustawienia systemu posiadają mocno rozbudowaną sekcję poświęconą dostępności:

Jak widać, macOS dzieli te ustawienia na poszczególne zmysły, które dane opcje mają wspierać. Stąd w kategorii wzroku mamy m.in. czytnik ekranu (VoiceOver), ale też ustawienia wyświetlacza czy animacji ruchowych, w słuchu – ustawienia dźwięku itd. Każda z tych opcji w menu posiada konkretne ustawienia, np. odnośnie animacji ruchowych:

System od Apple pozwala na dostosowanie większości aspektów systemu, np. wyłączając autoodtwarzanie ruchomych obrazków (GIF-ów). I choć na początku ogrom opcji może przytłaczać, to sam fakt ich istnienia jest jak najbardziej pozytywny. W końcu jedne z najbardziej dostępnych rozwiązań to te, które można najbardziej dostosować pod siebie!

Windows również posiada dość rozbudowane opcje dostępności. Podobnie jak macOS udostępnia czytnik ekranowy, Narratora. W przypadku jednak tego systemu nie zdobył on nigdy większej popularności. Od lat na tej platformie królują JAWS (płatny) oraz NVDA (darmowy). Oprócz czytnika Windows oferuje choćby lupę ekranową (do powiększania fragmentów ekranu) czy tryb wysokiego kontrastu.

Systemy mobilne także dostarczają technologii asystujących. Zarówno Android, jak i iOS, mają wbudowane czytniki ekranowe – odpowiednio TalkBack i VoiceOver. Mają także choćby opcję ograniczania animacji ruchowych. Także sporo linuksowych dystrybucji ma ustawienia dostępności, np. LInux Mint pozwala włączyć tryb wysokiego kontrastu i ma wbudowany czytnik ekranu (Orcę).

Innymi słowy: systemy operacyjne próbują dostarczyć niezbędnych narzędzi do tego, by mogło z nich korzystać jak najwięcej osób, w tym osoby z niepełnosprawnościami.

System a przeglądarka

Jak zatem taka systemowa technologia asystująca przekłada się na przeglądarkę? To zależy. Wraz z rozwojem technologii sieciowych, osoby tworzące strony WWW dostały możliwość dowiedzenia się nieco więcej o systemie operacyjnym, na którym uruchomiona jest przeglądarka. Najczęściej dzięki nowym media queries w CSS-ie. Wśród nich wymienić można:

• prefers-reduced-motion – informujące o ustawieniach dotyczących ograniczenia animacji ruchowych,
• forced-colors – informujące o trybie wymuszonych kolorów, czyli ograniczeniu palety dostępnych kolorów, jak w przypadku Windowsowego trybu wysokiego kontrastu,
• prefers-color-scheme – informujące o preferencjach osoby użytkowniczej co do doboru schematu kolorystycznego; inaczej mówiąc: czy woli jasny, czy ciemny motyw.

Część z systemowych ułatwień dostępu może być jednak “zakamuflowana”. Dobrym przykładem są tu różnego rodzaju powiększenia. Działają one trochę jak zmniejszenie rozdzielczości: poszczególne elementy robią się większe, przez co są bardziej czytelne. Równocześnie jednak ogranicza to liczbę elementów widocznych w danej chwili na ekranie. Przeglądarka często interpretuje to jako mniejszy viewport. Co też dobrze pokazuje, jak zawodne jest opieranie responsywności na założeniu mały ekran = urządzenie mobilne.

Jeszcze inne technologie asystujące są całkowicie przezroczyste dla przeglądarki, jak np. czytniki ekranu. Nie ma żadnego sposobu, aby dowiedzieć się, że osoba odwiedzająca stronę używa czytnika ekranu. I to akurat dobrze. Zwłaszcza, że stworzenie strony z zachowaniem standardów sieciowych i dobrych praktyk dostępności jest w większości przypadków wystarczające, by strona ta działała poprawnie we wszystkich popularnych czytnikach ekranu. Innymi słowy: wystarczy dobrze wykonywać swoją pracę – jakkolwiek brutalnie by to nie brzmiało.

Podsumowując: przeglądarka i system to para zaufanych przyjaciół, która niektóre sekrety zostawia wyłącznie dla siebie. Ale to, czym się jednak z nami dzielą, powinno wystarczyć do stworzenia dostępnej, przyjaznej strony WWW.