Welk lettertype is het best leesbaar?

Bart Simons op 25/11/2014

Er bestaan lettertypes die beweren dat ze beter leesbaar zijn voor slechtzienden en andere zijn speciaal ontworpen voor mensen met dyslexie.

paragraaf in Dyslexie font

Goed bedoeld en sommige mensen zullen er zeker blij mee zijn, maar moet je nu knoppen op je site plaatsen die bezoekers toelaten van lettertype te veranderen?

Er zijn artikels die een specifiek lettertype aanraden en andere die zeggen dat ze wetenschappelijk gezien geen verschil maken. Je wil natuurlijk een site maken die er voor zoveel mogelijk mensen aantrekkelijk uitziet. De tevredenheid van je bezoekers is belangrijker dan de vraag of het wetenschappelijk gezien werkt of niet. Hier kan ook een soort placebo-effect werken: dit lettertype is speciaal voor mij dus ik lees er beter mee.

De ene vorm van slechtziendheid is de andere niet en niet alle mensen met dyslexie lezen op dezelfde manier. Ons standpunt is dan ook dat je niet voor iedereen goed kunt doen. Als alle websites een style switcher implementeren op een verschillende manier, helpt dat de bezoeker ook niet om er vlot mee te werken.

Onze adviezen voor grafisch ontwerpers:

serif en sans-serif lettertype

  • Geef de doorlopende tekst een goed leesbaar en schreefloos lettertype (geen handschrift).
  • Maak de letters niet te klein: standaard browsertekst is 16 pixels; ga daar niet te ver onder.
  • Zorg voor voldoende witruimte, regelafstand en ruimte tussen letters.
  • Maak de tekstregels niet te lang. Beperk ze bijvoorbeeld tot een zestigtal karakters.
  • Zorg voor voldoende contrast tussen de tekst en de achtergrond (technische norm is 4,5:1). Kies voor een rustige achtergrond: geen video, bewegend beeld of een groot kleurverloop.
  • Bouw de website volgens de standaarden en test met de standaardtools van besturingssystemen en browsers zoals de hoog contrast weergave van Windows.

Bezoekers kunnen letters vergroten/verkleinen in elk besturingssysteem en elke browser. De website moet dus zelf geen knoppen voorzien om de letters te vergroten. Overschrijven van lettertypes is voor bezoekers veel minder evident. Je website kan dus een style switcher aanbieden maar het blijft moeilijk om daarmee voor iedereen goed te doen. Niet alle slechtzienden zullen deze versie voor slechtzienden even mooi vinden en je kan ook overdrijven met keuzemogelijkheden.

1 reactie

CSS Clip versus Clip-path

Bart De Clercq op 28/10/2014

Clip en Clip-path zijn twee CSS eigenschappen die je op elementen kan toepassen. Er zijn verschillende doeleinden om Clip of Clip-path toe te passen. Hoofdzakelijk wil je een deel van een element tonen.

Aangezien Clip ontmoedigd wordt door het W3C (deprecated) bekijken we het voorgestelde alternatief Clip-path. In deze blogpost verdiepen we ons in de verschillen en wat ze met toegankelijkheid te maken hebben.

Clip

De CSS Clip eigenschap laat toe een gedeelte van een element te tonen. Je kan een rechthoek definiëren door vier coördinaten te gebruiken. Meestal wordt deze techniek op afbeeldingen toegepast.

Er zijn voor- en nadelen aan deze eigenschap. Zo moet het element absoluut gepositioneerd staan wat meestal een heel groot nadeel is.

Het volledige logo

We starten met afbeelding zonder Clip of Clip-path, namelijk ons logo.

Het AnySurfer logo met baseline
<img src="../logo_baseline_nl_307x70.png" alt="Het AnySurfer logo met baseline" />

Een deel van het logo

Stel dat we de tekst willen afknippen van onze afbeelding, dan kunnen we Clip gebruiken om de CSS Sprite techniek toe te passen. We gebruiken hetzelfde brondbestand maar tonen alleen het logo.

Het AnySurfer logo zonder baseline
<img src="../logo_baseline_nl_307x70.png" alt="Het AnySurfer logo zonder baseline" />

We selecteren een gedeelte van de afbeelding:

img{
  position: absolute; 
  clip: rect(0px 75px 70px 0px);		
}

Clip-path

Bij Clip ben je beperkt tot een rechthoek. Met Clip-path kan je gebruik maken van een SVG mask of enkele beschikbare CSS basisvormen (rectangle, circle, ellipse of polygon).

Een deel van het logo met SVG circle

Naast de CSS shapes kan je ook verwijzen naar een SVG waarin een SVG shape gedefinieerd is. In volgend voorbeeld linken we een SVG circle aan ons logo.

Deel van het logo met clip-path SVG circle

Als je hierboven niets of ons volledig logo ziet, dan ondersteund je browser SVG circle mask nog niet. Hieronder een screenshot wat je moet zien:

Screenshot SVG circle mask

<img 
  class="orange" 
  src="../logo_baseline_nl_307x70.png" alt="Deel van het logo met clip-path SVG circle" 
/>

De SVG bestaat uit een cirkel met coördinaten x en y plus de grootte van de radius.

<svg width="0px" height="0px">
  <defs>
    <clipPath id="clipping">
      <circle cx="37" cy="34" r="23" />
    </clipPath>
  </defs>
</svg>

In de CSS code wordt verwezen naar een SVG element met id="clipping".

.orange { 
  clip-path: url(#clipping);
}

Hieronder een schets welke SVG we maken. Het middelpunt zit op coördinaat 37px, 34px met een radius van 23px.

Schets SVG op het logo

En wat met toegankelijkheid?

Soms wil je tekst alleen beschikbaar maken voor screenreader gebruikers. Dit kan je doen door de Clip methode te gebruiken, meer lees je hierover op onze pagina Verborgen tekst, enkel voor screenreaders.

Omdat de Clip eigenschap vervangen wordt door de Clip-path eigenschap, is de code niet hetzelfde. Bij Clip gebruik je onderstaande code:

clip: rect(0 0 0 0);

Bij Clip-path een licht andere syntax:

clip-path: rectangle(0,0,0,0);

Besluit

Clip-path is momenteel onvoldoende ondersteund om het als waardig alternatief te gebruiken voor Clip. Voorlopig blijven we het gebruik van Clip aanraden.

Het kan geen kwaad om beide eigenschappen te gebruiken. Huidige browsers ondersteunen Clip en in de toekomst zullen ze Clip-path ondersteunen.

Reageer als eerste

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