Webrichtlijn 3: Niet rekenen op optionele technologie (R-pd.1.3)
Maak de functie van de website niet afhankelijk van optionele technologie, zoals CSS en client-side script: optionele technologie dient de informatie op de site en het gebruik ervan te complementeren en niet de toegang ertoe te belemmeren wanneer deze technologie niet ondersteund wordt. (R-pd.1.3)
Volgens de richtlijn zijn er uitzonderingen. Ben jij het met die uitzonderingen eens?
Hou je rekening met het feit dat afbeeldingen uit kunnen staan? En dan niet met betrekking tot het alt attribuut, maar met oog op image replacement technieken (text-indent: -9999px; background-image: url(foo.png); bijvoorbeeld). Hoe ver ga je?
Voeg jij HTML met functionaliteit waar JavaScript voor vereist is altijd toe met JavaScript zelf? Of maak je soms een uitzondering? In welke gevallen?
Wanneer adviseer je klanten of opdrachtgevers trouwens om de hele site opnieuw te (laten) bouwen?
Reacties
- 1 Marcel op 15-01-2008 om 09:39 uur:
- Waar iets contextueel relevant is pas je image replacement toe. Headers (h1 .. h5) met een apart font zijn bij mij gewoon h1..h5-tags met een background-image.
Maar een sfeerplaat die geen ander doel heeft dan het opleuken van een visueel design behoeft wat mij betreft geen aandacht om dit voor slechtzienden zichtbaar te maken. Dan besteed ik er eerder tijd aan om deze uit de HTML te verwijderen om op die manier geen overbodige informatie in de pagina te laten staan.
En javascript is in de meeste gevallen optioneel, dat wil zeggen: in websites waar ik geen controle heb over het gebruik van de website moet men zonder javascript de site perfect kunnen gebruiken.
Er zijn immers overijverige systeembeheerders in grote bedrijven die standaard javascript uit zetten voor het gehele bedrijf.
Waar ik echter wel controle over de doelgroep heb (intranetten bijvoorbeeld) wil ik me ook kunnen uitleven. Drag 'n drop interfaces (denk Extjs, Jquery, etc.) en Ajax en nog meer fancy buzzwords waar verkopers geil van worden.
Maargoed, ook een intranet kan te maken krijgen met slechtzienden of anderzijds gehandicapte gebruikers. Waar mogelijk is er dan ook een alternatief voor drag 'n drop. Dat zal dan omslachtiger zijn, maar in ieder geval een mogelijkheid.
Kortom: onderzoek je doelgroep en richt je daar op. Dat brengt uiteindelijk het meeste geld in de bankrekening ;-) - 2 Sander v L op 15-01-2008 om 11:29 uur:
- Het niet afhankelijk zijn van het bestaan van optionele technieken krijg je 'gratis' als je progressive enhancement gebruikt.
Het enige 'probleem' dat dan nog overblijft ligt op het raakvlak van meerdere optionele technieken. Wat gebeurt er met je web applicatie als JavaScript aan staat, maar CSS niet? Accepteer je dat dan plotseling alle form velden tegelijk tonen, of schrijf je je JavaScript om de velden compleet uit de DOM te verwijderen (wat op een gegeven moment performance impact gaat hebben) zodat dat niet gebeurd?
Dit is zo'n edge case dat elk antwoord waarschijnlijk goed gerekend kan worden; zolang er in ieder geval maar even over wordt nagedacht en er bij de ontwikkeling rekening mee wordt gehouden.
CSS aan en JavaScript uit komt vaker voor, maar leidt in mijn ervaring ook tot minder problemen - zolang je maar een server-side weg hebt om display: none; onderdelen alsnog te tonen.
De mogelijkheid van images uit zijn voor mij de reden om niet image replacement technieken zoals hierboven beschreven te gebruiken; als het een plaatje verdient, dan mag het ook een daadwerkelijk plaatje zijn; In mijn ervaring ziet Google een alt tekst van een plaatje binnen een <h1> niet als minder waard dan die tekst rechtstreeks in een <h1>. (En de text-indent zou zelfs in theorie als hidden tekst kunnen worden aangemerkt.)
Overigens... @krijn: plaatjes uit maar CSS aan op de fronteers weblog leidt tot zeer slecht contrast voor de helft van de posts (de even .section divs) - donkergrijs op zwart. Lijkt een bug in je CSS te zijn, door een conflict tussen de volgende rules:
html, body { background: #fff; }
die wordt overschreven door:
html { background: #000; }
en
body { background: transparent; } - 3 Ronald op 15-01-2008 om 19:00 uur:
- >Wanneer adviseer je klanten of opdrachtgevers trouwens om de hele site opnieuw te (laten) bouwen?<
Als het benodigde budget voor aanpassingen het budget voor het nieuw bouwen van een site overstijgt. - 4 stelt op 16-01-2008 om 00:03 uur:
- Waarom staat Flash dan als optie bij het inschrijfformulier? Flash is namelijk behoorlijk optioneel. Je hebt een plug-in nodig, als er tenminste een versie bestaat die op jouw OS+browser combi werkt. Probeer dat maar eens op je mobieltje, je EEE of een van de vele andere PCs die niet up-to-date zijn volgens wat Microsoft en Adobe willen.
- 5 stelt op 16-01-2008 om 00:07 uur:
- En dan zwijg ik nog over alle manieren waarop Flash niet OPEN is.
- 6 Sander op 16-01-2008 om 03:20 uur:
- @stelt
Wanneer je Flash gebruikt wil dat toch niet automatisch zeggen dat de functie van de website ervan afhankelijk is. - 7 Sander v L op 16-01-2008 om 09:57 uur:
- @stelt
Hoewel ik het helemaal met je eens ben dat er aan Flash zeer veel nadelen kleven, is deze vereniging niet alleen voor de webstandaarden. Zoals besloten op de algemene leden vergadering willen wij - ondanks het feit dat we op dit moment nauwelijks actieve (Flash) leden hebben - een thuis bieden aan iedereen die iets aan de front-end van webdevelopment doet, en Flash hoort daar zeker bij (net zoals shudder Silverlight e.a.).
Natuurlijk streven we wel "professionalisering" na, wat o.a. betekent dat we de webstandaarden zeer sterk aanraden (het is waarschijnlijk voor bijna iedereen van ons "inconceivable" om je professioneel te noemen zonder die te volgen). Maar het schijnt dat ook Flash toegankelijk kan worden opgezet, met goede equivalente fallback - en dan wordt er dus niet op Flash vertrouwd, maar is Flash een optionele techniek die een laag toevoegt bovenop de basis van HTML. En het gaat aan de Flash-ontwikkelaars binnen deze vereniging zijn om de methoden hiervoor algemener bekend te maken als onderdeel van de push om de frontend ontwikkeling van Flash te professionaliseren. - 8 Sander v L op 16-01-2008 om 09:58 uur:
- Erm - die haakjes zijn verkeerd geplaatst door het herschrijven van de zin; wilde natuurlijk zeggen:
"ondanks het feit dat we op dit moment nauwelijks (actieve) Flash leden hebben" - 9 Kilian Valkhof op 16-01-2008 om 14:57 uur:
- Stelt, flash werkt prima op mijn EEE ;) Daarnaast zijn er ook al zat opensource implementaties van (die inderdaad niet allemaal evenveel kunnen als adobe flash)
Overigens, voor een leuk en toegankelijk flash voorbeeld: http://webkitchen.be
view-source ;)
Over deze richtlijn: Websites gelaagd bouwen zorgt naar mijn idee voor 99% van deze richtlijn. De andere 1% is het rekening houden met "de exotische" combinaties als "wel javascript, geen css", "wel css, geen afbeeldingen".
Het voorbeeld wat in het artikel genoemd wordt, die van image-replacement met plaatjes uit is een lastige, en blijft naar mijn idee behelpen tot siFR of webfonts goed, snel en crossbrowsers werken. Er is gewoon geen ideale manier voor. (of: elke methode heeft nadelen) - 10 Sander v L op 16-01-2008 om 17:02 uur:
- @Kilian: ik weet niet of die webkitchen zo'n goed voorbeeld is. Ik heb hier geen Flash. Als ik de site bekijk zie ik bijvoorbeeld een Adobe Flex Builder 3 plaatje wat de helft van de tekst van de "Flex 3 / AIR roadshow starts next monday" entry overlapt (niet leesbaar dus), en ik mis een scrollbar, waardoor ik alleen de eerste drie entries kan lezen. Niet echt wat je toegankelijk noemt.
Het idee is goed, maar de uitvoering beduidend minder.
De site werkt beter als ik CSS uitzet, maar dan merk je gelijk dat alle semantiek ontbreekt. Geen paragrafen, geen headers: eigenlijk alleen maar divitis. - 11 Stephen Hay op 18-01-2008 om 15:37 uur:
- Ben eens de lezers die zeggen dat het houden aan 1.2 (progressive enhancement) er vaak voor zorgt dat je hier ook aan voldoet. Wellicht handig om te weten waarom veel van de Webrichtlijnen elkaar overlappen; er zit veel redundantie in omdat er vroeger twee sets richtlijnen waren: de minimale en optimale sets. Deze zijn inmiddels gecombineerd. Wel voordelig voor ontwikkelaars: voldoen aan één richtlijn kan betekenen dat je meteen aan meerdere voldoet.
- 12 Gerrit Berkouwer op 18-01-2008 om 16:16 uur:
- @Krijn: kunnen we bij elke richtlijn in deze serie vermelden bij welk nummer we zijn aanbeland? Dit was "week 3/de 3e richtlijn", maar dat staat niet meer in de kop.
- 13 Krijn op 21-01-2008 om 12:09 uur:
- @Sander: fixed. Andries vond het prettiger als de achtergrond ook zwart was, maar okay.
@Gerrit: zoiets? - 14 Gerrit Berkouwer op 22-01-2008 om 13:46 uur:
- @Krijn: lijkt mij prima, dank!
- 15 Serge Jespers op 20-02-2008 om 22:50 uur:
- Yep... je hebt gelijk. Ik moet dringend nog wat aan mijn CSS sleutelen. Eigenlijk heb ik deze "schaduw" alleen maar gemaakt om mijn Flex site te laten indexeren door Google en eigenlijk nooit nagedacht over een betere experience te maken voor mensen zonder Flash. Dus thanks for pointing this out... Ik ga hier zeker eens aan sleutelen.
Serge Jespers
Webkitchen.be