CSS generated content

Bart Simons op 26/09/2014

CSS voor vormgeving, HTML voor inhoud, was altijd de mantra van goed webdesign en ook goed voor toegankelijkheid. Toch voegen we ook soms via CSS betekenisvolle inhoud toe aan een webpagina. Die kan je niet altijd toegankelijk maken dus de beste vuistregel blijft om CSS enkel voor layout te gebruiken en alle inhoud in de markup te plaatsen of desnoods via Javascript aan het DOM toe te voegen.

Afbeeldingen via CSS

De AnySurfer checklist bevat een ijkpunt over achtergrondafbeeldingen die informatie bevatten. Het eenvoudigst is om geen informatie in achtergrondafbeeldingen te stoppen, maar vaak gebeurt dit toch (sprites e.d.):

<a class="twitter" href="https://twitter.com/anysurfer"></a>
a.twitter:after { 
    content:url('icon_twitter.png'); 
}

De informatie in de achtergrondafbeelding gaat echter verloren voor screenreadergebruikers en er is geen manier om een alt-tekst toe te voegen aan achtergrondafbeeldingen. Wat overblijft is een lege, betekenisloze link. Daarom moet u vervangende tekst toevoegen.

<a class="twitter" href="https://twitter.com/anysurfer">
<span class="visuallyhidden">Twitter</span>
</a>
a.twitter:after { 
    content:url('icon_twitter.png'); 
}

.visuallyhidden { 
    border: 0; 
    clip: rect(0 0 0 0); 
    height: 1px; 
    margin: -1px; 
    overflow: hidden; 
    padding: 0; 
    position: absolute; 
    width: 1px;
}

Merk op dat we de afbeelding hebben ingevoegd met een :after pseudo-element. Als we zouden kiezen voor background url dan gaat de achtergrondafbeelding verloren als mensen een specifieke achtergrond instellen in hun browser of de hoog contrast versie van het besturingssysteem gebruiken. De afbeelding valt dan weg en de vervangende tekst die we hebben toegevoegd voor screenreaders komt daarbij niet tevoorschijn. De afbeeldingen die zijn ingevoegd met :before en :after blijven beschikbaar als de pagina met hoog contrast wordt bekeken.

Tekst via CSS

Met de CSS :before en :after pseudo-elementen kan je niet enkel afbeeldingen maar ook tekst toevoegen aan een webpagina. Hier geldt hetzelfde als voor de achtergrondafbeeldingen: prima voor decoratieve elementen zoals scheidingsstreepjes in een horizontaal menu maar gebruik het niet om tekst of andere informatie toe te voegen zoals in dit voorbeeld (tekst ingevoegd via :after).

De via CSS toegevoegde inhoud wordt geen deel van het DOM en is daarom niet beschikbaar voor screenreaders. Uit onze tests blijkt dat bijna alle browsers het wel doorgeven maar Internet Explorer doet het niet. Als we zouden vragen om net als bij achtergrondafbeeldingen verborgen tekst toe te voegen, dan zou dit het probleem oplossen voor Internet Explorer, maar het zou in alle andere browsers betekenen dat de screenreader dubbele informatie leest.

Daarom is het beter de inhoud in de HTML-pagina te zetten en niet in de CSS. Een andere mogelijkheid is de informatie via jQuery toe te voegen. In dit voorbeeld (tekst toegevoegd via jQuery) voegen we een PDF-melding toe aan alle links naar PDF-bestanden zonder iets te wijzigen aan de markup.

<script>
	$('a[href$=".pdf"]').each(function(){
	    $(this).append(' (PDF)');
	});
</script>

Icon fonts

Icon fonts zijn een ingewikkelder geval: een karakter wordt ingevoegd (meestal via de CSS :before en :after pseudo-elementen zoals hierboven) maar de visuele betekenis wijkt vaak af van wat een screenreader normaal zou uitspreken voor dat karakter. U moet dus:

  • vervangende tekst voorzien zoals voor een achtergrondafbeelding,
  • er tegelijk voor zorgen dat het karakter zelf niet wordt voorgelezen. Dit kan op twee manieren:
    • Kies unicode karakters uit de private use area. Screenreaders hebben geen uitspraakregels voor deze karakters.
    • Als u leesbare karakters gebruikt, verberg ze dan met aria-hidden="true".

Toegankelijkheid van icon fonts bespreken we uitgebreider in een apart artikel.

Conclusie

Karl Groves vat het met deze titel helemaal samen: CSS generated content is not content: als iets informatie is, voeg het dan niet in via CSS. Als iets decoratief is, voeg het dan in via CSS.

Reageer als eerste

Toegankelijke iBooks maken

Bart Simons op 04/09/2014

Niet alleen websites maar ook digitale documenten moeten toegankelijk zijn voor iedereen. De principes zijn voor alle bestandsformaten gelijk, maar de technieken om het doel te bereiken zijn in elk programma verschillend. Onze collega's van de Blind-d-mobiel schreven deze technieken uit voor het programma iBooks Author, de software waarmee je iBooks maakt.

Wat zijn iBooks?

iBooks zijn Apple's interpretatie van de ePub-standaard voor digitale boeken. De eerste versie van iBooks dateert uit april 2010 en was toen volledig conform die standaard. Bij de lancering van iBooks 2 in januari 2012 voegde Apple echter een aantal elementen toe aan het iBooksformaat die niet voorzien zijn in de ePub-standaard. Daardoor kan een iBook nu veel meer interactieve elementen bevatten, maar voldoet het niet langer aan de ePub-standaard.

Een iBook kun je lezen met de app "iBooks" die beschikbaar is voor:

  • iOS (iPhone, iPad, iPod touch) en deze app werkt prima met de spraak- en vergrotingsfuncties van deze toestellen
  • en voor Mac OS X (voor Mac-computers) maar helaas is de app hier niet zo toegankelijk voor VoiceOver-gebruikers.

Hoe maak je een toegankelijk iBook?

Pictogram van de app iBooks Author

iBooks maak je met iBooks Author, een gratis app, maar enkel beschikbaar voor Mac computers. Apple biedt met zijn iBooks Store een onlinewinkel aan waarin je iBooks te koop kunt aanbieden. Maar je kunt je iBooks ook gewoon aanbieden op je eigen website.

Bij het maken van het boek moet je met een aantal zaken rekening houden zodat het eindresultaat een toegankelijk iBook wordt. Deze technieken zijn beschreven in een ADOD-document. ADOD staat voor Accessible Digital Office Documents. Voor websites is er de AnySurfer checklist, voor allerlei andere bestandsformaten zijn er de ADOD-handleidingen. In de ADOD-reeks zijn er handleidingen met toegankelijkheidstechnieken voor allerlei programma's. Aan die reeks zijn nu de technieken voor het produceren van toegankelijke iBooks toegevoegd. Het document is geschreven voor wie iBooks Author versie 2 gebruikt. Het document is ook in het Engels beschikbaar.

Dit werk hebben we gepresenteerd in Parijs tijdens de conferentie eBooks for everyone! An opportunity for more inclusive libraries. Op de conferentie-website zijn de paper en slides beschikbaar.

Reageer als eerste

jQuery UI Dialog

Bart De Clercq op 29/07/2014

jQuery UI laat toe om op een eenvoudige manier een dialoogvenster te openen. Hier kan een melding instaan met of zonder buttons, een volledig fomulier of nog andere content.

Screenshot jQuery UI Dialog

De standaard dialog geeft echter wat problemen voor toetsenbordgebruikers en screenreader gebruikers. Een dialog wordt, net zoals een lightbox, geïnjecteerd in de broncode en komt via CSS 'over' je pagina heen te staan.

  • Bij openen van de dialog, wordt de focus niet voor iedereen naar de dialog gebracht.
  • Bij tabben kan je uit de dialog geraken maar er niet meer in.
  • Als screenreader gebruiker tab je niet en kan je met je pijltjes buiten de dialog geraken.

Door enkele opties te configureren die standaard in de code bibliotheek zitten, wordt de dialog zo goed mogelijk bruikbaar voor iedereen.

modal

We zetten modal="true" zodat andere elementen in de pagina niet meer bereikbaar zijn met het toetsenbord. Je creëert als het ware een keyboard trap die ervoor zorgt dat je in de dialog blijft.

Sommige screenreader gebruikers geraken echter wel uit de dialog. Afhankelijk van de screenreader software, tab je niet door de pagina maar gebruik je pijltjes om door de pagina heen te gaan. Dit wordt niet opgevangen door de JavaScript. Dit is echter geen ramp. Als de focus verplaatst wordt naar de dialog, heeft de gebruiker de boodschap gelezen en kan hij ook terug gaan om bijvoorbeeld de Ok button te gebruiken die in het button paneel zit.

Focusbaar element

Het is heel belangrijk dat de focus verplaatst wordt naar de dialog als de gebruiker in de pagina op een link klikt of een andere actie onderneemt waardoor een dialog geopend wordt. Een blinde of slechtziende gebruiker kan denken dat een link niet werkt omdat er op het eerste zicht niets gebeurd. Een slechtziende gebruiker met vergrotingssoftware, kan het venster miscchien niet zien. Gelukkig zit het verplaatsen van de focus standaard in jQuery UI.

aria-hidden

ARIA is een techniek specifiek voor screenreader gebruikers. Het geeft hen meer informatie over elementen. In deze context is het nuttig om aria-hidden te gebruiken.

Aria-hidden is een booleaanse waarde. Aria-hidden true wil zeggen dat een element onzichtbaar is voor een screenreader gebruiker. Aria-hidden false maakt het zichtbaar.

Door de content (hier een div met id="wrap") op true te zetten, wordt de inhoud onzichtbaar. De dialog zelf plaatsen we achteraf op aria-hidden false zodat de dialog zelf niet onzichtbaar blijft. Wat we niet mogen vergeten, is bij het sluiten deze waarden om te draaien: de content wordt opnieuw zichtbaar en de dialog mag verdwijnen.

Code voorbeeld

Onderstaande code staat online in een voorbeeld.

<a href="#" id="opener">Open het dialoogvenster.</a>
<div id="dialog">
  <!-- autofocus zorgt dat jQuery UI de focus naar dit element brengt
       tabindex -1 zorgt ervoor dat de h1 focusbaar is -->
  <h1 autofocus tabindex="-1" >Dialog title</h1>
  <p>Dialog content.</p>
</div>
$("#dialog").dialog( {
  // de dialog wordt niet getoond bij laden van de pagina
  autoOpen : false,
  // hij kan niet versleept worden
  draggable: false,
  // we voegen een sluit button toe
  buttons: {
    Close: function() {
      $( this ).dialog( "close" );
    }
  },
  open: function() {
    // we willen geen title venster met sluit button
    $(".ui-dialog-titlebar").hide();
    // content mag verborgen zijn voor screenreader gebruikers
    $("#wrap").attr("aria-hidden", "true");
    // de dialog zelf natuurlijk niet
    $(".ui-dialog").attr("aria-hidden", "false");
  },
  close: function() {
    // bij het sluiten moet de content opnieuw zichtbaar zijn
    $("#wrap").attr("aria-hidden", "false");
    // de dialog mag volledig onzichtbaar zijn
    $(".ui-dialog").attr("aria-hidden", "true");
  },
  // we zorgen voor de keyboard trap
  modal: true
});
// de link met id opener, opent de dialog
$("#opener").click(function(e) {
  // de pagina scrollt niet tot boven bij het openen van de link
  e.preventDefault();
  $("#dialog").dialog("open");
});

Besluit

jQuery UI Dialog is mits enkele kleine aanpassingen goed bruikbaar voor zoveel mogelijk gebruikers. Een screenreader zoals Supernova, is hier een uitzondering en heeft wel problemen met het verplaatsen van de focus en blijft in ons voorbeeld op de openen link.

Een muisgebruiker kan bij een dialog, niet meer interageren met andere elementen op de pagina. Idealiter is dit voor een toestenbord gebruiker en/of screenreadergebruiker exact hetzelfde.

Een mooi voorbeeld is online banking. Als je een melding krijgt dat je sessie zal verlopen, wil je dat de gebruiker niets anders kan dan op Ok klikken in de dialog om zijn sessie te verlengen. Dit moet voor een muisgebruiker en toetsenbord gebruiker hetzelfde zijn. Door de eerder getoonde configuratie van de jQuery UI Dialog, bereiken we dit resultaat:

Openen dialog

  • Verplaatsen van de focus in de dialog.
  • Aria-hidden toepassen op de content (true) en dialog (false).

Sluiten dialog

  • Verplaatsen van de focus naar de content.
  • Aria-hidden omwisselen: content (false) en dialog (true).

Reageer als eerste

JavaScript OnClick? Gebruik dan a of button.

Bart De Clercq op 25/06/2014

Meer en meer komen we elementen tegen die aanklikbaar zijn maar die geen toetsenbord focus verwerven. Ziende toetsenbord gebruikers kunnen er niet naartoe tabben, blinde screenreader gebruikers weten niet dat er iets interactief is of nog andere gebruikers kunnen geen commando geven aan hun spraaksoftware.

Deze elementen linken niet naar een pagina maar veroorzaken een paginawijziging aan de hand van JavaScript.

Enkele voorbeelden:

  • Een hamburger menu om de navigatie te tonen in een responsive website:
    <span onclick="...">Toggle navigation</span>
  • Sluitknop, vorige en volgende knoppen in een lightbox:
    <div onclick="...">Sluiten</div>
  • Links in facetnavigatie om zoekresultaten te filteren:
    <li onclick="...">Tussen 1200W en 1500W</li>
  • Sorteren van tabellen aan de hand van de th elementen:
    <th onclick="...">Datum</th>
  • Items uit je winkelwagentje verwijderen:
    <img onclick="..." alt="Verwijder item" />

<div>, <span>, <th>, … elementen die interactief gemaakt zijn, zijn bijna nooit toetsenbord toegankelijk. Als je dat wel wilt, moet je veel moeite doen met tabindex, ARIA en/of extra JavaScript om deze elementen toch focusbaar te maken en bruikbaar te maken voor elk type gebruiker.

De oplossing is relatief eenvoudig. Gebruik altijd een link of button waar je je JavaScript aan koppelt. Een link of button komt altijd in de tab flow en krijgt altijd toetsenbord focus. Werk je met JavaScript en link je niet naar een pagina? Dan zijn er enkele manieren om dit te doen, we werken met heel simpele JavaScript code die een alert toont om onze code voorbeelden beknopt te houden.

a href="#"

In deze eerste manier staat de JavaScript code onClick als attribuut bij de link.

<a href="#" onclick="alert('Code voorbeeld 1');">
  Voorbeeld 1
</a>
Voorbeeld 1

Event Listener

Bij een listener kan je makkelijk je code scheiden van je element. Je JavaScript code kan in je HTML staan of in een apart JavaScript bestand staan.

We gebruiken jQuery om de event listener te koppelen aan de link met id="link2".

<a href="#" id="link2">
  Voorbeeld 2
</a>
<script>
  $("#link2").click(function() {
    alert('Code voorbeeld 2');
  });
</script>
Voorbeeld 2

In href

Hier maak je geen gebruik van een listener of OnClick maar staat de code in het href attribuut.

<a href="javascript:alert('Code voorbeeld 3');">
  Voorbeeld 3
</a>
Voorbeeld 3

Advies

Naar toegankelijkheid toe is elke manier mogelijk, kies er diegene uit die het best bij je workflow past.

Gebruik geen of niet alleen onMouseOver, onMouseOut, onKeyDown, onKeyUp en onDblClick aangezien die niet voor elke gebruiker kunnen werken. OnClick doet dat wel, gebruik onClick zoals in één van onze drie voorbeelden.

Reageer als eerste

5 redenen waarom toegankelijkheid een plaats verdient in uw communicatiestrategie

Gijs Veyfeyken op 30/04/2014

Deze tekst is geschreven als gastblogpost voor Toecomst, Logboek van het project Visie en strategie Vlaamse overheidscommunicatie 2014-2020

1. Omdat Europa het verplicht

Er zit nieuwe Europese wetgeving in de pijplijn die de toegankelijkheid van overheidsinformatie en diensten op het web, e-government, verplicht onder de lidstaten. Europa hanteert de Web Content Accessibitily Guidelines (WCAG) als norm. Deze internationaal erkende ISO-standaard bevat 3 niveau’s van toegankelijkheid.

  • WCAG level A: basisniveau, de norm om het AnySurfer label te behalen.
  • WCAG level AA: gemiddeld niveau, de norm die Europa oplegt
  • WCAG level AAA: strengste niveau, in de praktijk nauwelijks haalbaar

Meer info over wetten en standaarden.

Bekijk de toespraak van Neelie Kroes van de Europese Commissie op Youtube: Making the web accessible for people with a disability.

2. Omdat 15% van de Vlamingen een beperking heeft

  • mensen met een motorische handicap, die het moeilijk hebben met een muis of toetsenbord
  • blinden, die spraaksoftware gebruiken om naar een website te luisteren
  • slechtzienden, die vergroting gebruiken en nood hebben aan hoge contrasten
  • slechthorenden, waarvoor ondertiteling essentieel is.
  • doven, bij wie gebarentaal de moedertaal is en het Nederlands een vreemde taal is.
  • dyslectici, personen met een concentratiestoornis of andere cognitieve stoornissen.

Vergeet de vergrijzing van de bevolking niet. Dit cijfer zal enkel stijgen.

3. Omdat 15% van de Vlamingen de taal van de overheid niet spreekt

“In Vlaanderen is 15% van de volwassenen laaggeletterd. Dit betekent dat meer dan een half miljoen Vlamingen (580.470) kampt met een duidelijk geletterdheidsprobleem.”

Bron Vakgroep Onderwijskunde Universiteit Gent

Het gemiddeld taalniveau ligt op B1 of B2 van het Europees referentiekader. Het merendeel van overheidscommunicatie is geschreven op niveau C1, te moeilijk voor het grootste deel van de bevolking.

Iedereen leest graag klare taal.

4. Omdat vanaf het begin rekening houden met toegankelijkheid, tijd, moeite en middelen bespaart

Vergelijk het met het bouwen van een huis. Als de architect rekening houdt met toegankelijkheid in het ontwerp, blijft de meerkost beperkt en is het huis bij oplevering meteen bruikbaar. Wanneer toegankelijkheid pas achteraf ter sprake komt, zijn verbouwingen noodzakelijk. Dit kost nodeloos tijd, geld en moeite.

  • Kies voor een erkende webbouwer met bewezen ervaring en expertise
  • Neem toegankelijkheid op als vereiste in de aanbesteding van nieuwe websites en controleer bij oplevering

5. Omdat Google en mobiele gebruikers steeds belangrijker worden

  • Search Engine Optimisation (SEO): Google is blind en leest uw website op gelijkaardige wijze als een blinde met een screenreader dat doet. Toegankelijkheidsrichtlijnen helpen u beter scoren in Google.
  • Mobile: mobiele gebruikers zijn ook “gehandicapt”. Ze kunnen geen muisfuncties uitvoeren en lezen op een klein scherm, vaak in een omgeving met zonlicht, waardoor hoge contrasten wenselijk zijn.

Hoe staat de Vlaamse overheid er momenteel voor?

AnySurfer onderzoekt jaarlijks de toegankelijkheid van het Belgische internetlandschap. Daarbij wordt ook een steekproef van Vlaamse overheidssites gescreend op vraag van de dienst Emancipatiezaken.

  • 14% van Belgische websites voldoet aan minimale toegankelijkheidsvereisten
  • 64% van Vlaamse overheidswebsites

Opgelet, dat wil niet zeggen dat 64% van de Vlaamse overheid voldoet aan de norm die Europa oplegt (WCAG level AA). Slechts 11% draagt het AnySurfer label (= WCAG level A). Het aantal websites dat voldoet aan WCAG level AA zal nog lager liggen.

Wat zijn de grootste uitdagingen?

  • Bewustwording: op vlak van fysieke toegankelijkheid, bijvoorbeeld van openbare gebouwen, is er een maatschappelijk draagvlak. Het is een evidentie. Bij digitale toegankelijkheid is dat nauwelijks het geval.
  • Word en PDF: er worden anno 2014 nog steeds massaal ontoegankelijke documenten online gezet om te communiceren met de burger. 90% van die documenten zouden beter als webpagina’s gepubliceerd worden. Dat is voor iedereen toegankelijker en gebruiksvriendelijker. Hetzelfde geldt voor interactie met de burger: formulieren.
1 reactie