Zostawiając awizo…

Kolejną teoretycznie prostą sprawą jest powiadamianie czytników ekranu o zmianach na stronie. Jednak w praktyce jest to o wiele bardziej skomplikowane, niż się wydaje na pierwszy rzut oka.

Powiadamianie o zmianach na stronie

Czasy całkowicie statycznych stron skończyły się eony temu. Obecnie bardzo często zachodzi potrzeba dynamicznej zmiany treści na stronie, np. w aktualizowanej na żywo relacji z meczu czy w odpowiedzi na akcję osoby użytkowniczej. Osoby, które nie korzystają z technologii asystującej, najczęściej są w stanie taką zmianę zauważyć (strona się wizualnie zmienia). Niemniej osobom korzystającym z technologii asystującej (a zwłaszcza czytników ekranu) taka zmiana może umknąć. Wypada więc w jakiś sposób je o niej poinformować.

Jednym ze sposobów są tzw. live regions (żywe regiony, regiony zmieniające się na żywo). Gdy oznaczy się element na stronie przy pomocy atrybutu [aria-live], wszelkie zmiay w jego zawartości będą odczytywane osobie korzystającej z czytnika ekranu. Dodatkowo, przy pomocy wartości tego atrybutu, możemy określić, czy czytanie ma być “uprzejme” (polite), czy “asertywne” (assertive). To pierwsze poczeka, aż osoba skończy wykonywać aktualną czynność (np. czytać akapit tekstu) i dopiero przeczyta komunikat. To drugie przerwie aktualną czynność i komunikat zostanie przeczytany natychmiast. Dodatkowo, przy pomocy atrybutu [aria-atomic] można określić, czy za każdym razem ma być odczytywana cała zawartość elementu z [aria-live], czy tylko jej zmieniona część.

Warto też zauważyć, że istnieją role, które odpowiadają wartościom atrybutu [aria-live]. Elementy z atrybutem [role=status] będą czytane uprzejmie, natomiast elementy z atrybutem [role=alert] – asertywnie.

Niemniej żywe regiony mają jedną, zasadniczą wadę: powiadamiają czytnik ekranu tylko, gdy ich zawartość się zmieni. Nie da się po prostu wstawić elementu z komunikatem na stronę. Trzeba najpierw wstawić pusty element, a dopiero potem dodać do niego treść komunikatu. To sprawia, że całe API zaczyna być mocno upierdliwe w użyciu. Zwykle kończy się na tym, że na stronie istnieje sobie pusty element z atrybutem [aria-live], a wokół niego istnieje całe API, którego zadaniem jest dodawać i usuwać komunikaty. A jeśli robimy większą aplikację, w której komunikatów może być sporo i mogą się pojawiać często, to de facto musimy zrobić cały mechanizm ich kolejkowania. Tak to działa np. w CKEditorze 5. Strasznie dużo roboty jak na coś, co powinno być proste.

Nowy, wygodniejszy sposób

Na całe szczęście, Edge zaproponował jakiś czas temu nowe API, ariaNotify(). To metoda, przypięta do elementów HTML, która pozwala na wysłanie komunikatu do czytnika ekranu:

document.ariaNotify( 'Jakiś komunikat' );

Dzięki drugiemu argumentowi można też określić priorytet komunikatu:

document.ariaNotify( 'Komunikat'. {
	priority: 'normal' // 1
} );

document.ariaNotify( 'Komunikat'. {
	priority: 'high' // 2
} );

Normalny priorytet (1) odpowiada czytaniu uprzejmemu, podczas gdy wysoki (2) – asertywnemu.

Nowe API rozwiązuje też problem kolejkowania komunikatów. Nie trzeba się już dłużej samemu tym zajmować, robi to za nas przeglądarka.

Gdzie jest więc haczyk? To wciąż mocno eksperymentalna technologia, która nawet nie ma specyfikacji. Na ten moment jest tylko propozycja ze strony Edge’a. Samo API na ten moment działa wyłącznie w Chrome i Edge – a i tam ma problemy poza Windowsem. Na razie zatem trzeba dalej męczyć się z żywymi regionami.

Bo dostępność nigdy nie może być za prosta, prawda?