iframes: het paard van Troje & Webrichtlijnen

Een van de drie succescriteria die in het Toepassingskader als complex worden aangemerkt is succescriteria U7.1: het gebruik van ‘geneste weergavekaders’. Dat blijkt voor verwarring te zorgen. In technisch opzicht is het namelijk heel eenvoudig om een iframe te plaatsen conform de eisen. Het gaat echter om de inhoud van het iframe wat het tot een complex succescriterium maakt.

Een iframe is te vergelijken met het paard van Troje. Wikipedia zegt daarover: “Het staat voor een gewenste zaak die ergens wordt binnengehaald, waarin een ongewenste lading is verborgen. De ontvangers bewerkstelligen argeloos hun eigen ondergang”. Buiten de mythologie is het allemaal wat minder apocalyptisch, maar het gebruik van iframes in combinatie met Webrichtlijnen zorgt wel degelijk voor problemen, en kent een aantal grootsche mythes.

Mythes

De ontvangers bewerkstelligen argeloos hun eigen ondergang.

De best verspreide mythe rondom iframes is dat het een manier zou zijn om bepaalde content buiten de scope van de webrichtlijnen te houden. Dat zou natuurlijk hilarisch zijn, maar bij die conclusie worden 3 foutieve keuzes gemaakt:

  1. Waarom zou je op die manier je gebruikers voor de gek houden? Op welke manier help je de bezoeker met het inladen van externe informatie in een deel van de pagina dat slecht wordt ondersteund door mobiele browsers (weliswaar steeds beter), laat staan wanneer de inhoud van die pagina ook nog eens slecht bruikbaar is voor mensen met een beperking.
  2. Ook al plaats je bijvoorbeeld een video op YouTube; jij bent eigenaar van die content, en zodra je het plaatst op je website — al dan niet met behulp van een iframe — moet de video alsnog zijn ondertiteld en indien relevant worden voorzien van audiodescriptie.
  3. Waarom kies je überhaupt voor een contentvorm die blijkbaar ontoegankelijk is? Is het niet beter gewoon een tekstalternatief te maken en dat te gebruiken, in plaats van al deze poespas?

Mocht je dan ondanks deze argumenten, afwegingen en suggesties alsnog besluiten om dat iframe te gebruiken, en als je dan de moeite neemt om de inhoud op toegankelijke wijze te plaatsen, dan is het inderdaad erg eenvoudig om te voldoen aan succescriterium U7.1. Het normdocument beschrijft 3 oplossingen om aan het succescriterium te voldoen:

  • Door geen iframe te gebruiken. Echt waar? Ja, echt waar. Goede suggestie!
  • Door een iframe te gebruiken waarbij de inhoud van het iframe exact gelijk is aan de inhoud van de pagina die wordt ingesloten. Ik heb persoonlijk nooit helemaal begrepen wat hiermee wordt bedoeld.
  • De meest gangbare oplossing; je gebruikt een iframe, waarbij je naast het iframe een link plaatst naar diezelfde content. De vraag die dan vaak volgt is; moet de link vóór of ná het iframe worden geplaatst. Dat maakt natuurlijk geen donder uit, het gaat erom dat als het iframe niet wordt getoond of niet wordt opgelezen door een screenreader je in ieder geval de link kunt gebruiken. Hierbij zijn twee zaken belangrijk; een title-attribuut op het iframe, en een link voor of na het iframe.

Ergo;

<iframe title="Video op Youtube over het aankomende muziekfestival" src="http://goo.gl/I30AdZ">
</iframe>

<a href=”http://goo.gl/I30AdZ”>Video over het komende festival op YouTube</a>

Absoluut geen rocket-science. Maarja, die verdraaide inhoud dan, hè.

Hoe om te gaan met de inhoud van iframes

Er zijn vaak een aantal redenen waarom mensen besluiten ofwel informatie buiten de website te plaatsen ofwel informatie van derden te gebruiken op de eigen website. Hieronder een lijst van de diverse voorbeelden, en de bijbehorende argumenten.

  • Diensten van derden: Op het moment dat je een dienst van derden afneemt is het van groot belang af te dwingen dat de betreffende content voldoet aan Webrichtlijnen versie 2 Niveau AA. Dat is verantwoordelijkheid van de organisatie de content inlaadt, ook als dit middels een iframe gebeurt.
    • Kaartmateriaal – Voor geografisch materiaal geldt dat op dit moment geen goede oplossing wordt geboden om dit conform Webrichtlijnen te plaatsen. Daarmee valt kaartmateriaal onder het ‘Pas toe of leg uit’-principe. Dat neemt niet weg dat er iets anders aan ten grondslag ligt, namelijk: is een kaart wel de beste manier om geografische informatie weer te geven. Een voorbeeld: Als je op de kaart 3 locaties zou willen aangeven met een marker, dan is het eenvoudiger om een lijst met de drie adressen weer te geven, dan om een ontoegankelijke kaart in te voegen. Voor dergelijke situaties geldt dat je beter de complexe vorm kunt vermijden, dan dat je terugvalt op het ‘pas toe of leg uit’-principe, omdat je het niet toegankelijk kunt aanbieden.
    • Videomateriaal – Voor videomateriaal is mijn simpele oplossing, de video op YouTube te plaatsen, aldaar te voorzien van ondertiteling, en die video te embedden op de pagina, voorzien van een link naar de YouTube pagina. Op die manier vermijd je organisatorische problemen, voorkom je serverkosten en licensiekosten voor een videoplayer, en bovendien maakt YouTube het gemakkelijk de video toegankelijk aan te bieden. Helaas is audio-descriptie nog wel een problematisch geval. Audiodescriptie is echter alleen verplicht indien relevant voor de eindgebruiker, dus is het ook in deze gevallen belangrijk complexiteit te vermijden.
    • Externe applicaties – Voor externe applicaties die niet anders dan met een iframe kunnen worden ingeladen geldt ten zeerste de aanbeveling om toegankelijkheid af te dwingen. Mocht dat om welke reden dan ook niet mogelijk zijn, dan moet worden overwogen of de informatie van de dienst niet via een zogenaamde webservice API kan worden aangeboden. Op die manier is er volledige regie mogelijk over de vorm waarin de informatie wordt getoond, en is ook niet langer een iframe nodig.
  • Sociale media – Het invoegen van sociale media op de eigen website valt op dit moment eveneens onder het ‘pas toe of leg uit’-principe. Dat heeft te maken met de standaard toepassingen voor bijvoorbeeld Twitter, Facebook Comments of comments bijgehouden met behulp van Discus. In het geval van Facebook Comments is er bijvoorbeeld geen fysieke pagina is waarnaar kan worden verwezen. Anders gezegd; er is geen URL beschikbaar met alleen de comments voor die specifieke pagina. Voor de meeste Twitter widgets geldt dat ze niet toegankelijk zijn opgebouwd. Gelukkig zijn er wel manieren om Twitter berichten op te slaan in het CMS, en die vervolgens op toegankelijke wijze te tonen. Kort gezegd is het in ieder geval geen proces zonder pijn en moeite in de meeste gevallen. Er moet dus goed worden afgewogen welke keuzes moeten worden gemaakt. Voor social media gaat het ‘pas toe of leg uit’-principe niet op bij gebruik van ontoegankelijke bronnen, omdat er toegankelijke alternatieven mogelijk zijn.

Conclusie

Het is kortom zo eenvoudig nog niet, die verdraaide iframes. Gelukkig merk je wel steeds meer begrip vanuit grote organisaties voor de toegankelijkheidseisen, en is er steeds meer pressie vanuit de overheid om bij ontoegankelijke diensten ook de leveranciers aan te spreken.

Anderzijds zie je ook regelmatig beleidsmatige keuzes voor ‘sexy content’ uitmonden in ontoegankelijke oplossingen, simpelweg doordat er te veel aandacht wordt besteed aan de verkeerde zaken. Blijf daarom bewust omgaan met externe bronnen en complexe content, en daag je eigen organisatie of de leverancier uit sexy én toegankelijke content te ontwikkelen. Succes!

Dit artikel is ontstaan uit een overpeinzing met Raph de Rooij, waarvoor dank!

2 gedachten over “iframes: het paard van Troje & Webrichtlijnen”

  1. Lekker duidelijk artikel, Jeroen. Bedankt. Ik zie alleen niet het probleem van een iframe. Bij het succercriterium staat “Het is mogelijk dat een user agent niet of onvoldoende kan omgaan met content die in een geneste context wordt aangeboden. De toegang tot deze content moet altijd gewaarborgd zijn.”. Ik lees echter nergens dat dat nog zo zou zijn. Op WebAIM staat bijvoorbeeld “There are no distinct accessibility issues with inline frames. The content of the inline frame is read at the point it is encountered (based on markup order) as if it were content within the parent page.”(zie http://webaim.org/techniques/frames/).

  2. Helemaal eens, Jaap. Er is geen reden waarom je geen iframe meer zou gebruiken, behalve dat de manier waarop veel mensen het nog gebruiken fout is. Dat het namelijk een externe site is betekent niet dat je niet verantwoordelijk bent voor de inhoud, zeker wanneer je het onderdeel maakt van je website. Toch? :)

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Verplichte velden zijn gemarkeerd met *