Icon fonts kwamen, tot nu, zelden voor in webdesign. Het beperkte zich meestal tot Word – of andere documenten. Met de komst van de CSS expressie @font-face werd het mogelijk om eender welk lettertype online te gebruiken. Een grote stap vooruit voor online typografie en ook gunstig voor accessibility, want het maakt ontoegankelijke technieken zoals Cufón en sIFR overbodig.

Voordelen van icon fonts

• Kleine bestandsgrootte en dus snelle laadtijd. Je hebt geen images meer nodig in de HTML. Een lettertype laadt ook sneller dan image sprites.
• Afbeeldingen kunnen niet vergroot worden zonder kwaliteitsverlies. Een lettertype is vectorieel en kan daarom eindeloos geschaald worden zonder in te boeten op scherpte.
• Via CSS kan je de iconen makkelijk en snel stijlen, over de hele website. Denk hierbij ook aan de vele mogelijkheden van CSS3 (text-shadow, gradients etc.).
• Brede browser support.

Enkele voorbeelden van iconen uit het Pictos font:

Maar?

Er is helaas altijd een maar. Wanneer we een techniek (als ik lettertypes even een techniek mag noemen) gebruiken voor andere doeleinden dan oorspronkelijk bedoeld (cijfers en letters weergeven), vormt dat in 99% van de gevallen een toegankelijkheidsprobleem. Een machine of programma zoals een screenreader (her)kent alle universele karakters. Tot de vreemdste wiskundige tekens toe. Maar wanneer je een niet-universeel erkend of zelf ontworpen symbool (bijvoorbeeld een potlood) koppelt aan een bestaand karakter in een lettertype (bijvoorbeeld “P”), leest een programma dat karakter, en niet het symbool dat wordt weergegeven.

Wil dat zeggen dat je icon-fonts links moet laten liggen? Natuurlijk niet. Je moet er enkel bewust mee omgaan.

De icoontjes worden ingebracht via CSS pseudo elements :before of :after. Niet alle screenreaders ondersteunen CSS gegenereerde inhoud. De standaard ingebouwde screenreader op Mac OS VoiceOver, ondersteunt dit wel en wordt daarom ook in onderstaand voorbeeld gebruikt.

Ik gebruik een gratis (en dus beperkt) abonnement op Pictos server. Daarvoor moet het domein waarop mijn voorbeeld staat, door Pictos aanvaard worden. Blijkbaar zorgt dat dan weer voor problemen bij (drie keer raden) Internet Explorer. Om een lang verhaal kort te maken: bekijk onderstaand voorbeeld met eender welke moderne browser behalve Internet Explorer.

Testpagina met bedieningsknoppen via een icon font.

Conclusie

Wil je iconen gebruiken door middel van een lettertype voor puur decoratieve elementen? Verberg dan het karakter waaraan het icoon is gekoppeld met aria-hidden zodat screenreader gebruikers niet in de war geraken.

Hebben de iconen een functie, zijn ze niet decoratief? Voeg dan verklarende tekst toe die je eventueel verbergt door ze buiten scherm te positioneren.

Alternatief

Een alternatief voor aria-hidden is het gebruik van de Private Use Area binnen Unicode. Screenreaders lezen tekens binnen die groep van Unicode niet voor. Een voorbeeld van een font icon dienst die dit toepast is IcoMoon.

Fout

Eerst en vooral heb ik een foute voorbeeldpagina gemaakt met een lijstje dat als menu wordt gebruikt. Er staan cijfertjes bij de li-elementen om het probleem extra duidelijk te maken.

Hieronder vind je de belangrijkste HTML en CSS code:

<ul id=”menu”>
<li><a href=”#”>4 Contact</a></li>
<li><a href=”#”>3 Blog</a></li>
<li><a href=”#”>2 About us</a></li>
<li><a href=”#”>1 Home</a></li>
</ul>

#menu li{
float: right;
list-style: none;
}

We zien dat de li-elementen rechts uitgelijnd worden met de CSS-property float: right;. Het probleem is echter dat de elementen in de broncode in omgekeerde volgorde moeten staan om zo visueel de juiste volgorde te verkrijgen. In principe is dit een logische redenering. CSS werkt volgens een hiërarchische structuur. Eerst komt element 4 Contact tegen de rechterzijde en de elementen die volgen, komen er links naast te staan.

Meer info over dit probleem in het ijkpunt 3.2.1 Pagina-inhoud heeft betekenisvolle volgorde. Een screenreader zal in dit voorbeeld namelijk eerst 4 Contact voorlezen en eindigen met 1 Home. Dat kan je ook zien door te tabben in het menu. De focus komt eerst op 4 Contact en schuift zo op naar links tot 1 Home.

Goed

Je kan dit probleem oplossen door eerst het ul-element rechts uit te lijnen en de li-elementen links uit te lijnen. Op deze manier staan visueel de li-elementen identiek zoals in het foute voorbeeld én de volgorde in de broncode is correct. Deze correcte manier kan je vinden op de goede voorbeeldpagina. Hier zal de screenreader en het tabben beginnen bij 1 Home en eindigen bij 4 Contact.

De aangepaste HTML en CSS:

<ul id=”menu”>
<li><a href=”#”>1 Home</a></li>
<li><a href=”#”>2 About us</a></li>
<li><a href=”#”>3 Blog</a></li>
<li><a href=”#”>4 Contact</a></li>
</ul>

#menu{
float: right;
}

#menu li{
float: left;
list-style: none;
}

Daarnaast is het ook een week om aandacht te vragen voor de problematiek rond de digitale kloof, zowel bij politici, academici, mensen uit het werkveld als bij het grote publiek.

Met dit initiatief wil LINC vzw (de initiatiefnemer voor in Vlaanderen en Nederlandstalig Brussel) ‘nieuwe’ geletterdheid bevorderen, opdat iedereen zich thuis kan voelen in de kennismaatschappij.
Dat sluit mooi aan bij onze doelstelling voor een toegankelijker internet. Daarom heeft AnySurfer besloten om dit jaar ook enkele opleidingen gratis aan te bieden tijdens de digitale week:

• Toegankelijke Word-documenten ma, 23/04/2012, 09:30 – 16:30
• Online video ondertitelen di, 24/04/2012, 09:30 – 16:00
• Formation – Sous-titrer les vidéos en ligne vr, 27/04/2012, 09:30 – 16:00

Per opleiding kunnen er maximaal 10 mensen deelnemen. Wilt u deelnemen? Schrijf u dan ten laatste 16 april in door een e-mail te sturen naar info@anysurfer.be

We hebben een kijkje genomen en ervaren geen problemen die het gebruik, zowel het aanmaken als het invullen van een doodle, onmogelijk maken. De website bevat tamelijk wat fouten ten opzicht van de AnySurfer checklist / WCAG2.0 maar is wel voor iedereen bruikbaar als je weet op welke manier je het moet aanpakken.

3 mogelijkheden voor input

Bij het aanmaken van een doodle krijg je standaard de “agenda-weergave” te zien. Die is niet voor iedereen bruikbaar. De JavaScript (met device dependant event handlers) sluit helaas toetsenbordgebruikers uit. Je kan echter ook kiezen voor “basic calendar”, een eenvoudige tabel. Of een derde optie “free text” waar je de gewenste data zelf kan intypen in invoervelden. Dit zorgt ervoor dat iedereen een Doodle kan aanmaken. Als de agenda-weergave niet bruikbaar is met een specifiek hulpmiddel (bijv. een screenreader), kan je overschakelen naar de eenvoudige tabel (basic calendar). Wanneer dat niet werkt, kan je invoervelden (free text) gebruiken. Eigenlijk een soort van ‘graceful degradation’ dus. Alleen gebeurt dit niet automatisch.

Kleurgebruik

Hetzelfde geldt voor het invullen van een Doodle die je werd toegestuurd. Ook hier is een tabel-weergave en een agenda-weergave. De tabel-weergave is voor iedereen bruikbaar. De bijdragen van de deelnemers worden rood of groen gemarkeerd maar kleur is nooit het enige kenmerk waarmee een onderscheid tussen de gegevens wordt gemaakt. De keuze van de deelnemers wordt rood, orange of groen gemarkeerd maar ook onderlijnd. Geen probleem voor kleurenblinden dus.

In de groene tabelcellen staat ook telkens een vinkje. Hierdoor is het onderscheid tussen ja en nee niet alleen op kleur gebaseerd.

In de broncode worden alt-teksten aan deze afbeeldingen toegevoegd die het voor blinde gebruikers duidelijk maken.

<img src="/static/2012022701/graphics/common/doodlesprite.png"
alt="Bruce Lee, donderdag 19 april 2012: Ja.">


Mag ik er tot slot nog even op wijzen dat er ook een mobiele versie van doodle bestaat. Die is bedoeld voor smartphones maar kan ook nuttig zijn voor gebruikers met een beperking die het graag zo eenvoudig mogelijk houden.

Voor Windows is er een gratis en opensource screenreader Non visual desktop access (NVDA) die je kunt gebruiken om je website eens te beluisteren. De Nederlandse stem die erbij zit, is wel van mindere kwaliteit. We raden de versie voor USB-sticks aan. Omdat je die niet moet installeren, kan er ook niets fout lopen op je computer. Sinds onze vorige blogpost over NVDA zijn er heel wat verbeteringen in het product.

Een van de commerciële pakketten is JAWS. JAWS is 40 minuten als demoversie te gebruiken. Daarna moet je de computer opnieuw opstarten om er verder mee te kunnen werken. Download JAWS versie 12 in het Nederlands. Standaard zit er geen Nederlandse stem bij maar die is wel gratis te downloaden. Ga naar Help, Webbronnen, RealSpeak Solo Direct download pagina.

Gebruikers van Lion voor Mac hoeven al helemaal geen screenreader te installeren, want deze is ingebouwd in het besturingssysteem (VoiceOver). Druk op command+f5 en je computer begint te praten. Standaard praat hij Engels maar via de VoiceOver-instellingen kan je de Nederlandse stem Ellen activeren. Lees meer over VoiceOver, de screenreader van Apple.

WYSIWYG staat voor What You See Is What You Get. De gebruiker werkt in een interface die gelijkt op de pagina zoals die er in de webbrowser zal uitzien.

Welke WYSIWYG-editor?

Er bestaan geen cijfers die aantonen welke editors het meest gebruikt worden. Hier volgt een vergelijking van de twee editors waar we het meest mee in contact komen, namelijk Tiny MCE en CKEditor.

Enerzijds moet de WYSIWYG-editor inhoud produceren die het mogelijk maakt om aan de AnySurfer Checklist 2.0 te voldoen, en dit zonder dat de gebruiker van de editor kennis heeft van HTML. Anderzijds is het ook belangrijk dat de editor waar mee gewerkt wordt, zelf toegankelijk is.

Test 1: correcte HTML

Voor deze test heb ik een pagina gemaakt die valideert volgens de W3C validator. De test bestaat eruit deze pagina na te maken in CKEditor (screenshot CKEditor) en TinyMCE (screenshot TinyMCE). In dit document staan HTML elementen waarmee je al een redelijk uitgebreide pagina kan maken.

Beide editors slagen voor deze test, de HTML valideert. Er zijn echter wel een aantal zaken die opvallen:

• Bij nesting van lijstjes kan het wel eens mis gaan. Het hangt ervan af hoe je dit doet. Als je achteraf item selecteert en het inspringen vergroot, kan het wel eens fout lopen. De geneste lijst staat dan tusssen 2 li- elementen en niet in het li-element (fout voorbeeld):
  <ul>
<li>a</li>
<li>b</li>
<ul>
<li>b1</li>
<li>b2</li>
<li>b3</li>
</ul>
<li>c</li>
</ul>
• Als je in TinyMCE een datatabel wil invoegen met tabelhoofdingen <th> en een titel <caption>, moet je achteraf via eigenschappen van de tabelcel, het celtype veranderen van data naar header. CKEditor voorziet al het gebruik van tabelhoofdingen bij de aanmaak van een tabel. Zeker voor redacteurs die geen HTML-kennis hebben, is het een extra drempel om th-elementen in TinyMCE te gebruiken.
• Soms kunnen extra plugins of instellingen ervoor zorgen dat de gebruiker geen toegankelijkheidsproblemen kan veroorzaken. Zo kan je de gebruiker aanraden het alt-attribuut in te vullen van een afbeelding. Als de afbeelding decoratief is, kan hij het alt-attribuut dan leeg laten (alt=”").
• Het is aangeraden dat de ‘full-option’ toolbar niet gebruikt wordt. De mogelijkheid om te onderlijnen (u-tag) kan voor verwarring zorgen, links zijn doorgaans onderlijnd. Tekst uitvullen (justify) wordt ook beter weggelaten, dit verminderd de leesbaarheid. Andere mogelijkheden zoals de kleur en achtergrond van tekst kunnen aanpassen, het lettertype en de lettergrootte, kan de leesbaarheid van tekst bemoeilijken. Dergelijke zaken worden beter vastgelegd in de CSS. Plugins zoals het invoegen van flash, kunnen voorzien worden als het echt nodig is.

We kunnen besluiten dat beide editors in staat zijn HTML te produceren die semantisch correct is. Ook na het aanpassen en verwijderen van code, blijft de code valideren.

Test 2: toegankelijkheid

Beide editors hebben een toolbar waar tal van iconen kunnen instaan. Het is relatief simpel om extra toolbars of extra iconen te tonen of te verbergen. In de filosofie van AnySurfer is het natuurlijk belangrijk dat deze toolbars zelf ook gebruiksvriendelijk en toegankelijk zijn.

CKEditor slaagt het best voor deze test. Op hun website is er zelfs een document te vinden over toegankelijkheid van de editor met het toetsenbord. Zo is het mogelijk om in de toolbars te navigeren met diverse sneltoetsen zonder dat hiervoor extra code moet voorzien worden.

Bij TinyMCE is het ook mogelijk maar de procedure is veel omslachtiger. Bij de test slagen we er niet in om de voorgestelde sneltoetsen werkende te krijgen (getest in Windows 7 en Mac OS X Lion met Internet Explorer 9 en Firefox 7). Daarenboven zijn de sneltoetsen niet in elk besturingssysteem hetzelfde, iets waar CKEditor wel aan gedacht heeft.

Besluit

CKEditor komt het best uit onze test. Hij is toegankelijk in gebruik en een redacteur zonder technische kennis kan er toegankelijke pagina’s mee publiceren. Je kan alvast een voorbeeld met CKEditor bekijken welke toolbars  nodig zijn om de demo pagina te maken.
Een editor biedt helaas nooit garanties. De beste garantie blijft een gebruiker met kennis van webtoegankelijkheid.

Deze stelling sluit echter niet uit dat men met andere editors ook correcte HTML kan maken die zelf ook toegankelijk zijn.

Voorlopig is het nog verwarring alom als er iemand “Bart” roept, maar dat zal wel wennen. We wensen Bart heel veel succes en bedanken iedereen die de vacature heeft helpen verspreiden.

Enkele bekende voorbeelden, er bestaan tientallen varianten:

• webAIM’s WAVE toolbar
• AChecker
• FAE Functional Accessibility Evaluator

Waarom zijn hun resultaten waardeloos zonder menselijke aandacht?

Vergelijk het met taal. Je schrijft een artikel dat volgens de ingebouwde spellingscontrole van het programma geen enkele fout bevat. Wil dat zeggen dat je een artikel hebt geschreven dat voor iedereen begrijpelijk is en correct is opgebouwd? Neen. De spellingscontrole kan je enkel helpen om puur grammatische fouten te verbeteren.

We zijn grote voorstander van valide code, webstandaarden zijn er niet voor niets. Maar een website waarvan elke pagina valideert, is niet per definitie een gebruiksvriendelijke of toegankelijke website.

• Een testtool kan je bijvoorbeeld groen licht geven omdat alle afbeeldingen een alt-attribuut bevatten. Maar enkel een mens kan zien of die alternatieve omschrijvingen voor blinden en zoekmachines ook werkelijk overeenkomen met hetgeen er in de afbeelding wordt weergegeven.
• Enkel een mens weet welke afbeeldingen best als decoratief worden beschouwd en dus een leeg alt-attribuut moeten krijgen (alt=”“).
• Een script kan nagaan of je pagina’s koppen bevatten (H1, H2, H3 enz.) maar enkel een mens kan nagaan of die een logische en hiërarchische structuur weergeven.
• …

Wil dat zeggen dat testtools voor toegankelijkheid waardeloos zijn. Natuurlijk niet. Ze kunnen je helpen in de juiste richting kijken. Maar vertrouw ze nooit blindelings. Train jezelf in webtoegankelijkheid (onze checklist is een interessant startpunt). Wanneer je de noden en potentiële problemen van al je bezoekers kent, hoef je niet te vertrouwen op geautomatiseerde testtools.

Accessibility expert Joe Dolson vat het mooi samen:

“This isn’t to say that automated testing doesn’t have a place; but it should never be considered the deciding factor for accessibility.”

Als de site in kwestie het AnySurferlabel draagt, mag je het ons laten weten. Stuur ons een mailtje of richt je direct naar de website eigenaar en zet ons in kopie.

Heeft de site geen label, probeer dan de website eigenaar te contacteren. Natuurlijk mag je naar ons verwijzen voor meer technische uitleg om toegankelijkheidsproblemen te verhelpen.

Wanneer je een probleem wil melden, is het belangrijk dat je alle informatie geeft die een webbouwer (mogelijk) nodig heeft om het probleem te verhelpen.

• Je contactgegevens zodat men bijkomende vragen kan stellen of kan melden wanneer het probleem is verholpen.
• Wat je probeerde te doen op de site, wat je verwachtte en wat er gebeurde. Beschrijf eventueel de stappen die nodig zijn om het probleem te reproduceren en stuur de URL mee van de pagina waar het probleem zich voordoet.
• Vermeld welke apparatuur je gebruikt:
  • Besturingssysteem: bv. Windows 7 of Mac OS Lion
  • Browser: bv. FireFox 4, Internet Explorer 8, Opera 11 of Chrome 13
  • Eventuele hulpmiddelen: bv. screenreader JAWS 9, vergrotingssoftware ZoomText 9.1 of spraakherkenningssoftware Dragon 10

Gerelateerde blogpost: Toegankelijkheidsproblemen melden via Fix the web

Meer informatie en tips in het Engels:

• Contacting Organizations about Inaccessible Websites
• Users Must Become Their Own Advocates

• Er is een nieuwe versie van Tax-on-web in de maak. De site is nog niet live, maar de ontwikkelaars vragen jou om de toepassing in aanbouw alvast uit te testen en feedback te geven om de toegankelijkheid ervan te verbeteren.
• Een webdesigner mailt je met de vraag of dat nieuwe fancy lightbox-script wel zo bruikbaar is voor blinde bezoekers. Om daarop te antwoorden, moet je eerst wat tests doen met verschillende screenreaders. Je beslist om je bevindingen neer te pennen in een artikel en publiceert het op de website.
• Volgende week geef je een technische opleiding aan een team ontwikkelaars. Je zoekt nog wat nieuwe voorbeelden om het verhaal bij het ijkpunt ‘Website is bruikbaar zonder muis’ kracht bij te zetten.
• Je krijgt een mailtje van een oplettende klant die je laat weten dat zijn auditrapport er niet zo netjes uitziet in de laatste versie van Opera. Dat zet je snel even recht door de CSS van het rapport aan te passen.
• Samen met een collega zoek je naar een manier om automatisch facturen te genereren vanuit TeamDesk, onze online CRM applicatie.
• In je mailbox zit een complexe vraag over formuliervalidatie. De vraagsteller wil je antwoord graag in het Engels omdat de site in India wordt ontwikkeld.
• Je legt de laatste hand aan het auditrapport voor een nieuw museum. Je leest het nog eens na, overlegt een aantal zaken met je collega’s en verstuurt het naar de klant. In onze databank vul je de nodige gegevens in zodat de factuur opgemaakt kan worden.
• Een klant mailt trots met de melding dat alle gevraagde aanpassingen aan haar website zijn uitgevoerd. Je plant de validatie voor vrijdag in want volgende week wordt de site voorgesteld op een persconferentie.
• Je collega’s hebben een suggestie voor een nieuwe feature in onze rapportage-toepassing. Je onderzoekt hoe haalbaar het is en duikt vervolgens in de PHP-code.
• Je las op Twitter dat er een leuk nieuw boek over HTML 5 verschenen is. Na goedkeuring, bestel je het boek zelf op de website van Amazon. Op de treinrit naar huis verdiep je je in het boek.