O ile robię wszystko, co w mojej mocy, żeby popularyzować wsparcie dla standardów i poprawianie usability w sieci, nie każdy przypadek jest taki sam i nie zawsze można ślepo stosować te same reguły.
W większości przypadków faktycznie, powinno się ograniczyć technologie wspierające (czyli tak naprawdę wszystko poza HTML) do minimum, zapewniając tym samym jak najlepszą dostępność do informacji dla osób korzystających z różnych urządzeń i oprogramowania. Nie chcemy przecież któregoś dnia zalogować się do swojego systemu bankowego tylko po to, żeby dowiedzieć się, że brakuje nam 16 wtyczek, z czego 8 nie jest dostępnych dla naszej platformy (co jest coraz powszechniejszym problemem, nie dotyczy już tylko urządzeń przenośnych, ale także komputerów pracujących na procesorach rodzin AMD64 i PPC). Wszystko jest jednak warunkowane przez target, dla którego przeznaczony jest nasz produkt.
Głupotą byłoby zrezygnowanie z technologii takich jak Flash, czy zagnieżdżone wideo na stronach reklamujących najnowszą grę komputerową - serwis tego typu jest przeznaczony dla wąskiej grupy odbiorców, raczej nie grozi nam nawał użytkowników uzbrojonych w telefony komórkowe, PDA czy konsolowe przeglądarki pracujące pod kontrolą systemów uniksowych. Zwłaszcza, jeśli gra przeznaczona jest dla jednej konkretnej platformy. Jej podstawową funkcją jest pokazanie odwiedzającym namiastki tego, co znajdą w reklamowanym produkcie, stąd zastosowanie znajdą tam najnowsze technologie multimedialne.
Podobna sytuacja ma miejsce w przypadku aplikacji webowych. Zamknięte systemy, wymagające logowania, takie jak intranety, ekstranety czy panele kontrolne CMS służą jedynie swoim użytkownikom. Nie musimy martwić się tym, że zostaną nieprawidłowo zaindeksowane przez wyszukiwarki, a układ hierarchiczny z definicji nie przypomina typowej strony internetowej. Wszechobecne formularze i układ aplikacyjny z definicji dyktują strukturę dokumentów, która często nie może być tak czysta, jak w przypadku zwykłych serwisów - musi sprostać projektowi graficznemu, który niejednokrotnie bardziej przypomina aplikację rodem z pakietu MS Office niż dokument stworzony w HTML.
Tutaj znajdują zastosowanie gorące nowinki ze świata, z modnym ostatnio hasłem AJAX na czele. Jeśli aplikacja ma wyglądać jak zwykły program, to funkcjonalność typu drag-n-drop z zapisywaniem danych w locie (bez przeładowania) jest dla użytkownika czymś naturalnym. W przeciwieństwie do usability typowych stron, w kwestii aplikacji standardy wyznacza Ruby on Rails i świetny framework script.aculo.us.
Kwestia wsparcia dla przeglądarek z wyłączonym JS nie jest problemem, sprzedajemy program i ma on swoje wymagania. Nikt nie oczekuje, że Windows XP zacznie działać na 286, nikt też nie narzeka, że najnowsze mordobicie na konsolę nie nadaje się do użytku po wyłączeniu telewizora.
Inaczej wygląda sprawa ze specyficznymi klientami - w pewnych warunkach nie jest możliwe zastosowanie czystego układu (strukturalny dokument + CSS). Nie jest to jednak powód do tego, żeby całkowicie zarzucić wsparcie dla styli - zbudowanie układu hybrydowego (tabela do pocięcia układu + CSS do zgrania całości) daje dużo więcej korzyści niż sama satysfakcja. Strona jest przede wszystkim dużo lżejsza, a przez to ładuje się szybciej (choć układy tabelaryczne nie pozwalają na renderowanie progresywne w takim zakresie, jak oparte na czystej strukturze) i jest znacznie łatwiejsza w edycji (a wprowadzając zmiany w arkuszu styli możemy w prosty sposób zmienić wygląd setek podstron). Zapewniamy sobie też identyczny wygląd we wszystkich przeglądarkach, także w tych przyszłych (wyobraź sobie, jak wyglądałoby teraz 95% internetu, gdyby przeglądarki nagle porzuciły wsparcie dla przestarzałych elementów, jak <font/>).
Z drugiej strony są też ekstremiści, którzy nawet dane typowo tabelaryczne (jak zestawienia statystyczne, czy cenniki) zamieniają na groteskowe konstrukcje, które według nich są bardziej semantyczne. To jednak - na szczęście - kwalifikuje się w większości przypadków jako nieszkodliwe geekostwo i zajęcia typu proof of concept. Użycie takiego wynalazku w realnym projekcie komercyjnym może tylko wystawić autora na publiczne pośmiewisko - jest dowodem zupełnego braku zrozumienia semantyki języka.
Podsumowując - twarde zapieranie się rękoma i nogami przed zastosowaniem bogatych multimediów czy oparciem funkcjonalności na językach skryptowych po stronie agenta przy argumentacji, że to dla dobra usability, nie zawsze jest właściwe. W niektórych, specyficznych przypadkach, odwiedzający oczekuje takiej właśnie funkcjonalności i wzbranianie się przed nią jest działaniem na szkodę użytkownika.