Een icon font is een font (of lettertype) dat uitsluitend bestaat uit afbeeldingen. Aan elk karakter binnen het lettertype wordt een afbeelding gekoppeld. Het is dus niet bedoeld om tekstuele informatie mee over te brengen. In de typografie spreekt men van een "dingbat". Men gebruikt (of misbruikt?) de posities van het lettertype, die bedoelt zijn om cijfers en letters weer te geven, om er symbolen of iconen mee te creëren. Bijvoorbeeld pijltjes, sterretjes, hartjes, een telefoontje, een brief, etcetera. Het meest bekende lettertype dat uitsluitend bestaat uit dingbats is Windings, gecreëerd door Microsoft in 1990.

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 browsers geven CSS gegenereerde inhoud door aan screenreaders. De standaard ingebouwde screenreader op Mac OS VoiceOver, in combinatie met Safari, 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="true" 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 visueel verbergt.

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.

8 reacties

Je wil een menu uitlijnen tegen de rechterzijde van je website. Hiervoor gebruik je natuurlijk een lijstje (ul-element). Als we de CSS property float op een verkeerde manier gebruiken, kunnen we een toegankelijkheidsprobleem creëren.

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; 
}</p>

2 reacties

Een website wordt tegenwoordig altijd voorzien van een CMS (wat staat voor Content Management System). Aan de hand van een CMS kan de beheerder van een website zelf zijn inhoud beheren. Omdat niet elke beheerder kennis heeft van HTML, wordt er meestal een WYSIWYG-editor voorzien. 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 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 en een titel , 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 sneltoetsenwerkende 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.

3 reacties

Talloze geautomatiseerde tools beloven je website te testen op toegankelijkheid. Zulke tools kunnen nooit een uitspraak doen of je website voldoet aan de Web Content Accessibility Guidelines. Die internationale standaard bestaat uit Succescriteria. Dat zijn principes en er zijn vaak meerdere technieken om daaraan te voldoen. Een aantal successcriteria zijn tot op zekere hoogte automatisch te controleren. De tool produceert een rapport met zijn bevindingen. Om dat rapport correct te interpreteren, heeft de gebruiker in elk geval kennis van zaken nodig.

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.

• 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.
• Als een knop of link niet correct is geïmplementeerd in de website, ontdek je dat onmiddellijk als je met de tabtoets de pagina overloopt. Voor een testtool is dat veel moeilijker vast te stellen.
• 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.
• Succescriteria als "betekenisvolle volgorde" en "paginatitels" vereisen menselijke interpretatie over wat betekenisvol is.

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. 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.

1 reactie

Veel webbouwers denken dat hun site niet wordt bezocht door personen met een handicap. Als er nooit klachten komen, gaan ze er al snel van uit dat er niets mis is met hun site. Ze vinden het dan ook niet de moeite om aandacht te besteden aan toegankelijkheid. Beide veronderstellingen komen vaak niet overeen met de realiteit. Als je een probleem hebt met een site, laat dan van je horen. Dat kan soms net de aanmoediging zijn die men nodig heeft om er werk van te maken.

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

Meer informatie en tips in het Engels:

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

5 reacties