Door Anoniem: Waarom is het dan niet gewoon een html-form met een submitbutton die het ook met Lynx doet i.p.v. een complex ding met plaatjes en allemaal JavaScript?
Het W3C heeft helaas al behoorlijk lang geleden uit de aanbevelingen voor toegankelijke websites de werking zonder JavaScript laten vervallen. Er bestaan allerlei web-frameworks die die terugval op HTML zonder JavaScript ook al niet als uitgangspunt nemen.
Op zich kan het wel degelijk. Vanuit JavaScript kan een webpagina
volledig herschreven worden. Dat impliceert dat het in beginsel
altijd mogelijk is om een versie die zonder JavaScript werkt als beginpunt te nemen en vanuit JavaScript er een gelikte versie van te maken met alle toeters en bellen die je maar weet te bedenken, en die requests naar de server niet alleen voor volledige pagina's maar ook vaak voor kleine onderdelen ervan doet.
Wel is het zo dat die twee modellen, de hele pagina verversen versus alleen onderdelen ervan, behoorlijk ver uit elkaar zijn gaan lopen waardoor de afhandeling op de server ervoor ook heel verschillend wordt. Om hele pagina's te verversen moeten alle gegevens voor een pagina in één request geleverd worden, terwijl bij de opbouw in onderdelen een reeks aparte requests voor die onderdelen gedaan kan worden, die dan ook weer los van het grote geheel kunnen worden uitgevoerd. Om hele pagina's in een keer op te leveren bij elke wijziging van een onderdeeltje in die pagina moet de server ofwel een uitgebreidere sessie-staat bijhouden die al die gegevens bevat, ofwel per request veel meer gegevens opnieuw uit een database ophalen. Het verschil zit dus niet alleen in de browser, maar heeft ook een grote impact op hoe de applicatie op de server werkt. Dat wil niet zeggen dat daar geen voorzieningen voor te bedenken zijn, maar die maken het geheel wel complexer.
Toen ik, eind jaren '90, als ontwikkelaar betrokken raakte bij een webinterface voor een grote verzameling mainframe-applicaties, kwam ik al snel op de website van W3C het begrip
graceful degradation tegen. Dat komt erop neer dat je je applicatie zo maakt dat als een onderdeel niet werkt, bijvoorbeeld JavaScript, je terugvalt op iets dat nog wel werkt, bij JavaScript de mogelijkheden van kaal HTML dus, inclusief hyperlinks en formulieren.
Aangezien je JavaScript nodig hebt om in de webbrowser wat dan ook te veranderen aan een webpagina, besefte ik meteen dat JavaScript onmogelijk gebruikt kan worden om die terugval te implementeren, want als JavaScript uitstaat doet het simpelweg niets meer. Qua implementatie draai je het daarom om: begin met een versie in kaal HTML die het gewoon doet, en gebruik JavaScript niet om terug te vallen maar om de extra's die je nodig hebt toe te voegen.
Ik was als automatiseerder allang gewend dat er regelmatig situaties zijn dat een nieuwe mogelijkheid, ten opzichte van hoe hij beschreven wordt (vaak vanuit het perspectief van de gebruiker van de applicatie), ongeveer achterstevoren en binnenstebuiten gekeerd geïmplementeerd moet worden om precies het gewenste effect te bereiken. Dat komt omdat het moet aansluiten bij de al aanwezige opzet van het systeem waarop je voortbouwt. Voor mij was het een open deur dat dat voor
graceful degradation in webappicaties die vertaalslag ook nodig was. En die paste ik dan ook toe.
Vervolgens verbaasde ik me jarenlang erover dat dit in de meeste andere websites overduidelijk
niet werd gedaan. De reden daarvoor werd me duidelijk toen het concept van
progressive enhancement gelanceerd werd en aansloeg bij webontwikkelaars. Dat was
exact wat ik al jaren deed: begin met een HTML-versie die zonder JavaScript werkt en breng daar de wijzigingen in aan die het gelikter maken. Voor mij is
graceful degradation het effect dat je wilt bereiken en
progressive enhancement de manier waarop je dat effect implementeert. Voor mij is dat zo vanzelfsprekend dat ik er geen aparte term voor nodig heb, ik had dat letterlijk al bedacht voor ik het stukje over
graceful degradation van W3C helemaal uitgelezen had.
Maar een forse meerderheid van de webontwikkelaars bleek te denken dat
graceful degradation sloeg op hoe je de implementatie doet. Die concludeerden uit het feit dat dat zo niet
kan werken, dat je niet via JavaScript iets kan veranderen in een webpagina als JavaScript uitstaat,
niet dat je voor de implementatie dan een andere benadering nodig hebt, maar dat W3C een tent was die theoretisch uit zijn nek kletst zonder iets van de praktijk te snappen. Die hadden iemand nodig die voor ze bedacht hoe het toch kon werken en dat met een fancy naam onder de aandacht wist te brengen.
Kennelijk had ik de gemiddelde intelligentie van webontwikkelaars ernstig overschat.
Omdat webontwikkelaars dit massaal niet snapten en dus niet toepasten is die terugval naar kaal HTML nooit een vanzelfsprekendheid geworden op het web. Wie weet heeft W3C het mede uit de toegankelijkheidsaanbevelingen laten vallen omdat het hopeloos was om te verwachten dat dit nog goed zou komen, naast natuurlijk het feit dat JavaScript steeds krachtiger werd en steeds beter gestandaardiseerd raakte. Zonder die richtlijn is er vervolgens nooit een noodzaak geweest voor de ontwikkelaars van allerlei web-frameworks om te zorgen dat die terugval naar kaal HTML out-of-the-box (voor zover dat nog mogelijk is) ondersteund wordt. En dus hebben we die niet.
Wat ik bij hedendaagse webapplicaties vooral prettig vind is als de JavaScript die nodig is om te functioneren van de site zelf komt. Dat maakt het in add-ons die JavaScript blokkeren (NoScript, uBlock Origin etc.) eenvoudig om een webapplicatie werkend te krijgen. Er zijn helaas websites die afhankelijk zijn van JavaScript van derden, die weer aanpassingen doen die JavaScript van vierde partijen nodig hebben, vervolgens vijfde partijen etc., en dan wordt het een puzzel. Bij de interfaces voor internetbankieren die ik gebruik (ASN, Triodos en Rabo) zit dit gelukkig goed.