BETA
Aby się zalogować, najpiew wybierz portal.
Aby się zarejestrować, najpiew wybierz portal.
Podaj słowa kluczowe
Słowa kluczowe muszą mieć co najmniej 3 sąsiadujące znaki alfanumeryczne
Pole zawiera niedozwolone znaki

Baza wiedzy











ASP .NET 2.0: gdzie się podziały tamte standardy?

26-02-2006 20:09 | zooly
Artykuł ten nie jest kolejnym tutorialem dotyczącym języka XHTML. Zawiera on przegląd zmian w ASP .NET 2.0 i Visual Studio 2005 i analizę możliwości ich zastosowania przy tworzeniu aplikacji internetowych zgodnych ze standardem XHTML i wytycznymi WCAG 1.0. Czytelnik dowie się, jakie korzyści można osiągnąć z zastosowania standardów i zaleceń W3C i dlaczego „dostępne” aplikacje WWW często wiążą się z dodatkowymi poświęceniami.

Wstęp

XHTML 1.0 został oficjalnie rekomendowany w 2000 roku. W ciągu kilku ostatnich lat liczba publikacji opisujących cechy tego języka osiągnęła tak duże rozmiary, że można wątpić w sens tworzenia nowych książek i artykułów. Niemal każdy twórca aplikacji internetowych słyszał o tym standardzie i jest w stanie wskazać różnice i zalety XHTML’a w porównaniu ze „zwykłym” językiem HTML (prawidłowe zagnieżdżanie znaczników, doctype, wymagany znacznik title). Jak się jednak okazuje, zastosowanie tego „prostego” standardu w praktyce ma miejsce niezwykle rzadko. Moim zamiarem nie było tworzenie kolejnego tutoriala dotyczącego tego języka, lecz zbadanie możliwości jego zastosowania w środowisku ASP .NET 2.0. Nowa odsłona środowiska programistycznego sama z siebie nie gwarantuje uzyskania stron zgodnych ze standardami. To od nas i naszej wiedzy zależy czy trud programistów z Redmond włożony w przystosowanie ASP .NET 2.0 do standardu XHTML nie poszedł na marne.

Nowa wersja ASP .NET oferuje także zwiększone wsparcie dla programistów i designerów, którzy chcą tworzyć dostępne aplikacje (zgodne z wymogami sekcji 508 i zaleceniami WCAG/WAI). W ostatnich rozdziałach przedstawię nowe funkcjonalności samej platformy jak i środowiska programistycznego, które mają nas wspomóc w tym zadaniu.

 

W dalszej części tekstu wielokrotnie pojawi się słowo przeglądarka, które dla większości użytkowników komputera oznacza programy takie jak Internet Explorer. Proszę jednak nie zapominać o innych aplikacjach takich jak: crawler’y, screen reader’y czy inne programy, które również mogą przetwarzać tworzone przez nas strony internetowe.

 

Czym jest sekcja 508, WAI i WCAG?

Nazwy te związane są z dostępnością (ang. accessibility) stron internetowych. Sekcja 508 to fragment ustawy ustalającej standardy i wymogi dotyczące m.in. systemów operacyjnych, aplikacji internetowych tworzonych w sektorze publicznym w USA.

WAI (Web Accessibility Initiative) jest podgrupą W3C (World Wide Web Consortium), koordynującą pracę wielu zespołów w celu:

  • tworzenia technologii internetowych dostępnych także dla osób upośledzonych
  • edukacji osób odpowiedzialnych za tworzenie nowych aplikacji
  • ustalania i propagowania standardów dla aplikacji wspomagających tworzenie stron internetowych

WCAG 1.0 (Web Content Accessibility Guidelines) to natomiast zestaw wskazówek stworzony przez WAI dla nas - programistów, dzięki któremu tworzone przez nas aplikacje będą dostępne dla jak największej liczby użytkowników.

 

Jestem programistą, nie designerem

W iększość czytelników zastanawia się teraz nad sensem czytania tego artykułu. XHTML? CSS? Po co nam ta wiedza? Jesteśmy programistami a nie designerami. Zgodziłbym się z tym twierdzeniem gdybyśmy żyli w „idealnym” świecie. Tak jednak nie jest – zapewne wielokrotnie zdarza się nam tworzyć kontrolki użytkownika, co może wiązać się z „przeciąganiem” kontrolek serwera na projektowany formularz. Visual Studio dość skutecznie chroni nas przed oglądaniem kodu (X)HTML. W ekstremalnych przypadkach jesteśmy nawet w stanie stworzyć funkcjonalne strony bez ręcznej modyfikacji źródeł. Ale czy jest to dobre rozwiązanie? Bez względu na skomplikowanie i strukturę logiki aplikacji, zastosowane wzorce projektowe, zadaniem ASP .NET i aplikacji internetowej jest generowanie zestawu znaczników dla końcowego użytkownika.

Dla kogoś, kto odwiedza portal internetowy nie ma znaczenia czy baza danych jest rozproszona, czy baza działa w oparciu o SQL Server czy inny system zarządzania bazami danych. Wymagania „szarego” użytkownika są następujące:

  • aplikacja ma działać szybko i poprawnie
  • wygenerowana przez serwer zawartość (kod (X)HTML) ma wyglądać tak samo jak i działać na każdej przeglądarce

 

Szybkość i poprawność działania aplikacji internetowej zależy od naszych zdolności, doświadczenia i wiedzy dotyczącej korzystania z frameworku ASP .NET. Tutoriale, przykładowe aplikacje i dokumentacja dotycząca tego tematu są szeroko dostępne na vortalach poświęconych programowaniu – CodeGuru.pl, CodeProject, MSDN.

 

Skąd jednak „szary programista” ma dowiedzieć się jakie są konsekwencje stawiania znaku równości między warstwą prezentacji ASP .NET a Windows Forms? Jedyne co uzyskujemy po wpisaniu słowa XHTML w wyszukiwarce MSDN to odnośniki do tutoriali FrontPage 2003 o tytułach Master HTML tables, once and for all i im podobnych. Dość nieciekawie prezentuje się też sekcja  Web Development. Strony te zawierają kod niezgodny z przyjętymi standardami, którego korzenie sięgają czasów największej świetności Internet Explorera 5.0. Dopiero w „kąciku designera” znaleźć możemy wysokiej jakości artykuł Building ASP.NET 2.0 Web Sites Using Web Standards. Tylko który programista zagląda do sekcji przeznaczonej dla designerów?

 

XHTML, HTML 4.01, gdzie ta różnica?

Różnice między rekomendacją XHTML a HTML 4.01 nie sprowadzają się tylko do bardziej rygorystycznej składni. HTML został stworzony do samego opisu danych. Dopiero dodawanie nowych znaczników jak font, b, i, atrybutów jak bgcolor, border zniszczyło istotę tego języka. Już w wersji 4.01 języka HTML zostały one skrytykowane natomiast ich miejsce zająć miały kaskadowe arkusze stylów (CSS). HTML 4.01, podobnie jak XHTML 1.0 ma kilka wersji: strict, transitional i frameset. Upiorny znacznik font przetrwał jedynie w wersji transitional i frameset (czyli w celu łatwej konwersji stron zgodnych z poprzednią wersją HTML na nowszą).

„X” w nazwie nowego języka z którym wiązano takie nadzieje został wzięty od XMLa. Ignorancja przyjętych powszechnie zasad składni poszczególnych wersji języka HTML wymusiła na producentach przeglądarek skomplikowanie ich wewnętrznych parserów tak, by jak najdokładniej „odtworzyć” zamierzenia programisty. Jeśli znaczna część kodu przeglądarki jest przeznaczona do obsługi i interpretowania niepoprawnej składni, błędy muszą się pojawić. Zastosowanie parserów XML do dokumentów XHTML gwarantuje, że użytkownik zobaczy poprawną stronę lub błąd (w przypadku znalezienia jakiegokolwiek błędu w składni). Gdyby specyfikacje HTML od samego początku wymagały od parserów przeglądarek takiego zachowania, świat byłby zupełnie inny.

 

Media Type i klątwa IE, czyli dlaczego wstrzymanie wdrożenia XHTML 1.1 w aplikacji to dobry pomysł

Cześć z czytelników słyszała zapewne o MIMEmedia type, specjalnym oznaczeniu każdego pliku znajdującego się na serwerze WWW. Umożliwia ono przeglądarce odróżnienie pliku tekstowego od pliku zawierającego kod HTML.

Dla wszystkich wersji HTML’a stosowany jest typ text/html, XHTML 1.0 powinien być stosowany tylko z MIME: application/xhtml+xml.

Zabieg ten pozwala jednoznacznie odróżnić plik html zawierający kod HTML od pliku zawierającego kod XHTML i zastosować odpowiednio parser HTML, który „wybacza” wiele błędów składni lub bardziej „surowy” parser XML.

Przeglądarki 4 i 5 generacji (wymierające, ale nadal używane) nie potrafią rozpoznać tego typu MIME i zamiast wyświetlić stronę, proponują zapisanie jej na dysku.

Niestety problemy z obsługą wcześniej wspomnianego typu ma najbardziej popularna przeglądarka - Internet Explorer w wersji 6 (problem dotyczy także wersji 7).

 

W celu zapewnienia wstecznej kompatybilności języka XHTML 1.0 ze starszymi przeglądarkami, W3C dopuściła oznaczanie ich jako text/html. Spora grupa programistów i designerów uważa jednak, że takie postępowanie jest niepoprawne i może prowadzić do problemów po zmianie media type z text/html na application/xhtml+xml.

Zweryfikowałem te założenia i ustaliłem najważniejsze problemy, z jakimi możemy mieć do czynienia:

  • wszystkie skrypty osadzone bezpośrednio w dokumencie, ukrywane dotychczas za pomocą konstrukcji <!-- <kod JavaScript> // --> zostaną uznane jako komentarze i nie będą wykonywane
  • obecność znaku & w bezpośrednio osadzonym na stronie skrypcie skutkować będzie błędem parsera (skrypty takie powinny być umieszczane w sekcjach CDATA: <![CDATA[ kod ]]> )
  • właściwość nodeName zwracająca nazwę znacznika w drzewie DOM będzie zwracała body zamiast BODY (w XHTML wielkość liter ma znaczenie)
  • wielkość liter w selektorach styli nabierze znaczenia (np. taka definicja stylu nie zadziała: P {color: red;})

 

Zmianę zachowania się dokumentu w zależności od jego MIME można dokładnie prześledzić na przykładzie 1 (kod przykładów jest dołączony do artykułu

 

Zysk

Wszyscy korzystamy z wyszukiwarek internetowych. Liczba odświeżeń strony głównej Google’a liczona jest w milionach. Nie dziwi nas więc oszczędny wygląd samej wyszukiwarki. Strona odchudzona o każdy kilobajt daje ogromne zyski w postaci mniejszego obciążenia pasma i serwerów WWW wyszukiwarki. Wydawać by się mogło, że rozmiar 2,93 KB znaczników po pominięciu deklaracji DOCTYPE, usunięciu białych znaków to szczyt możliwości. Kilka lat temu ktoś jednak odważył się przerobić stronę główną do postaci zgodnej ze standardem XHTML transitional 1.0. Wynik: strona główna, okrojona z elementów prezentacyjnych zajmuje… 1,5 KB. Same style zajmują 1 KB. 2,5 KB, można uznać, że to niewielki zysk, ale biorąc pod uwagę domyślne ustawienia cache’owania przeglądarek, czyli fakt, że podczas kolejnych odwiedzin strony style nie zostaną pobrane, daje to ogromny zysk.

Nie wydaje się, że konwersja kodu Google’a jest taka skomplikowana – jeśli strona MSN Search jest zgodna z XHTML 1.0 strict, to chyba można tego dokonać?

 

ASP .NET i wcześniej

Wszelkie próby stworzenia strony internetowej przy pomocy ASP i ASP .NET, zgodnej ze standardami W3C były i są daremne. Niepełna walidacja kodu HTML (oparta nie na konkretnej wersji standardu, lecz składni akceptowanej przez wybrane przeglądarki) i automatyczne formatowanie kodu przy przełączaniu się między widokiem Design a HTML skutecznie uniemożliwiało tworzenie prawidłowych aplikacji. Na efekty nie trzeba było długo czekać: ASP .NET spotkał się z ogromną krytyką społeczności internetowej. Nic dziwnego – blogi tworzone przez fascynatów były lepiej zaprojektowane od strony użytkownika niż strony międzynarodowych koncernów. Dzięki ogromnym naciskom ze strony organizacji takich jak WaSP ASP .NET 2.0 zostało sprowadzone na „jasną stronę mocy” i niemal w pełni obsługuje standard XHTML (1.0 jak i 1.1).

 

ASP .NET 2.0

Wersja 2.0 platformy .NET Framework i nowe Visual Studio przyniosły wiele zmian, które bardzo ułatwią nam tworzenie stron zgodnych z XHTML:

  • Visual Studio 2005 przestało formatować kod (X)HTML
  • Każda nowoutworzona strona ASPX jest zgodna ze standardem XHTML Transitional:

<% @ Page Language ="C#" AutoEventWireup ="true" CodeFile ="Default2.aspx.cs" Inherits ="Default2" %>

 

<! DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

 

< html xmlns ="http://www.w3.org/1999/xhtml" >

< head runat ="server">

    < title >Untitled Page</title>

</ head >

< body >

    < form id ="form1" runat ="server">

    < div >

   

    </ div >

    </ form >

</ body >

</ html >

 

Do naszej dyspozycji mamy 3 nowe schematy walidacji kodu XHTML: Transitional, Frameset i XHTML 1.1. Wyboru odpowiedniego schematu możemy dokonać w menu domyślnie dostępnym na pasku zadań:

wybór schematu walidacji (X)HTML w Visual Studio 2005

 

Jeśli z dostępnej listy wybierzemy XHTML, wówczas po wpisaniu następującego (niepoprawnego) kodu:

    < div >

            < p >

  </ div >

 

wiadomość o tym będzie umieszczona na standardowej liście błędów kompilacji:

informacje o błędach w kodzie XHTML

ASP .NET 2.0: tryby renderowania

Sama walidacja składni XHTML’a nie rozwiąże naszych problemów gdyż nie możemy ingerować w sposób generowania kodu XHTML dla np. kontrolki GridView (ulepszonego odpowiednika DataGrida z ASP .NET 1.1).

 

Niestety zachowanie się kontrolek ASP .NET 2.0 możemy regulować tylko w jednym miejscu – standardowym pliku konfiguracyjnym (web.config). Oto fragment pliku konfiguracyjnego, który pozwoli nam na zdefiniowanie „zachowania” kontrolek na zgodne z XHTML 1.0 Strict:

 

 

 

< configuration >

  < system.web >

    <!-- fragment -->

    < xhtmlConformance mode = "Strict" />

  </ system.web >

</ configuration >

 

 

Do naszej dyspozycji mamy 3 tryby:

  • Legacy – całkowita zgodność z poprzednią wersją ASP .NET
  • Transitional – oferuje zgodność z XHTML Transitional
  • Strict – zgodny z XHTML 1.0 Strict

 

Taki sposób konfiguracji wymusza na nas dokonanie wyboru: albo tworzymy projekt zgodny z XHTML albo zostajemy przy poprzedniej „zupie tagów”. W niektórych przypadkach może być to niedogodnością – załóżmy, że dokonujemy konwersji istniejącej już aplikacji, nie mamy jednak czasu na jej kompletne dostosowanie do standardu XHTML. Idealnym rozwiązaniem byłaby konwersja tylko publicznie dostępnych stron i kontrolek i zostawienie części administracyjnej portalu bez zmian. Takie chytre rozwiązanie nie jest na razie możliwe.

 

Kamyk do ogródka

Niektóre kontrolki ASP .NET 2.0 (np. HyperLink, AdRotator) z powodu stosowania atrybutu target nie są zgodne z XHTML Strict czy XHTML 1.1. Nie jest to związane z lenistwem programistów z Redmond, lecz z brakiem odpowiedniego zastępcy tego atrybutu. Niestety problem ten dotyczy (częściowo) walidatorów. W wersji Visual Studio 2005, z której korzystam (8.0.50727.42) zmiana trybu renderowania kontrolek na Strict, ustalenie doctype’a na zgodny z XHTML 1.1 i zmiana MIME na application/xhtml+xml w żaden sposób nie wpływają na generowany przez walidatory skrypt. Rezultatem tego jest całkowicie bezużyteczny kod (dołączany do stron z walidatorami). Fragment:

 

 

< script type ="text/javascript">

<!--

var Page_ValidationActive = false;

if (typeof(ValidatorOnLoad) == "function") {

    ValidatorOnLoad();

}

 

function ValidatorOnSubmit() {

    if (Page_ValidationActive) {

        return ValidatorCommonOnSubmit();

    }

    else {

        return true;

    }

}

// -->

</ script >

 

 

Z poprzednich paragrafów wiemy też, że umieszczanie skryptów wewnątrz komentarzy HTML <-- i --> jest poprawne dla dokumentów udostępnianych jako text/html (czyli HTML 4.01, ewentualnie XHTML Transitional), ale nie dla XHTML 1.1! Na szczęście kod generowany przez walidatory nie zawiera znaków specjalnych i dzięki temu sama strona jest zgodna z XHTML 1.1. Jako że nie mamy żadnego wpływu na działanie walidatorów (chyba, że stworzymy zmodyfikowane wersje kontrolek), stosowanie ich po stronie klienta dla stron deklarujących zgodność z XHTML 1.1 mija się z celem.

 

Kamyk do ogródka #2

Wspomniałem wcześniej, że część programistów i designerów woli tworzyć kod zgodny z HTML 4.01 (przynajmniej do momentu w którym najpopularniejsza przeglądarka zacznie wspierać typ application/xhtml+xml). Mamy wprawdzie możliwość walidacji kodu pod względem poprawności z HTML 4.01 i tryb legacy wymuszający generowanie kodu zgodne ze starszymi przeglądarkami, ale w praktyce nie zdołamy osiągnąć zamierzonego celu. Dlaczego? Podczas pracy z Visual Studio 2005 możemy odnieść wrażenie, że walidacja kodu pod względem zgodności ze standardem HTML 4.01 jest mocno niedopracowana.

W HTML 4.01 niektóre znaczniki takie jak meta czy br nie mogą być domknięte, zaś dla paragrafów domknięcie jest opcjonalne.

Niestety, dla poniższego kodu:

<! DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

< html >

< head >

    < title >Untitled Page</title>

    < meta http-equiv ="Content-Type" content ="text/html; charset=utf-8">

</ head >

< body >

   

    < form id ="form1" runat ="server">

    < div >

        test

        < p >Test2

    </ div >

    </ form >

</ body >

</ html >

 

 

Visual Studio zgłasza błędy:

rzekome błędy w składni HTML 4.01

mimo iż strona jest całkowicie zgodna z HTML 4.01!

 

W praktyce dla osoby zaznajomionej ze specyfiką języka HTML 4.01 takie błędy nie stanowią przeszkody. Problemem nie do obejścia jest jednak renderowanie ukrytego pola zawierającego ViewState (znacznik nie powinien być domknięty, a niestety jest).

 

Walidacja stron i kontrolek

Visual Studio 2005 na bieżąco sprawdza poprawność tworzonego kodu XHTML (jeśli jednak przeszkadza nam kilkusekundowe opóźnienie, zawsze możemy ręcznie wymusić walidację poprzez kliknięcie w menu Edit/Advanced/ValidateDocument). Domyślnie wszelkie błędy w składni XHTML znalezione w dokumencie są wyświetlane jako błędy, nie jest to jednak przeszkodą przy kompilowaniu i testowaniu projektu.

Mechanizmy kontroli zgodności kodu z językiem HTML i XHTML są przydatne, musimy jednak pamiętać, że w większości przypadków wygenerowana przez ASP .NET strona składa się z kodu generowanego przez kilka (lub więcej) kontrolek i komponentów. Kontroli końcowego kodu powinniśmy dokonywać za pomocą walidatora W3C. Pomimo wielu opcji, jakie oferuje, walidacja za jego pomocą może być uciążliwa (np. gdy nie posiadamy publicznego IP lub korzystamy z wbudowanego w Visual Studio serwera WWW).

Znacznie wygodniej jest skorzystać z IE Developer Toolbar’a (w czasie powstawania artykułu dostępna była wersja Beta2). Oprócz wygodnego mechanizmu walidacji lokalnych stron oferuje on dodatkowe funkcjonalności, które ułatwiają analizę struktury konkretnej strony i zastosowanych w niej styli.

IE Developer Toolbar, podgląd opcji dot. walidacji oglądanej strony

IE Developer Toolbar

 

Failed redesigns, czyli dlaczego warto stosować standardy

Mianem Failed Redesigns (brak polskiego odpowiednika) określane są nowe strony lub strony, które w ostatnich miesiącach przeszły gruntowną przebudowę i zmianę layoutu. Tak duża modyfikacja strony powinna pozwolić na konwersję do postaci zgodnej z jakimiś standardami. W rzeczywistości prawie nigdy się to nie zdarza, mamy zazwyczaj do czynienia z dwoma przypadkami:

  • kompletnym niezrozumieniem technologii (przykład: http://www.tv.com/). Atrakcyjna grafika i DTD deklarujące zgodność z XHTML transitional skrywają ponurą rzeczywistość: ponad 300 błędów walidacji, zaś style strony są tak ciekawe, że zostały omówione na stronie TheDailyWTF (gorąco polecam)
  • ignorancją powszechnie przyjętych standardów (przykład: MSN Entertainment). Brak DTD (czyżby chęć zachowania zgodności z HTML 1.0?), połączony ze skryptami umieszczonymi w sekcji CDATA!

 

Taki stan jest do przyjęcia w przypadku, gdy strona została stworzona przez gimnazjalistę, lecz nie przez „profesjonalistów” zarabiających konkretne pieniądze!

 

Każdy programista ASP .NET wpisuje w swoje CV aplikacje internetowe w których tworzenie włożył swój wysiłek. Co może powiedzieć przyszły pracodawca, który odkryje, że tworzone przez nas strony są źródłem pośmiewiska w sieci? A jeśli okaże się, że nasz konkurent dostał posadę tylko dlatego, że jego blog pomyślnie przeszedł walidację, a nasz nie?

 

A teraz coś z zupełnie innej beczki

Wiele osób uważa kwestię dostępności (ang. accessibility) stron internetowych jako coś zbędnego, coś co tylko zabiera czas w którym moglibyśmy tworzyć nowe funkcjonalności lub poprawiać błędy aplikacji. Jeśli nie przejmujemy się marginesem użytkowników IE4 to czemu mielibyśmy się martwić o ten odsetek ludzi korzystających ze screen reader’ów?

 

Idea „dostępnych” stron internetowych dotyczy nas wszystkich. Takie „nadmiarowe” informacje jak atrybut img czy etykiety dla pól formularzy pozwalają niewidomym na dostęp do naszych stron, ale także wzbogacają doznania „zwykłych” użytkowników. Poniższy rysunek przedstawia 2 checkbox’y (przykład 3):

brak widocznych różnic między zwykłym checkbox'em a jego bardziej dostępną wersją

Wyglądają identycznie, jednak ich kod jest inny:

1)     < input type ="checkbox" /> Love VS 2005 :)

2)       < input id ="chk" type ="checkbox" name ="chk" />< label for ="chk">Love VS 2005 :)</label>

Pierwszy z nich przedstawia „starożytną szkołę” – widzimy opis pola, jednak nie jest on w żaden sposób skojarzony z samą kontrolką typu checkbox. Żeby pokazać przywiązanie do naszego ulubionego środowiska programistycznego, musimy wyjątkowo precyzyjnie kliknąć kursorem myszy na obszar składający się z kilkunastu pikseli. W przypadku jednego pola jest to niedogodność, w przypadku ankiety zawierającej 20 takich pól – przeszkoda.

Drugi z checkbox’ów został wygenerowany przez kontrolkę CheckBox ASP .NET 2.0 (wartości atrybutów id i name zostały przeze mnie skrócone). Zawiera on dodatkowe informacje - (etykietę), dzięki której screen reader będzie mógł skojarzyć opis z samym polem (za pomocą atrybutu for, który wskazuje na id elementu formularza). W zwykłej przeglądarce internetowej kliknięcie samej etykiety spowoduje natomiast zaznaczenie pola!

 

Aplikacja internetowa bazująca na standardzie WCAG będzie tak samo dostępna, bez względu na to czy przeglądarka użytkownika obsługuje CSS, obrazki czy wyświetla tekst (marzeniem każdego programisty i jego zmęczonych oczu byłoby posiadanie aplikacji, która czytałaby na głos artykuły ze stron MSDN czy CodeGuru.pl).

 

Bardziej dostępny ASP .NET 2.0

Sam zapał do tworzenia aplikacji internetowych przyjaznych dla wszystkich użytkowników nie wystarczy. Potrzebne są także zmiany w samych kontrolkach ASP dostępnych w .NET Framework 2.0. Wiemy już, że nie musimy się martwić tworzenie etykiet dla pól jedno- i wielokrotnego wyboru, jednak w jaki sposób można skojarzyć etykietę z polami tekstowymi czy listami rozwijanymi, które działają na serwerze? W zależności od kontekstu, w jakim kontrolki te są użyte, ich id może się dowolnie zmieniać. W ASP .NET 1.1 cel ten moglibyśmy osiągnąć poprzez stworzenie własnej kontrolki, która generowałaby znacznik label z odpowiednią wartością atrybutu for. W ASP .NET 2.0 wyręczy nas w tym kontrolka Label, oto fragment formularza (przykład 3):

 

 

< asp : Label ID ="lblNick" runat ="server"

  AssociatedControlID ="txtEmail">Twój e-mail</asp:Label>

< asp : TextBox ID ="txtEmail" runat ="server"></ asp : TextBox >

 

 

Ustalenie atrybutu AssociatedControlID kontrolki Label powoduje, że zamiast kodu

 

< span > Twój e-mail</span>

 

 

otrzymujemy:

 

< label for ="unikanleID_txtEmail" id ="ctl00_mainContent_lblEmail">Twój e-mail</label>

 

 

Dostępność – dlaczego powinno nam na niej zależeć

Jeśli zapewnienie dostępności naszej aplikacji dla większej ilości użytkowników nie jest argumentem przekonującym za jej stosowaniem, to może będzie nim ustawa? W USA w 1998 roku wprowadzono w życie ustawę Rehabilitation Act, zawierającą sekcję 508, której celem jest zniesienie barier w środkach elektronicznych. UE także zalecastosowanie się do zaleceń The Web Accessibility Initiative(WAI). Obecnie wiele firm korzysta z dofinansowań UE (np. w celu szkolenia pracowników) i są one zobowiązane do odpowiedniej promocji funduszy i samej Unii. Co będzie, jeśli to zalecenie zmieni się w wymóg? Czy warto odwlekać w nieskończoność wprowadzanie nieuniknionych zmian?

 

Kontrolki, które musimy poznać

To, że korzystamy z ASP .NET 2.0 i VS2005 nie oznacza, że automatycznie uzyskamy aplikację zgodną z XHTML i WCAG. Musimy wiedzieć jaki kod generuje kontrolka Label, GridView czy LinkButton. Abstrakcja oferowana przez kontrolki z przestrzeni nazw System.Web.UI.WebControls jest bardzo wygodna, jednak naraża nas na pewne niebezpieczeństwo.

Rozważmy kontrolkę użytkownika zawierającą etykietę działającą po stronie serwera (dyrektywy zostały pominięte):

< asp : Label ID ="myLabel" runat ="server" Text ="Label"></ asp : Label >

 

Jej walidacja w Visual Studio nie wykryje żadnych błędów. Nie oznacza to, że możemy spać spokojnie; załóżmy, że etykiecie przypisujemy wartość pobraną z bazy danych. Może być to czysty tekst, lub tekst zawierający znaczniki języka XHTML:

 

myLabel.Text = "<strong>CodeGuru.pl</strong>";

lub np.:

myLabel.Text = "<p>CodeGuru.pl</p>";

 

Druga linijka kodu jest jednak niepoprawna – ASP .NET wygeneruje odpowiedni jej fragment kodu pseudo-XHTML (przykład 4):

 

< span id ="mainContent_myLabel">< p >CodeGuru.pl</p></span>

 

 

Osadzanie elementów blokowych jak p w elementach typu inline jest niedopuszczalne, dlatego w tym przypadku lepiej byłoby zastosować kontrolkę Literal, która nie generuje dodatkowego kodu.

 

Kontrolki, o których powinniśmy zapomnieć

Kontrolki CheckBoxList i RadioButtonList zostały stworzone dla wygody programisty – dzięki temu nie musimy używać Repeater’ów czy „ręcznie” budować kod XHTML po stronie serwera. Jeśli jednak dbamy o dostępność naszej aplikacji, to powinniśmy zrezygnować z ich użycia. Dlaczego? Generowane przez te kontrolki przyciski jedno- lub wielokrotnego wyboru są opakowane w tabelę! Znacznik table powinien być stosowany w celu prezentowania zestawień danych, tabele w języku (X)HTML nadają znaczenie zawartym w nich elementom i nie powinny być stosowane do tworzenia layout’u strony. Wysiłek programistów włożony w dostosowanie tylu kontrolek ASP .NET do zaleceń W3C silnie kontrastuje z brakiem jakiegokolwiek wkładu do dostosowania kontrolek CheckBoxList i RadioButtonList do obowiązujących standardów.

 

Źródłem wielu kontrowersji jest także obecna już w poprzedniej wersji ASP .NET kontrolka LinkButton. Jest wyjątkowo atrakcyjna z punktu widzenia programisty, pozwala na obsługę po stronie serwera zdarzenia, jakim jest kliknięcie odnośnika. Podobne właściwości oferuje w ASP .NET zwykły przycisk, wspierany przez wszystkie przeglądarki od niepamiętnych czasów. LinkButton wygląda jednak z niewielką pomocą styli o wiele lepiej a sam daje w wyniku następujący kod:

 

< a href ="javascript:__doPostBack('_ctl2$newsRepeater$_ctl7$moreLink','')">Odwiedź CodeGuru.pl</a>

 

 

Cena, jaką musimy zapłacić za doskonały wygląd tej kontrolki jest niekiedy zbyt wysoka:

  • taki „przycisk” nie zadziała w przeglądarce nie obsługującej skryptów
  • użytkownik korzystający z nowoczesnej przeglądarki może pomyśleć, że ma do czynienia ze zwykłym odnośnikiem, jednakże dzięki naszej przebiegłości nie jest w stanie otworzyć go w nowej zakładce. Prędzej czy później zrazimy do naszej aplikacji wielu użytkowników
  • crawler’y takich wyszukiwarek jak MSN Search czy Google nie obsługują skryptów i nigdy nie zaindeksują zasobu do którego prowadzi odnośnik z kodem JavaScript

 

AutoPostback

Z poprzednich paragrafów można wywnioskować, że ASP .NET 2.0 nie ułatwia nam pracy przy tworzeniu dostępnych aplikacji. W większości przypadków sami musimy ustalać np. właściwość AlternateText dla kontrolki Image, TabIndex dla składników formularzy czy opis zestawu pól formularza (znacznik legend). Z używania części kontrolek powinniśmy zrezygnować (LinkButton) lub zmienić sposób ich stosowania. Tu przykładem może być właściwość AutoPostback, obecna dla list rozwijanych, pól tekstowych, pól wyboru. Ta jakże przydatna funkcjonalność oparta jest o skrypty działające po stronie klienta i nie będzie ona obecna dla części urządzeń przenośnych lub przeglądarek z wyłączoną obsługą skryptów.

 

Weryfikacja dostępności

Język XHTML ze względu na jasno określoną składnię, jest prosty w walidacji, dostępność danej strony internetowej – niestety nie. Do naszej dyspozycji istnieje wiele darmowych jak i komercyjnych aplikacji, w większości pozwalają one jednak na wykrycie znaczników img bez alternatywnego tekstu. Inne, bardziej zaawansowane, jak np. Wave 3.0 potrafią wykryć spacer’y (obrazki o wymiarach 1px na 1px stosowane do wizualnego formatowania strony) czy zastosowanie tabel do tworzenia layout’u.

Dostępność strony tworzonej w Visual Studio 2005 możemy sprawdzić po kliknięciu charakterystycznego przycisku na pasku narzędzi (rys.):

 

podgląd przycisku umożliwiającego weryfikację zgodności dokumentu z zaleceniami WAI i sekcji 508

Po wybraniu odpowiednich zaleceń (sekcja 508 – obowiązująca w USA i/lub WCAG/WAI) wszelkie nieprawidłowości zostaną (podobnie jak w przypadku błędów w składni języka XHTML) wyświetlone jako błędy i/lub ostrzeżenia (rys.):

błędy i ostrzeżenia związane z brakiem dostępności edytowanego w VS2005 dokumentu

Podział informacji jest następujący:

  • jako błędy kwalifikowane są jednoznaczne naruszenia wybranych przez nas wcześniej zasad i powinniśmy je poprawić
  • zadaniem ostrzeżeń jest poinformowanie nas o tym, że dany fragment kodu może być źródłem problemów (np. duże tabele bez nagłówków th);

 

Przyszłość

Od kilku miesięcy mamy do naszej dyspozycji VS2005 i .NET Framework 2.0, środowisko dzięki któremu wreszcie możemy tworzyć aplikacje zgodne z językiem XHTML i najważniejszymi zaleceniami dot. dostępności. Stosowanie doskonałego zestawu narzędzi nie jest gwarantem zgodności z obowiązującymi standardami. Nieprzyjemne doświadczenia wielu użytkowników związane z kontrolką LinkButton pokazują, że tworzenie dobrej jakościowo warstwy prezentacji w ASP .NET to coś więcej niż przeciąganie kontrolek na edytowany formularz. Czy będziemy w stanie zerwać ze starymi przyzwyczajeniami?

Pamiętajmy, że przyszłość i jakość nowych stron WWW leży w naszych rękach.

 

Literatura

Wszystkie odnośniki zamieszczone w artykule były dostępne 23 lutego 2006.

  1. XHTML FAQ (osiolki.net)
  2. Building ASP.NET 2.0 Web Sites Using Web Standards (MSDN)
  3. Web Page Development: Best Practices
  4. ASP.NET and XHTML (MSDN)
  5. Specyfikacja HTML 4.01
  6. Specyfikacja XHTML 1.0
  7. Web Content Accessibility Guidelines 1.0

Załączniki:

Komentarze 0

pkt.

Zaloguj się lub Zarejestruj się aby wykonać tę czynność.