Toegankelijkheid website*

[Bosmonster]

Modbreak:

Dit topic is afgesplits uit emailadres op website plaatsen

Wolfboy schreef op donderdag 23 september 2010 @ 02:20:
Je houd misschien de meeste bots tegen op die manier. Mar aan een fatsoenlijke spamfilter ontkom je toch niet. Ik doe wat dat betreft niet zoveel moeite meer om m'n mail adres te beschermen. Ze vinden 'm toch wel

Idd. En volgens de webrichtlijnen mag je het niet eens misvormen ivm toegankelijkheid Oplossingen met Javascript lijken me al helemaal ongewenst.

Beter kun je gewoon een adres aanmaken dat je alleen op de site gebruikt voor web-inquiries ipv persoonlijke e-mailadressen.

Wat je namelijk niet wilt is dat je bezoekers moeten boeten voor jouw probleem.

[ Voor 32% gewijzigd door MueR op 24-09-2010 11:25 ]

[DexterDee]

Bosmonster schreef op donderdag 23 september 2010 @ 10:20:
[...]


Idd. En volgens de webrichtlijnen mag je het niet eens misvormen ivm toegankelijkheid Oplossingen met Javascript lijken me al helemaal ongewenst.

Beter kun je gewoon een adres aanmaken dat je alleen op de site gebruikt voor web-inquiries ipv persoonlijke e-mailadressen.

Wat je namelijk niet wilt is dat je bezoekers moeten boeten voor jouw probleem.

Dat hangt dus helemaal af van de situatie en beoogde doelgroep.

Ten eerste, als je website al van javascript afhankelijk is omdat je bijvoorbeeld jquery gebruikt voor essentiele zaken is het prima om het email adres met javascript wat beter te beschermen.

Ten tweede, de toegankelijkheid komt niet in het gedrang, aangezien die javascript oplossing het email adres rechtstreeks op de juiste plaats als tekst in de DOM injecteert. Elk (audio)visueel hulpmiddel zal dus deze tekst gewoon kunnen lezen. Het feit dat crawlers als Google het email adres overslaan biedt naast nadelen IMO ook voordelen.

Voor een simpele website die echt overal moet werken, tot op de meest simpele Nokia en op browsers zonder javascript support ga ik zonder meer mee met je argumentatie.

[Bosmonster]

Ik denk dat je het concept "toegankelijkheid" verkeerd begrijpt. Javascript mag hierbij sowieso geen onderdeel uitmaken van het gebruik van de site. Het verminken van een e-mailadres op de website is dus bijvoorbeeld niet toegestaan vanuit de webrichtlijnen.

Daarnaast als je jQuery gebruikt voor "essentiele zaken", dan pas je jQuery al verkeerd toe. Waar jQuery juist in uitblinkt is de mogelijkheid het unobtrusive toe te passen. Maar op het moment dat je een website JS-afhankelijk opbouwt ipv middels progressive enhancement, toegankelijkheid blijkbaar toch al niet hoog op de eisenlijst staat.

Tuurlijk is toegankelijkheid niet altijd een belangrijk issue, maar de vraag is ook in hoeverre het belangrijk is dat je een e-mailadres op de site hebt staan (als je deze vervolgens niet kunt selecteren bijvoorbeeld), of hoe erg het is dat een e-mailadres gespiderd wordt (gebruik dan bijvoorbeeld een speciaal web-inquiry adres bijvoorbeeld).

Wat ik dus zeg is dat je je in het beginsel al af moet vragen of het verminken van een adres wel de beste oplossing is, aangezien er genoeg andere mogelijkheden en belangen zijn.

Daarbij is het dus een probleem van de sitebeheerder, maar wordt het met het verminken vervolgens een probleem van de bezoeker gemaakt (niet toegankelijk, over moeten typen, etc). Persoonlijk vind ik dat geen goede oplossing.

[ Voor 22% gewijzigd door Bosmonster op 23-09-2010 11:09 ]

[DexterDee]

Bosmonster schreef op donderdag 23 september 2010 @ 11:03:
Ik denk dat je het concept "toegankelijkheid" verkeerd begrijpt. Javascript mag hierbij sowieso geen onderdeel uitmaken van het gebruik van de site.

Ik begrijp het concept toegankelijkheid niet verkeerd. Het is echter geen wetmatigheid om geen javascript te gebruiken om een toegankelijke website te maken. Evenals het geen wetmatigheid is om je website altijd W3C compliant te maken. Het zijn richtlijnen en standaarden die je helpen om een betere website te maken. Het gebruik van javascript vermindert in vrijwel alle gevallen de toegankelijkheid in meer of mindere mate, dat klopt. Maar het gaat mij te ver om onvoorwaardelijk te roepen dat javascript nooit onderdeel uit mag maken van het gebruik van een site. Standaarden en richtlijnen zijn geen vrijbrief om je gezonde verstand uit te schakelen. Als iets logischerwijs een non issue is, moet het niet tot issue verheven worden.

Daarnaast als je jQuery gebruikt voor "essentiele zaken", dan pas je jQuery al verkeerd toe. Waar jQuery juist in uitblinkt is de mogelijkheid het unobtrusive toe te passen.

Totaal oneens. Natuurlijk moet je altijd streven naar graceful degradation, maar in de wereld van vandaag, waar we steeds meer praten over "web applicaties" in plaats van "web sites", kom je bij complexe zaken niet weg zonder javascript voor essentiele functionaliteit. Een goed voorbeeld is Gmail. Ja, ze hebben een basic versie van Gmail zonder Javascript, maar Gmail zou helemaal niks zijn als dat de enige versie was die ze aanboden. Voor de volledige versie is Javascript absoluut essentieel. En Google kent nog meer voorbeelden. Wat dacht je van de Google Docs functionaliteit: Spreadsheets, Tekstverwerker. Daar is javascript toch behoorlijk essentieel te noemen. jQuery is absoluut unobtrusive te gebruiken, maar hoewel dit een goede coding practice is, is het niet een keiharde vereiste. Het populaire jQueryUI bijvoorbeeld bevat een aantal dingen die niet kunnen degraden, zoals de dialogs. Het gebruik hiervan is niet per definitie altijd "fout".

Overigens is het gebruik van javascript heden ten dage zo ingeburgerd dat je niet meer fatsoenlijk kunt surfen als je het uitschakelt. Veel websites functioneren helemaal niet meer of "degraderen" op een dusdanige manier dat de site niet echt meer aantrekkelijk is om te gebruiken. Tegelijkertijd is er een trend dat mobiele apparaten en andere low-end browseroplossingen steeds meer capaciteiten krijgen. Elke moderne smartphone of MID heeft totaal geen problemen met javascript. Dat was een paar jaar geleden wel anders. Het webbrowser landschap verschuift. En javascript wordt langzaamaan gemeengoed.

Tuurlijk is toegankelijkheid niet altijd een belangrijk issue, maar de vraag is ook in hoeverre heb belangrijk is dat je een e-mailadres op de site hebt staan (als je deze vervolgens niet kunt selecteren bijvoorbeeld), of hoe erg het is dat een e-mailadres gespiderd wordt (gebruik dan bijvoorbeeld een speciaal web-inquiry adres bijvoorbeeld).

Zolang vrijwel alle grote sites e-mail adressen obfusceren, lijkt me er wel behoefte aan te zijn. Ik ben blij dat Tweakers mijn e-mail adres niet zomaar voor elke spam crawler beschikbaar maakt, ook al heb ik een hele goede spamfilter op mijn mailbox.

Wat ik dus zeg is dat je je in het beginsel al af moet vragen of het verminken van een adres wel de beste oplossing is, aangezien er genoeg andere mogelijkheden en belangen zijn.

En wat ik zeg is dat javascript om bepaalde redenen wél een oplossing kan zijn. Ook voor het obfusceren van een email adres. Een selecteerbaar en klikbaar mailadres is qua usability namelijk veel beter dan een plaatje of een "natuurlijke taal" constructie. En met een javascript oplossing kun je ook degraderen mocht je dat belangrijk vinden. Gewoon achter het javascript een <noscript> tag zetten met een image van het email adres. Dan kunnen 99.9% van je bezoekers profiteren van de oplossing die qua usability beter is en die paar die javascript niet kunnen of willen interpreteren zien alsnog het email adres.

[Bosmonster]

DexterDee schreef op donderdag 23 september 2010 @ 11:47:
[...]

Ik begrijp het concept toegankelijkheid niet verkeerd. Het is echter geen wetmatigheid om geen javascript te gebruiken om een toegankelijke website te maken. Evenals het geen wetmatigheid is om je website altijd W3C compliant te maken. Het zijn richtlijnen en standaarden die je helpen om een betere website te maken. Het gebruik van javascript vermindert in vrijwel alle gevallen de toegankelijkheid in meer of mindere mate, dat klopt. Maar het gaat mij te ver om onvoorwaardelijk te roepen dat javascript nooit onderdeel uit mag maken van het gebruik van een site. Standaarden en richtlijnen zijn geen vrijbrief om je gezonde verstand uit te schakelen. Als iets logischerwijs een non issue is, moet het niet tot issue verheven worden.

Je ziet toegankelijkheid als een soort werkwijze cq wetmatigheid lijkt het wel, terwijl het een doelstelling is. Om een website toegankelijk te houden dient deze te werken zonder javascript. Punt.

Dat dit niet altijd een noodzakelijkheid is, doet daar niet aan af. Als je je wilt houden aan de webrichtlijnen, wat voor veel klanten het geval is, dan dien je hier dus rekening mee te houden.

Totaal oneens. Natuurlijk moet je altijd streven naar graceful degradation, maar in de wereld van vandaag, waar we steeds meer praten over "web applicaties" in plaats van "web sites", kom je bij complexe zaken niet weg zonder javascript voor essentiele functionaliteit. Een goed voorbeeld is Gmail. Ja, ze hebben een basic versie van Gmail zonder Javascript, maar Gmail zou helemaal niks zijn als dat de enige versie was die ze aanboden. Voor de volledige versie is Javascript absoluut essentieel. En Google kent nog meer voorbeelden. Wat dacht je van de Google Docs functionaliteit: Spreadsheets, Tekstverwerker. Daar is javascript toch behoorlijk essentieel te noemen. jQuery is absoluut unobtrusive te gebruiken, maar hoewel dit een goede coding practice is, is het niet een keiharde vereiste. Het populaire jQueryUI bijvoorbeeld bevat een aantal dingen die niet kunnen degraden, zoals de dialogs. Het gebruik hiervan is niet per definitie altijd "fout".

Overigens is het gebruik van javascript heden ten dage zo ingeburgerd dat je niet meer fatsoenlijk kunt surfen als je het uitschakelt. Veel websites functioneren helemaal niet meer of "degraderen" op een dusdanige manier dat de site niet echt meer aantrekkelijk is om te gebruiken. Tegelijkertijd is er een trend dat mobiele apparaten en andere low-end browseroplossingen steeds meer capaciteiten krijgen. Elke moderne smartphone of MID heeft totaal geen problemen met javascript. Dat was een paar jaar geleden wel anders. Het webbrowser landschap verschuift. En javascript wordt langzaamaan gemeengoed.

Daarom ben ik ook geen voorstander van het verouderde graceful degradation, maar streef ik liever naar progressive enhancement.

Dat veel sites bagger gebouwd zijn en zonder javascript niks meer doen, maakt dat nog geen good practice natuurlijk. Dat zegt simpelweg dat er teveel prutsers aan het werk zijn die hun klanten opzadelen met baggerwerk.

Zolang vrijwel alle grote sites e-mail adressen obfusceren, lijkt me er wel behoefte aan te zijn. Ik ben blij dat Tweakers mijn e-mail adres niet zomaar voor elke spam crawler beschikbaar maakt, ook al heb ik een hele goede spamfilter op mijn mailbox.

Bekijk eens wat "grote sites". Je zult er bijna geen directe e-maillinks op vinden. Vanuit meerdere perspectieven is dit namelijk, juist voor grote bedrijven, helemaal geen interessante manier van communiceren.

En wat ik zeg is dat javascript om bepaalde redenen wél een oplossing kan zijn. Ook voor het obfusceren van een email adres. Een selecteerbaar en klikbaar mailadres is qua usability namelijk veel beter dan een plaatje of een "natuurlijke taal" constructie. En met een javascript oplossing kun je ook degraderen mocht je dat belangrijk vinden. Gewoon achter het javascript een <noscript> tag zetten met een image van het email adres. Dan kunnen 99.9% van je bezoekers profiteren van de oplossing die qua usability beter is en die paar die javascript niet kunnen of willen interpreteren zien alsnog het email adres.

Tuurlijk, maar hou er wel rekening mee dat deze oplossing dus niet voldoet aan de webrichtlijnen en dus niet toegestaan is voor veel ontwikkeltrajecten.


Maar afgezien van mijn geblaat over toegankelijkheid, is mijn belangrijkste argument nog steeds: Waarom je bezoeker opzadelen met jouw probleem? Laat het e-mailadres weg, of neem de spam voor lief. Je in allerlei bochten wringen om het toch aan te bieden lijkt me in beginsel al onwenselijk.

[ Voor 3% gewijzigd door Bosmonster op 23-09-2010 12:06 ]

[DexterDee]

Bosmonster schreef op donderdag 23 september 2010 @ 12:02:
Je ziet toegankelijkheid als een soort werkwijze cq wetmatigheid lijkt het wel, terwijl het een doelstelling is. Om een website toegankelijk te houden dient deze te werken zonder javascript. Punt.

Dat dit niet altijd een noodzakelijkheid is, doet daar niet aan af. Als je je wilt houden aan de webrichtlijnen, wat voor veel klanten het geval is, dan dien je hier dus rekening mee te houden.

Ik redeneer *juist* vanuit de doelstelling. En mijn punt wat je lijkt te missen (of aan voorbij gaat omdat je het hier stellig mee oneens bent) is dat je toegankelijkheid niet onlosmakelijk kunt verbinden aan het niet gebruiken van Javascript. Wat is namelijk de definitie van "toegankelijk"? Volgens mij kent toegankelijkheid een aantal functionele eisen die met technische hulpmiddelen gerealiseerd kunnen worden. De technische richtlijnen voor toegankelijkheid zijn vandaag de dag heel anders te interpreteren dan 5 of 10 jaar geleden. En dat komt omdat ons browserlandschap radicaal aan het veranderen is. Waar je vroeger een grote groep uitsloot met het gebruik van Javascript is dat vandaag de dag nog maar een heel erg kleine groep. Alles wat ik zeg is om hier slim mee om te gaan, in plaats van uiterst stellig te zeggen dat toegankelijkheid en Javascript nooit en te nimmer met elkaar samen gaan. Je zegt zelf, kijk naar de doelstelling. De doelstelling van een toegankelijke website is mijns inziens dat de website correct te bekijken is voor een zo groot mogelijke groep, onafhankelijk van de gebruikte technologie. Het feit dat vrijwel elke browser in elk device tegenwoordig Javascript ondersteunt, maakt het gebruik van Javascript steeds meer een non-issue.

Het wordt natuurlijk anders als de doelstelling van een klant is om aan de officiële richtlijnen te voldoen voor toegankelijkheid. Of dat de klant je verplicht om alles W3C gevalideerd op te leveren. In dit soort gevallen is er geen keus. En ergens is dat ook weer goed, omdat deze richtlijnen SMART opgezet zijn en dus makkelijk te controleren. En dat is wel zo handig voor de klant, omdat deze dan makkelijk kan zien of hieraan voldaan is.

Daarom ben ik ook geen voorstander van het verouderde graceful degradation, maar streef ik liever naar progressive enhancement.

Dat veel sites bagger gebouwd zijn en zonder javascript niks meer doen, maakt dat nog geen good practice natuurlijk. Dat zegt simpelweg dat er teveel prutsers aan het werk zijn die hun klanten opzadelen met baggerwerk.

Dat er teveel knutselaars zijn die prutswerk opleveren kan ik alleen maar beamen. Maar omgekeerd is het ook niet zo dat een goede website per definitie niet afhankelijk mag zijn van Javascript. Dat is evengoed te kort door de bocht. Ik ben ook voorstander van progressive enhancement, maar ik hanteer wel een duidelijke ondergrens. Zo ben ik gestopt met het ondersteunen van IE6 voor de meeste websites. Een logisch gevolg hiervan is dat ik 24-bit alpha PNG's gebruik die geen goede basis vormen voor progressive enhancement in IE6. Pas als in het voortraject blijkt dat er nog veel IE6 gebruikers zijn (bijv. in een corporate omgeving of gestaafd door web analytics van het bestaande verkeer) zal ik een stapje terug doen met het gebruiken van bepaalde moderne technieken.

Bekijk eens wat "grote sites". Je zult er bijna geen directe e-maillinks op vinden. Vanuit meerdere perspectieven is dit namelijk, juist voor grote bedrijven, helemaal geen interessante manier van communiceren.

Daar ben ik het mee eens, gezien de vraagstelling van de TS was dit echter een figuratief voorbeeld. Mijn relaas was echter bedoeld in een bredere context.

Maar afgezien van mijn geblaat over toegankelijkheid, is mijn belangrijkste argument nog steeds: Waarom je bezoeker opzadelen met jouw probleem? Laat het e-mailadres weg, of neem de spam voor lief. Je in allerlei bochten wringen om het toch aan te bieden lijkt me in beginsel al onwenselijk.

"jouw probleem" is wat kort door de bocht. Het is een gezamelijk probleem. En zoals met zoveel dingen, de "beste" oplossing is afhankelijk van veel variabelen. Er bestaat niet zoiets als de beste oplossing voor het tonen van alle mail adressen op alle websites.

[Bosmonster]

DexterDee schreef op donderdag 23 september 2010 @ 12:54:
[...]
Het feit dat vrijwel elke browser in elk device tegenwoordig Javascript ondersteunt, maakt het gebruik van Javascript steeds meer een non-issue.

Browsercompatibility != toegankelijkheid

Neem de webrichtlijnen eens door, want zo wordt het een beetje oneindige discussie

Of je je website wel of niet toegankelijk wilt hebben is het punt niet. Wat ik alleen zei is dat al de genoemde technieken niet toegankelijk zijn.

[ Voor 27% gewijzigd door Bosmonster op 23-09-2010 15:44 ]

[DexterDee]

Bosmonster schreef op donderdag 23 september 2010 @ 15:30:
Browsercompatibility != toegankelijkheid

Neem de webrichtlijnen eens door, want zo wordt het een beetje oneindige discussie

Er zijn zoveel versies van "webrichtlijnen" voor "toegankelijkheid". Welke bedoel je? De WCAG 2.0? Of misschien de MiBiZa Webrichtlijnen? Ik gok in jouw geval op het laatste. Waarschijnlijk maak jij dus websites voor de rijksoverheid, gemeenten of waterschappen.

In de nieuwe webrichtlijnen (v2.0 op dit moment in draft) lees ik dit:

# Interoperabiliteit

   1. Werkt in alle browsers
   2. Werkt op mobiel (aangepaste stylesheet, automatische herkenning mobiele opvraging, switch naar normale stylesheet aanwezig)
   3. Vereist geen specifieke software

Wat jouw statement "Browsercompatibility != toegankelijkheid" enigszins ontkracht. Browsercompatibility staat expliciet genoemd inclusief bijbehorende voorwaarden. Uiteraard is dit slechts één van de vele richtlijnen, maar het geeft wel een heel duidelijk standpunt weer.

Jij hangt je hele argumentatie op aan het netjes volgen van de webrichtlijnen. Alle individuele richtlijnen zijn goed en ik kan me er stuk voor stuk in vinden. Er is er geen één waar ik het niet mee eens ben. Ik ben echter van mening dat in specifieke omstandigheden bepaalde regels bijzonder weinig relevantie kennen of averechts werken (investering versus opbrengst). Derhalve is het voor mij persoonlijk onzinnig om hier ten alle tijden onvoorwaardelijk aan vast te houden (the law is the law). Mijn hele discussiepunt, waar jij zo sierlijk omheen draait, is om hier flexibel mee om te gaan en technologie in te zetten die past bij de situatie en omgevingsfactoren. Ook al breek je hier een regel mee. Als voorbeeld hiervoor gebruik ik de inzet van Javascript.

Jij gaat niet echt inhoudelijk in op dit kernpunt, maar probeert me meermaals met de webrichtlijnen om de oren te slaan. Dat komt een beetje belerend over op mij, wat ik erg jammer vind. De webrichtlijnen zijn mijns inziens van hoge kwaliteit en zeer nuttig, maar het is niet de heilige graal en de universele waarheid voor elke nieuw te bouwen webapplicatie onder elke omstandigheid. Anders is niet persé slechter, als er een goede argumentatie achter zit. Tenzij je opdrachtgever je verplicht stelt om aan de webrichtlijnen te voldoen uiteraard. Dan is het gewoon zaak om de richtlijnen tot op de letter op te volgen.

[Bosmonster]

Het enige dat ik zeg is dat toegankelijkheid over het algemeen betekent dat je website werkt zonder externe technieken als JS en plugins, en semantisch correct is opgebouwd (of eigenlijk dus ook CSS als externe techniek ziet) en nog andere zaken die er hier niet zo heel erg toe doen, zoals contrasten e.d. En daarnaast dat de technieken om een e-mailadres te verbergen voor de gebruiker hier dus niet aan voldoen. Een blinde kan een plaatje niet lezen, of voor laten lezen. Een screenreader zal de javascript niet parsen, etc.

Daarnaast zeg ik dat je je derhalve af moet vragen waarom je dergelijke technieken toe zou passen en kun je je beter focussen op het oplossen van het probleem (spam) of de vraag of je wel een e-mailadres op de website moet zetten vandaag de dag, of vanuit je communicatie-strategie.

Bovendien zijn mailto's ook al af te raden, doordat veel mensen incompatibele mailclients gebruiken, zoals webmail. Dan heeft zo'n mailto alleen maar frustratie tot gevolg als erop geklikt wordt.

Ik sla je niet om de oren met webrichtlijnen. Ik noemde alleen toegankelijkheid als belangrijk argument dit niet te gebruiken of niet mogen gebruiken. Ik denk graag iets dieper na over zaken dan alleen "e-mailadres levert spam op, hoe kunnen we het e-mailadres onzichtbaar maken voor spiders", om vervolgens een hele trucendoos open te trekken.

[ Voor 16% gewijzigd door Bosmonster op 23-09-2010 16:57 ]

[DexterDee]

Bosmonster schreef op donderdag 23 september 2010 @ 16:47:
Ik sla je niet om de oren met webrichtlijnen. Ik noemde alleen toegankelijkheid als belangrijk argument dit niet te gebruiken of niet mogen gebruiken. Ik denk graag iets dieper na over zaken dan alleen "e-mailadres levert spam op, hoe kunnen we het e-mailadres onzichtbaar maken voor spiders".

En ik ging inhoudelijk in op waarom dat in veel gevallen dus een non-issue is. Het feit dat ik over de gevolgen van deze keuze na denk, toont aan dat ik eveneens graag iets dieper nadenk dan over het probleem zelf. Als je mijn replies aandachtig had gelezen was je dat misschien al opgevallen.

Het enige dat ik zeg is dat toegankelijkheid over het algemeen betekent dat je website werkt zonder externe technieken als JS en plugins, en semantisch correct is opgebouwd (of eigenlijk dus ook CSS als externe techniek ziet) en nog andere zaken die er hier niet zo heel erg toe doen, zoals contrasten e.d. En daarnaast dat de technieken om een e-mailadres te verbergen voor de gebruiker hier dus niet aan voldoen. Een blinde kan een plaatje niet lezen, of voor laten lezen. Een screenreader zal de javascript niet parsen, etc.

Een screenreader is een mooi voorbeeld van waarom ik dit een non-issue vindt. Door met Javascript het correcte e-mail adres op de correcte plaats in de DOM te injecteren, zal een screenreader hier geen enkel probleem mee hebben. Een screenreader parsed namelijk niet een volledige HTML pagina, maar werkt op text elementen die (liefst semantisch correct) zijn geplaatst op de webpagina. Javascript is in dit geval slechts een hulpmiddel om de text in zo'n element te verfijnen. Zowel de screenreader van de Mac als onder windows hebben geen enkel probleem met het voorlezen van de email link.

Daarnaast zeg ik dat je je derhalve af moet vragen waarom je dergelijke technieken toe zou passen en kun je je beter focussen op het oplossen van het probleem (spam) of de vraag of je wel een e-mailadres op de website moet zetten vandaag de dag, of vanuit je communicatie-strategie.

Het probleem "spam" krijg je uiteraard niet zelf opgelost, behalve symptoombestrijding (spamfilters op je inbox). Natuurlijk bestaan er meerdere communicatie strategieën. En dit is er een van. Ik vind de voordelen (zeer effectief tegen spiders, javascript op vrijwel alle clients ondersteund, inline in de text, selecteerbaar, klikbaar) opwegen tegen de nadelen (niet semantisch correct, incompatible mailclients, geen javascript support bij een zeer beperkt aantal clients).

De webrichtlijnen zijn heel waardevol, maar staan wat mij betreft innovatie soms in de weg. Een website waarbij Javascript gebruikt wordt voor vitale onderdelen is in potentie krachtiger en interactiever. Hetzelfde geldt voor CSS3 en HTML5. Door hun sterk wisselende browserondersteuning is vaak onmogelijk om compliant te zijn met de webrichtlijnen. Voor sommige functionaliteit is er simpelweg geen alternatief in niet ondersteunde browsers (bijvoorbeeld de offline storage functionaliteit van HTML5) of is het alternatief zelf niet in lijn met de richtlijnen (HTML5 inline videos versus Flash videos). Om toch gebruik te kunnen maken van nieuwe technieken, zul je een aantal richtlijnen moeten schrappen of versoepelen. En als je dit met een beetje verstand doet, is er helemaal niks mis mee. Deze nieuwe technieken zullen ooit door het grote publiek geadopteerd moeten worden voor ze mainstream worden en ze in lijn komen met de webrichtlijnen.

[Bosmonster]

Denk het niet, maar het merendeel van de browsers ook niet Daar kun je wel een Javascript-fixje voor toevoegen natuurlijk.

Wel slim bedacht

Mini Poeper schreef op donderdag 23 september 2010 @ 20:39: Bovendien zijn dit richtlijnen en geen wettelijke bepalingen. Verder ben ik een n00b op dit gebied.

Afhankelijk van je klant zijn dit wel degelijk wettelijke bepalingen. Overheid en ook overheidsgesubsidieerde projecten dienen te voldoen aan deze richtlijnen.

Wil nog niet zeggen dat het altijd gebeurt, aangezien de controle minimaal is en veel software niet goed om kan gaan met goede code.

[ Voor 90% gewijzigd door Bosmonster op 24-09-2010 09:19 ]

[CMG]

Anoniem: 98590 schreef op donderdag 23 september 2010 @ 07:52:
http://www.alistapart.com/articles/gracefulemailobfuscation/

Wat een leuk artikel

W3Schools estimates that 6% of internet users have no access to JavaScript as of January 2007. As a comparison, if you believe that’s not enough to really care about, then maybe it’s time to reconsider why you strive to make your markup and CSS accommodate the 1.5% of IE 5.x users or the 1.3% of Safari users (again, W3Schools).

Dat vond ik echt wel een leuke quote

[DexterDee]

CMG schreef op vrijdag 24 september 2010 @ 09:45:

W3Schools estimates that 6% of internet users have no access to JavaScript
as of January 2007. As a comparison, if you believe that’s not enough to
really care about, then maybe it’s time to reconsider why you strive to
make your markup and CSS accommodate the 1.5% of IE 5.x users or the 1.3%
of Safari users (again, W3Schools).

Dat vond ik echt wel een leuke quote

Ik kan jammer genoeg nergens op internet een betrouwbare bron vinden hoe W3Schools aan dit nummer is gekomen. Op het eerste gezicht hebben ze hier natuurlijk een punt. Maar er wordt wellicht voorbij gegaan aan het feit dat de groep mensen die géén Javascript toegang hebben waarschijnlijk weinig tot geen overlap hebben op gebruikers van een typische site die Javascript (intensief) gebruikt. Een metafoor zou zijn dat iemand een auto heeft die niet hard genoeg kan om op de snelweg te rijden. Dat is pas een probleem als die persoon met die auto überhaupt op de snelweg *wil* rijden.
Verder kan ik dit nog opmerken over de getallen hierboven:[list]
• Januari 2007 is pre iPhone/Android en qua mobiel browsen staat alles nog erg in de kinderschoenen
• Het huidige marktaandeel Aug 2010 van Safari is 8.57% wereldwijd (Safari was in '07 nog niet beschikbaar onder windows en de iPhone was er nog niet)
• In december 2008 was het marktaandeel IE5 nog 0.3% en daarna verdwijnt het uit de statistieken.
• Het percentage "other" browsers in de statistieken van Aug 2010 is 0.39% en alle bekende browsers ondersteunen Javascript. Op z'n minst 99.61% heeft dus Javascript ondersteuning. Van alle "other" browsers heeft een deel wellicht ook nog Javascript ondersteuning, waardoor dit getal in de praktijk nog iets hoger uitkomt.

[MueR]

Even wat afgesplitst naar een apart topic

Over die cijfertjes die CMG in "Toegankelijkheid website*" noemt.. W3Schools zou ik nou niet als betrouwbare bron nemen, het is niet de meest up-to-date website zeg maar. Daarnaast zijn dit cijfers met een baard, een enorme baard zelfs.