Marek Wojciechowski, Piotr Kaleta. Politechnika Poznańska

Transkrypt

1 Interfejs użytkownika w aplikacjach webowych: co, gdzie, jak i dlaczego? Marek Wojciechowski, Piotr Kaleta Politechnika Poznańska Marek.Wojciechowski@cs.put.poznan.pl

2 Plan prezentacji Motywacje Źródła informacji Witryny internetowe a korporacyjne aplikacje z interfejsem webowym Rekomendacje i wskazówki Ocena przykładowych interfejsów

3 Motywacje Biegła znajomość technologii internetowych i języków programowania nie wystarcza do tworzenia witryn i aplikacji, które są: intuicyjne w obsłudze przyjazne użytkownikowi Pole do popisu dla konsultantów zajmujących się: architekturą informacji (ang. information architecture) użytecznością (ang. usability) Dostępność literatury dotyczącej powyższych dziedzin niektóre pozycje wręcz uznane za kultowe ukierunkowanie na ogólnodostępne serwisy internetowe Pytanie: Czy wiedza ta jest niezbędna i jednocześnie wystarczająca by tworzyć udane aplikacje korporacyjne?

4 Przegląd literatury Literatura: M. Kasperski, A. Boguska-Torbicz, Projektowanie stron WWW. Użyteczność w praktyce, 2008 P. Morville, L. Rosenfeld, Information Architecture for the World Wide Web, Third Edition, 2006 L. Wroblewski, Web form design: filling in the blanks, 2008 S. Krug, Don't Make Me Think! A Common Sense Approach to Web Usability, Second Edition, 2006 C. Jarrett, G. Gaffney, Forms that Work, 2008 J. Nielsen, Designing Web Usability, 1999 J. Nielsen, K. Pernice, Eyetracking Web Usability, 2099 i wiele innych... Standardy: Web Content Accessibility Guidelines (WCAG) 2.0

5 Serwisy internetowe a aplikacje korporacyjne z interfejsem webowym Być może te same technologie, ale czy te same problemy od strony projektowania interfejsu użytkownika?

6 Specyfika serwisów internetowych Użytkownicy okazjonalni: nie muszą korzystać akurat z naszego serwisu niewyszkolenie łatwo zniechęcający się niezainteresowani dogłębnym poznaniem serwisu być może nie do końca ufający serwisowi, któremu muszą udzielić o sobie informacji Konsekwencje dla twórców serwisów: wsparcie użytkowników odwiedzających serwis po raz pierwszy budowanie zaufania między użytkownikiem a serwisem przejrzystość i intuicyjność interfejsu ponad wszystko

7 Specyfika aplikacji korporacyjnych Użytkownicy przeszkoleni: mogą zostać zapoznani ze szczegółami dotyczącymi systemu wykonujący powtarzalne czynności absolutnie zorientowani na wydajność pracy Przetwarzanie dużych wolumenów danych: rozbudowane formularze dane tabelaryczne Konsekwencje dla twórców serwisów: wsparcie użytkowników wyszkolonych ważniejsze niż początkujących (skróty klawiaturowe, obsługa nawigacji klawiaturą, szybki dostęp do najczęściej używanych funkcji) kłopotliwe zarządzanie miejscem na stronie konieczność rozwiązywania problemów, na temat których literatura ogólnego przeznaczenia milczy

8 Gdzie szukać pomocy, rozwiązań, wskazówek? Mimo wszystko literatura, ze względu na wiele problemów wspólnych dla witryn i aplikacji typografia, kolory nawigacja dobór elementów formularzy informacje o błędach "Standardy przymysłowe" zestawy wskazówek i wytycznych tworzone przez korporacje na potrzeby aplikacji tworzonych przez siebie lub partnerów wiele z nich jest dostępnych w Internecie

9 Standardy przemysłowe dla aplikacji korporacyjnych Przykłady dostępne w Internecie: UI Guidelines for CRM WebClient User Interface (SAP) Oracle Browser Look and Feel (BLAF) Guidelines (Oracle) Seagate Web Style Guide(Seagate) Windows User Experience Interaction Guidelines (Microsoft) Web Content Accessibility Guidelines (WCAG) 2.0 (W3C) Mogą stanowić inspirację przy pracach nad własnymi specyfikacjami dla nowo tworzonych aplikacji zakres wskazówek i rekomendacji (uwzględnione zagadnienia) przykładowe konkretne rozwiązania

10 Uwagi ogólne układ strony paski przewijania kolorystyka interfejsu kształty komponentów typografia ikony język Nawigacja regiony nawigacji rodzaje menu Dane tabelaryczne Typowy zakres wskazówek i wytycznych (1/2)

11 Formularze Typowy zakres wskazówek i wytycznych (2/2) układ formularza etykiety zastosowanie i pozycjonowanie poszczególnych typów elementów walidacja Interakcja z użytkownikiem komunikaty sygnalizacja przetwarzania wyszukiwanie okna dialogowe kreatory skróty klawiaturowe Dostępność dla osób niepełnosprawnych

12 Uwagi ogólne

13 Układ strony Typowy podział na 3 regiony nagłówek (u góry): linki systemowe (np. Wyloguj ), wyszukiwarka pasek nawigacyjny (po lewej): menu pierwszego i drugiego poziomu, opcjonalnie zwijane/rozwijane obszar roboczy (reszta ekranu), posiadający własny specyficzny pasek narzędziowy Wszystkie strony aplikacji oparte o ten sam podstawowy szablon ewentualnie modyfikacje szablonu dla zidentyfikowanych różnych typów stron aplikacji Długie strony należy podzielić na sekcje

14 Paski przewijania Pionowe paski przewijania dopuszczalne, gdy zawartość nie mieści się w obszarze roboczym Poziome paski przewijania w zasadzie zabronione wyjątek: galerie obrazów co z tabelami?

15 Kolorystyka interfejsu (1/2) Kolory z grupy 216 kolorów "web-safe"? Już nieistotne! Kolory powinny wywoływać skojarzenia z dziedziną tematyczną nie zawsze oczywiste, można wzorować się na konkurencji Przykład: Oracle BLAF niebiesko-biała paleta z elementami beżu (w stosunku do wcześniejszych wersji zastąpienie szarości bielą) wg Oracle: czysty, profesjonalny, biznesowy wygląd, kojarzony z zaufaniem, bezpieczeństwem, czystością, precyzją, konserwatyzmem, technologią, komfortem i ciepłem Uwaga: W JDeveloper 11g nowa skórka o nazwie Fusion, jeszcze nie uwzględniona w dokumentach na temat BLAF!

16 Kolorystyka interfejsu (2/2) Paleta podzielona na 4 grupy kolorów Podstawowe w BLAF: odcienie niebieskiego ogólnie: kolory najsilniejsze i najbardziej nasycone, wykorzystywane do kluczowych elementów interfejsu, np. paska z zakładkami Akcenty w BLAF: odcienie beżu ogólnie: kolory neutralne, komplementujące podstawowe, używane np. jako tło tabeli i kolor przycisków Silne akcenty w BLAF: odcienie szarości ogólnie: dodają głębi palecie, używane w BLAF tylko do nadania 3-wymiarowego cieniowania niektórych elementów Pozostałe (w BLAF: biel dla tła, odcienie brązu i pomarańcz dla linków, czerwony dla błędów)

17 Kształty komponentów BLAF: kombinacja prostokątnych i zaokrąglonych elementów zaokrąglone kojarzone z połączeniem, społecznością, komfortem prostokątne z porządkiem, logiką i bezpieczeństwem

18 Typografia (1/2) Preferowane czcionki bezszeryfowe ze względu na lepszą czytelność na ekranie (rozdzielczość obrazu mniejsza niż druku) Jeśli szeryfowa, to Georgia ma opinię najlepiej czytelnej na ekranie (do 10 pkt) Najpopularniejsza bezszeryfowa w Internecie to Verdana Czytelność nawet przy 8-10 pkt Szeryfowe duże I Alternatywa dla Verdany: Tahoma Lucida I to jest ta czytelność! Arial (węższy więcej się mieści tekstu, ale gorzej z czytelnością)

19 Typografia (2/2) Kolor tekstu i tła najważniejsze by był kontrast tzw. kontrast odwrócony znacznie gorszy (np. biały tekst na czarnym tle do 40% mniej czytelny niż czarny na białym) Rozmiar czcionki najlepiej podawać w punktach problem z pikselami w IE, a planowane jako przenaszalne small, medium itd. w praktyce różnie zachowują się w różnych przeglądarkach Wyróżnienia w tekście przez wytłuszczenie nigdy przez podkreślenie, bo to kojarzy się z linkami nie przez kapitaliki, bo utrudniają rozpoznawanie kształtów słów Przy prezentacji liczb, duże liczby zapisywać porcjami po 3 cyfry Wyrównanie tekstu: do lewej lepsze niż justowanie, szczególnie w wypadku wąskiej kolumny tekstu duże i nierówne między wierszami odstępy między literami KAPITALIK

20 Ikony Generalnie stosować oszczędnie Jeśli ikony zamiast etykiet słownych, to raczej tylko w ramach systemu nawigacji Ikony mogą pełnić funkcję wygodnych skrótów dla doświadczonych użytkowników, ale dla początkujących ich znaczenie może nie być oczywiste

21 Język Zrozumiały dla użytkownika, ale nie żargon Spójne gramatycznie i stylowo formy w całej aplikacji Proszę tylko gdy akcja wiąże się z uciążliwością dla użytkownika

22 Nawigacja

23 Regiony nawigacji Prezentacja informacji gdzie w ramach aplikacji użytkownik się znajduje (ścieżki powrotu ang. bread crumbs itp.) Regiony nawigacji globalnej, lokalnej i kontekstowej Produkty > Gry > Planszowe praktykowane jest również integrowanie nawigacji globalnej i lokalnej poprzez menu rozwijane Pomysł wart rozważenia: wyróżnienie strony domowej jako punktu startowego do pracy każdego użytkownika dostęp do najczęściej używanych narzędzi, linki, ewentualnie raporty

24 Nawigacja a niezatwierdzone zmiany Wykrywanie sytuacji gdy użytkownik opuszcza stronę, na której dokonano niezatwierdzonych zmian W takiej sytuacji powinno być wyświetlane okno dialogowe z możliwością wyboru z trzech opcji: kontynuacja z zapisem zmian kontynuacja z anulowaniem zmian anulowanie nawigacji

25 Rodzaje menu (1/2) Menu poziome Zajmuje mało miejsca (+) Łatwo zauważalne przez użytkowników (+) Ograniczona liczba pozycji (max 8-10) (-) Nazwy linków muszą być krótkie (-) Menu poziome z podmenu w zakładkach Ma zalety menu poziomego (+) Czytelny związek między pozycjami menu i podmenu (+) Ma wady menu poziomego (-) Stosowane tylko dla 2 poziomów menu (-) Zabiera miejsce w pionie (-) Zakładki jako elementy graficzne zajmują więcej miejsca niż zwykłe linki (-)

26 Rodzaje menu (2/2) Boczne menu pionowe Mieści dużo opcji i łatwo się skaluje (+) Zajmuje dużo miejsca (-) Menu kaskadowe Oszczędza miejsce (+) Odpowiada doświadczeniom z aplikacji desktopowych (+) Pojemne (+) Opcje podmenu niewidoczne zanim nie zostaną rozwinięte (-) Nie wskazuje miejsca, w którym użytkownik jest w aplikacji (-) Rozwijane w bok nielubiane przez użytkowników (-)

27 Dane tabelaryczne

28 Tryby pracy tabel Dwa tryby pracy: tryb wyświetlania danych tryb modyfikacji danych Te same kolumny w trybie wyświetlania i edycji w trybie edycji dodatkowo selektor wiersza Dodatkowy toolbar w trybie edycji dodatkowy toolbar zawiera opcje do działania na pojedynczych wierszach opcje dotyczące całej tabeli są w podstawowym toolbarze, który jest widoczny w obu trybach

29 Uwagi ogólne o tabelach Należy minimalizować liczbę wyświetlanych kolumn Również w tabelach należy unikać poziomych pasków przewijania są wyniki badań nad usability, że poziome paski utrudniają korzystanie z aplikacji niestety nie zawsze możliwe ich uniknięcie Konieczny nagłówek tabeli m.in. ze względu na accessibility Kolumny najważniejsze dla użytkownika z lewej strony Banding (przeplatane kolory wierszy) i/lub gridding (siatka) poprawiają czytelność dla małych i wąskich tabel wystarczy siatka pionowe linie siatki nie zawsze niezbędne np. tylko w trybie edycji

30 Nawigacja i akcje w tabeli Pasek przycisków dla tabeli musi zawierać więcej niż jeden przycisk, chyba że tabela pozwala na wielokrotny wybór Należy unikać redundancji funkcjonalności przycisków w pasku i ikon z komórek tabeli Selekcja wierszy powinna być zablokowana tylko gdy wszystkie akcje z paska przycisków są niedostępne dla użytkownika Jeśli tabela zawiera kolumnę akcji z ikonami wywołującymi poszczególne akcje dla danego wiersza, to taka kolumna jest pierwszą w tabeli

31 Tryby selekcji wierszy tabeli no-select single-select multiple-select dla ułatwienia przyciski SelectAll, DeselectAll wielokrotny wybór tylko gdy naprawdę niezbędny, gdyż może prowadzić do błędów

32 Formularze

33 Układ formularza Np. układ formularza wpasowany w logiczny grid: układ jedno- lub dwukolumnowy (kolejność elementów wg kolumn) Rozmiar pól: 2 szkoły wiersze z polami w kolumnie formularza równej długości rozmiar pól dostosowany do typowej ich zawartości Pola z liczbami muszą mieć długość taką aby liczba zawsze w całości była widoczna!

34 Tryby pracy formularza 2 tryby pracy: edycji i wyświetlania W trybie edycji pola nieedytowalne wyświetlane jako pola read-only Kalendarze, listy itp. wspomagające wprowadzanie danych do pól tekstowych wyświetlane tylko w trybie edycji Obowiązkowość pól wskazywana tylko w trybie edycji, gwiazdką przy etykiecie i opcjonalnie dodatkowo innym kolorem tła pola Jeśli pole do edycji zawiera link, to link jest tylko w trybie wyświetlania, a w trybie edycji tylko dla pól niemodyfikowalnych Wyrównanie zawartości pól: w trybie wyświetlania wszystkie do lewej, a w trybie edycji liczby do prawej a pozostałe do lewej W trybie wyświetlania dopuszczalna jest konkatenacja pól, ale należy starać się zachować ten sam układ w trybie wyświetlania i edycji

35 Grupowanie elementów formularza Elementy formularza mogą być grupowane Grupa posiada swoją etykietę Grupa zajmuje nie więcej niż 8 linii formularza Grupa zawiera więcej niż 1 element jeśli jednak jeden to bez własnej etykiety, tylko etykieta grupy Grupy w układzie 2-kolumnowym wyrównane horyzontalnie chyba że wyrównanie wymagałoby dodania więcej niż 2 pustych wierszy do którejś z grup Podział na grupy musi być spójny z kolejnością nawigacji tabulatorem

36 Elementy zagnieżdżone Elementy zagnieżdżone uzupełniające dane z innego pola Zagnieżdżone elementy powinny być bliżej elementu, któremu podlegają, nawet jeśli zmniejszy to ustalone w formularzu marginesy między kolejnymi polami Elementy zagnieżdżone dla pola wyboru powinny być nieaktywne gdy pole wyboru nie jest zaznaczone Gdy elementy zagnieżdżone występują dla przycisków radiowych z grupy, można rozważyć listę rozwijaną, wybór z której będzie zmieniał zestaw pól uzupełniających

37 Etykiety Jednoznaczne, niezaskakujące, spójne z doświadczeniem użytkowników (np. Pomoc, Kontakt ) Raczej bez skrótów można wykorzystać podpowiedź w dymku, gdy etykieta się nie mieści Spójne w obrębie aplikacji z uwzględnieniem takich aspektów jak: wielkość liter, własności wizualne (krój czcionki, rozmiar, kolor, itd.), forma gramatyczna (czasownikowa, rzeczownikowa, pytająca)

38 Położenie i wyrównanie etykiet Ponad polem badania wykazały że użytkownicy w tym wypadku tracą około 50% czasu mniej na analizę formularza; minusem jest zwiększenie rozmiaru formularza Etykiety pól po lewej wyrównane do prawej: optymalizacja zajętości miejsca, trudne skanowanie etykiet wzrokiem wyrównanie do lewej: łatwiejsze skanowanie etykiet wzrokiem, kluczowe gdy użytkownik niezaznajomiony z formularzem Wewnątrz pola największa oszczędność miejsca; muszą pojawiać się ponownie po wykasowaniu zawartości pola możliwy jest też wariant że etykieta wewnątrz tylko dla list rozwijanych i wieloliniowych pól tekstowych

39 Pola wyboru Mogą mieć dwie etykiety : label (normalnie po lewej jak inne pola) i checkbox text (po prawej) Etykiety po lewej nie ma gdy chechbox stanowi uzupełnienie informacji z innego pola Gdy grupa pól wyboru, to etykietę po lewej ma pierwszy z nich i odnosi się ona do całej grupy Zawsze wyrównane do lewej krawędzi pozostałych pól w kolumnie niezależnie od tego czy mają etykietę czy nie

40 Przyciski radiowe (grupy) Zawsze w grupach, ułożone raczej w pionie, wyrównanie jak pola wyboru pod innym polem bez etykiety z lewej, gdy uzupełniają informację z innego pola Etykieta dla grupy jak przy polach wyboru gdy grupa przycisków radiowych stanowi samodzielną opcję formularza ponadto gdy grupa samodzielna, to odstępy między nią, a sąsiadującymi polami Typowo 2-5 przycisków w grupie, gdy potrzeba więcej raczej używamy listy

41 Radio buttons czy checkbox group? Gdy znaczenie niezaznaczonego checkboxa nie jest oczywiste, to radio buttons (np. portrait/landscape) Gdy wybór 0, 1 lub więcej opcji, to grupa checkboxów i błąd gdy żaden nie zostanie zaznaczony

42 Listy rozwijane Pozycje sortowane alfabetycznie, chyba że logika biznesowa narzuca inny porządek (np. kolejne stany procesu) LOV (list of values) gdy zbyt dużo opcji na dropdown list LOV wywoływane przyciskiem lub ikoną, ewentualnie automatycznie wskutek walidacji polatekstowego listą wartości LOV wyświetlane w modalnych oknach dialogowych z możliwością zmiany rozmiaru przez użytkownika

43 Przyciski (1/2) Przyciski z ikoną lub ikona+tekst, jeśli w ogóle, powinny być używane tylko dla generycznych, ogólnych akcji tooltip tylko dla przycisków z ikoną Położenie przycisku zależy od tego, czego dotyczy akcja przez niego wyzwalana: w pasku narzędziowym obszaru roboczego w pasku narzędziowym tabeli w pierwszej kolumnie tabeli poniżej grupy pól w formularzu obok pola w formularzu Wyrównanie: generalnie do lewej poza niektórymi generycznymi w paskach narzędziowych np. Print, Help

44 Przyciski (2/2) Aktywność przycisków: Gdy użytkownik nigdy nie ma prawa uruchamiania danej funkcji, to przycisk nie powinien być wyświetlany w ogóle Gdy akcja jest w danej chwili niedostępna i powody tego są oczywiste, przycisk jest nieaktywny Gdy akcja jest niedostępna z powodów, które dla użytkownika nie muszą być oczywiste, przycisk powinien być aktywny, a jego użycie powinno powodować wyświetlenie stosownego komunikatu o błędzie z wyjaśnieniem Uwagi o przyciskach w oknach dialogowych: zawsze tekstowe (bez ikon) wyrównane do lewej lub do środka przycisk zatwierdzający, jeśli taki jest, jest pierwszy z lewej

45 Link czy przycisk? Link: przechodzenie do szczegółowych informacji może mieć przyporządkowaną nazwę konkretnego obiektu Przycisk: wykonanie zadania lub nawigacja do zadania nazwa odnosi się do generycznej akcji

46 Date Picker Ułatwia wprowadzenie poprawnych dat Wyświetlany inline lub w pomocniczym modalnym oknie Niezależnie od sposobu wyświetlania, podstawowym sposobem wprowadzania daty jest pole tekstowe

47 Walidacja Błędy powinny być wyświetlane w tej samej linii co pole, aby zapewnić możliwość szybkiego rozwiązania okno dialogowe z listą błędów z wielu pól nie jest dobrym rozwiązaniem Walidacja pola po wprowadzeniu wartości, a nie już w trakcie Jeśli pole posiada limit znakowy należy go pokazać i modyfikować dynamicznie podczas wypełniania pola Wszelkie błędy powinny być od razu widoczne jako błędy, pola których dotyczą błędy powinny być dodatkowo zaznaczone

48 Komunikaty o błędach walidacji Komunikat poprzedzony ikoną; kolor czerwony Komunikaty o błędach powinny być spójne Komunikat o błędzie musi zawierać 3 informacje: jaki błąd? gdzie? co dalej?

49 Interakcja z użytkownikiem

50 Komunikaty Położenie: pasek komunikatów Message Box (między paskiem narzędziowym i obszarem roboczym) nie dla komunikatów o trwającym przetwarzaniu tabele (tylko komunikat o braku danych) okna dialogowe Komunikat poprzedzony jedną z czterech ikon zależnie od typu komunikatu błąd, ostrzeżenie, informacja, potwierdzenie Odpowiedni dobór słów i interpunkcji np. nieużywanie proszę kropka tylko gdy po zdaniu pytanie nieużywanie wykrzykników i kapitalików

51 Sygnalizacja przetwarzania Konieczna dla akcji (szczególnie asynchronicznych) zajmujących ponad sekundę Oszukanie percepcji upływu czasu przez pasek zaawansowania lub tzw. kręciołek należy stosować jeden albo drugi, nie oba jednocześnie pasek zaawansowania (progress bar) jeden przebieg, nie może w trakcie akcji wracać do początku

52 Wyszukiwanie Domyślnie 4 wiersze do kryteriów selekcji wyświetlane na starcie (atrybut, operator, wartość, dodanie/usuwanie warunku składowego) Operatory wybierane z listy sformułowane w języku naturalnym, dostępne operatory powinny zależeć od typu pola Specjalne przypadki: dla between pojawia się drugie pole dla is empty pole do wprowadzenia wartości dla warunku znika Wyniki na tej samej stronie poniżej formularza z kryteriami selekcji

53 Okna dialogowe Zastosowania okien dialogowych: Komunikaty informacyjne Wymaganie potwierdzenia krytycznych akcji Personalizacja aplikacji Wprowadzanie dodatkowych danych Dalsza nawigacja z modalnego okna dialogowego niemożliwa z wyjątkiem powrotu do strony wywołującej w związku z zamknięciem okna z wyjątkiem wywołanie okna pomocy lub nawigacji poprzez link zewnętrzny do jakiegoś niemodalnego okna dialogowego Rozmiar zależny od zawartości dopuszczalny pionowy pasek przewijania Przyciski wycentrowane

54 Zasady dla okien pop-up Użytkownik powinien spodziewać się wyświetlenia okna Zawartość powinna stanowić dodatek w stosunku do okna głównego Użytkownik powinien wiedzieć co zrobić by zamknąć okno Jedno okno pop-up w danej chwili

55 Kreatory Stosowane dla złożonych rzadko uruchamianych procesów, które można podzielić na etapy Zawsze należy pokazać kontrolkę z etapami procesu i miejscem w którym jest aktualnie użytkownik (mapa drogowa)

56 Skróty klawiaturowe Uwaga by nie przykrywać skrótów popularnych przeglądarek usability może ucierpieć, jeśli użytkownicy korzystali z tych skrótów Rodzaje skrótów Tab i Shift-Tab do nawigacji między elementami Gorące klawisze (accelerator, hot keys) dla niektórych akcji z pominięciem menu i nawigacji Klawisze dostępu przenoszą focus na wskazany element Enter wywołujący akcję gdy focus jest na linku lub przycisku Uwaga: po wejściu na stronę do wprowadzania danych, focus powinien być automatycznie w pierwszym polu, tak aby oszczędzić użytkownikowi niepotrzebnej nawigacji

57 Dostępność dla osób niepełnosprawnych

58 Kolorystyka 5-10% ludzi ma problem z percepcją niektórych kolorów Wskazana weryfikacja jak strony są widziane przez ludzi z różnymi wadami wzroku Vischeck ( Symulowane wady: deuteranopia, protanopia, tritanopia Colorblind Web Page Filter ( Symulowane wady: protanopia, deuteranopia, tritanopia, trichromatyzm, protanomalia, deuteranomalia, tritanomalia, achromatopsja

59 Pozostałe wskazówki Alternatywny tekst dla nietekstowej zawartości Separacja pierwszego planu od tła Cała funkcjonalność dostępna z klawiatury Pomoc w nawigacji i informowanie o aktualnym położeniu w aplikacji Zgodność z mechanizmami ułatwień dostępu w przeglądarkach

60 Przykłady interfejsu aplikacji korporacyjnych

61 Przykłady przemysłowe: SAP R/3 brak informacji o położeniu w nawigacji kontrast skróty szerokości pól niezrozumiałe przyciski wyrównanie etykiet przyciski z ikonami suwak poziomy