Placeholder is geen label

Bart De Clercq op 14/11/2012

We zien het tegenwoordig meer en meer. Labels bij een formulierveld worden weggelaten en vervangen door een placeholder.

Een placeholder is echter geen volwaardig alternatief voor een label, een label moet steeds zichtbaar bij een formulierveld staan.

Label, value en placeholder?

Even een verduidelijking wat het verschil is tussen een label, value en placeholder.

Label

Een label hoort bij een formulierveld. Het toont aan welke informatie in een invoerveld moet staan.

Een screenreader zal het gelinkte label voorlezen als de cursor in een veld staat. Staat er geen label? Dan kan de screenreader niet voorlezen wat er moet ingevuld worden.

Een muisgebruiker kan klikken op het label om de cursor in het bijhorende veld te plaatsen. Vooral bij radiobuttons en checkboxes is het als muisgebruiker handig om op het label te kunnen klikken, in plaats van op de radiobutton of checkbox.

Hieronder een correct codevoorbeeld om een label te linken aan een input veld, onder het codevoorbeeld staat ook het formulier.

<label for="name">Naam:</label>
<input type="text" id="name"/>

Value

Een value is een attribuut dat kan toegevoegd worden aan een input element.

Hier kan je de waarde van het veld op voorhand definiëren. Met een beetje JavaScript, kan je ervoor zorgen dat deze waarde verdwijnt als de cursor in het veld komt.

<label for="adress">Adres:</label>
<input type="text" id="adress" value="Kunstlaan 24" onfocus="this.value=''"/>

Placeholder

Een placeholder is een attribuut dat eveneens kan toegevoegd worden aan een input element maar niet mag aanzien worden als vervanging voor een label.

De HTML 5 specificatie zegt letterlijk:

The placeholder attribute should not be used as an alternative to a label.

Het kan de gebruiker een hint geven welke data de gebruiker moet invoegen. Als voorbeeld kan je bij een input veld waar een e-mailadres gevraagd wordt, een dummy e-mailadres ingeven in de placeholder.

Zodra je data begint in te voegen in het veld, dan verdwijnt de placeholder.

Laat je het veld leeg, dan wordt de tekst van de placeholder opnieuw geladen.

Zie onderstaand codevoorbeeld en het formulier eronder. Zie je geen e-mailadres in het veld? Dan ondersteunt je browser het HTML 5 placeholder attribuut nog niet.

<label for="e-mail">E-mail:</label>
<input type="text" id="e-mail" placeholder="info@anysurfer.be" />

Waarom blijft een label verplicht?

Een value of placeholder mag steeds toegevoegd worden als extra informatie om de gebruiker hints te geven welke data verwacht wordt. Een placeholder lijkt een alternatief voor een label, maar dat is het zeker niet. Er zijn enkele bedenkingen waarom er altijd een zichtbaar label moet staan. Deze opmerkingen zijn van toepassing op de gewone gebruiker, een screenreader gebruiker maar evengoed iemand met concentratiestoornissen:

  • De placeholder tekst verdwijnt als de cursor in het input veld komt. Je moet dus op voorhand de placeholder lezen en hem onthouden om te weten wat je moet invullen.
  • Gebruikers die met de tabtoets navigeren tussen invoervelden, moeten terug tabben om de placeholder te zien. Voor je het weet sta je namelijk in een veld waar je niet van weet welke data er verwacht wordt.
  • De placeholder tekst heeft standaard een te laag contrastratio van 4.5:1 om goed leesbaar te zijn. Als je het dus gebruikt samen met een label, is het aangeraden via CSS deze standaard kleur aan te passen.

Alternatieven

We zien dat labels vaak vervangen worden door placeholders, bijvoorbeeld om plaats te besparen in een formulier. Wil je toch het placeholder principe gebruiken? Dan kan je Sliding Labels gebruiken om een placeholder te simuleren.

Lees ook

3 reacties

Nieuwe huisstijl

Bart De Clercq op 12/11/2012

De meesten onder jullie zullen het wel al gemerkt hebben, we hebben een nieuwe website en huisstijl. Maar dat is niet alles! Even een woordje uitleg ter verduidelijking:

Blog en checklist

Vroeger stond de blog op een apart domein (blog.anysurfer.be), nu zit de blog geïntegreerd in de website. Update uw RSS-reader met onze nieuwe RSS feed.

Ook de checklist is eindelijk in de site verwerkt. Vroeger stond de checklist op anysurfer.org, nu vind je deze terug in de rubriek "in de praktijk".

Met deze update willen we onze communicatie en dienstverlening verbeteren. De zoekfunctie van onze nieuwe website vindt nu ook resultaten in de blog en de checklist.

Statuspagina

Op websites met het AnySurferlabel is er sinds kort ook de mogelijkheid om te reageren. Als je klikt op het AnySurferlabel kom je niet langer op onze homepage terecht, maar op een statuspagina. Deze pagina vertelt wanneer het label werd uitgereikt en of het label wel nog geldig is. Deze pagina bevat ook een formulier om toegankelijkheidsproblemen te melden. Bijvoorbeeld wanneer er na het behalen van het label toch nog een fout in de site geslopen is. We onderzoeken je vraag en nemen contact op met de eigenaar om het probleem te verhelpen.

Als test kan je klikken op ons label op de website Belgium.be. Ons label staat linksonderaan op deze pagina.

Met de nieuwe website werd ook het label lichtjes gewijzigd. We vragen alle labeldragers om de nieuwe afbeelding te gebruiken. Voor alle duidelijkheid, het nieuwe label is louter grafisch gewijzigd en de twee versies zijn geldig.

Reageer als eerste

Wat kan een blinde met een QR-code?

Bart Simons op 29/10/2012

Wat is het?

Een QR-code is een soort streepjescode die je terugvindt op een affiche, in een tijdschrift, op een naamkaartje of bij een object in een museum. Een QR-code is bedoeld voor gebruikers van een smartphone en werkt als een soort snelkoppeling naar een webpagina of een visitekaartje. Het is de bedoeling dat je een specifieke app op je smartphone opent en de camera van je toestel op de QR-code richt. Van zodra een code in beeld is, zal de bijhorende webpagina of visitekaartje worden getoond op het scherm van je telefoon.

Voorbeeld van een QR-code

Een goed voorbeeld

Als blinde heb ik nog maar 1 keer gebruik gemaakt van QR-codes en dat was in het Rosenborg kasteel in Kopenhagen. Bij de meeste objecten staat daar een goed zichtbare QR-code. Als je die scant, kom je op de pagina van de mobiele website van het Rosenborg kasteel terecht, waar de uitleg over dat object staat. Erg handig want zo kon ik de informatie lezen met de vertrouwde stem van mijn iPhone.

Een voordeel van dit systeem ten opzichte van de klassieke audioguide die in musea gebruikt wordt, is dat je geen cijfertjes meer hoeft in te toetsen. Deze zijn vaak moeilijk leesbaar voor slechtzienden en meer en meer audioguides werken met een touch screen waardoor blinden ze niet kunnen bedienen.

Voorwaarden

Het antwoord op de vraag of QR-codes handig zijn voor blinden heeft meerdere facetten:

  • Je moet een toegankelijke smartphone bij de hand hebben.
  • Je moet toegang hebben tot het internet.
  • Je moet weten dat er een QR-code staat en je moet de camera van je smartphone erop kunnen richten.
  • En dan is het nog maar te hopen dat de webpagina waar je terechtkomt toegankelijk is.

Toegankelijke smartphone

Smartphones zijn ook bij personen met een handicap snel in opmars. Het blijven dure apparaten en ze zijn lang niet allemaal toegankelijk, maar ze kunnen zeer interessante hulpmiddelen zijn. Blinden zullen vooral beroep doen op een synthetische stem die de inhoud van het scherm voorleest en slechtzienden kunnen doorgaans de teksten vergroten. Wat de mogelijkheden zijn van de verschillende platformen zullen we in een aparte blogpost wel eens uit de doeken doen. Voor dit verhaal volstaat de wetenschap dat meer en meer personen met een handicap over een smartphone beschikken, maar dat je er net als bij de gemiddelde burger zeker nog niet vanuit kunt gaan dat bijna iedereen er eentje op zak heeft.

Internettoegang

Om een QR-code te benutten, moet je in de meeste gevallen over internettoegang beschikken. Voor de meeste smartphonegebruikers zal dit wel het geval zijn, maar toeristen zullen het vaak hebben uitgeschakeld omwille van de hoge roaming tarieven.

De code scannen

Om te beginnen, een blinde weet simpelweg niet dat er een QR-code staat. Iemand zal hierop moeten wijzen en dan is het nog een hele kunst om blindelings de code goed voor de camera van de smartphone te krijgen. Plaatst u in een tentoonstelling een QR-code bij elk object, zorg dan voor een consistente positionering van de code, vb. altijd rechts onderaan.

Met de toegankelijkheid van de app om de code te scannen, valt het goed mee. Je hoeft geen foto te nemen. De functie wordt geactiveerd van zodra een code in beeld is.

Waar kom je terecht?

Als je erin geslaagd bent om de code te scannen, kom je doorgaans op een webpagina terecht. Het hele proces is pas geslaagd als deze pagina ook toegankelijk is. Toegankelijkheid van mobiele websites is hetzelfde verhaal als toegankelijkheid van websites die je in een browser bekijkt. De AnySurfer checklist is hierop gewoon toepasbaar.

2 reacties

Responsive Webdesign en toegankelijkheid

Bart De Clercq op 19/10/2012

Update: Vergeet de button of link die het mobiel menu opent niet te testen. Dat is vaak een hamburger icoon zonder betekenisvol tekstalternatief en vaak niet bereikbaar met het toetsenbord. Goed voorbeeld: Accessible and responsive dropdown for navigation

Responsive Webdesign is een techniek om de gebruiker een optimale surfervaring te bieden. Op basis van de viewport van het toestel (de grootte van het scherm waar de inhoud van de website staat) waarmee een gebruiker een website bezoekt, wordt er specifieke HTML en CSS geladen. Dit is mogelijk door CSS3 media queries. Deze techniek kan deze viewport van de browser detecteren.

Voor wie het nog niet duidelijk is, surf even naar Fork CMS (het CMS waar onze website op draait), en verklein even het browserscherm. Je zal merken dat er 4 versies bestaan van deze website: voor desktop, tablet en smartphone. De layout van de pagina zal zich automatisch aanpassen. Hieronder een screenshot van deze 4 versies, je kan de afbeelding vergroten door erop te klikken.

Screenshot Fork met 4 verschillende screenshots, hoe kleiner het browservenster, hoe minder inhoud.

Maar hoe zit het met Responsive Webdesign en toegankelijkheid? In principe zijn er geen problemen. De techniek zal afhankelijk van de viewport, aangepaste HTML en CSS inladen. Screenreaders die een website voorlezen aan blinde bezoekers, zullen op dezelfde manier deze info kunnen raadplegen dan op de reguliere website.

Er zijn echter 2 bedenkingen:

Screenreaders en mobiele toestellen

Een screenreader is geavanceerde software die alles voorleest aan blinde gebruikers. Standaard zit in Mac OS X VoiceOver. Voor andere besturingssystemen zijn echter ook screenreaders beschikbaar (bijvoorbeeld Jaws voor Windows).

VoiceOver is standaard ook terug te vinden in een iPhone en iPad en ook voor andere mobiele besturingssystemen zijn screenreaders beschikbaar (bijvoorbeeld TalkBack voor Android).

Als een blinde persoon een website bezoekt met zijn mobiele telefoon, zal hij echter niet dezelfde informatie krijgen dan van de screenreader op een desktop computer. De browsers en screenreaders op mobiele telefoons zijn niet zo krachtig dan deze van de desktop computer. Zo biedt Safari op iOS 6 minder ondersteuning voor ARIA in vergelijking met Safari in Mac OS X.

Ook al zijn de mogelijkheden op een mobiel toestel minder, we kunnen besluiten dat een gebruiker met een mobiele screenreader de website kan bezoeken.

There's a snag in it

Er is echter 1 situatie waar Responsive Webdesign niet gewenst is. Stel, je bent slechtziend en wil een onderdeel van een website vergroten met de zoomfunctie die aanwezig is in de browser. Dan zal er ongewenst een wijziging optreden van de inhoud waar de bezoeker niet om gevraagd heeft.

Deze wijziging treedt op bij de browsers Internet Explorer 9, FireFox 16 en Opera 12. In Safari 6 en de laatste versie van Chrome gebeurt dit niet. Bij het vergroten van een pagina, zal WebKit de viewport niet aanpassen. Onderstaande screenshot toont FireFox 16 en Safari 6 naast elkaar. FireFox (links) toont de versie voor een mobiele telefoon, Safari (rechts) toont de originele versie maar uitvergroot. Je kan op de afbeelding klikken om deze te vergroten.

Screenshot van FireFox en Safari met Fork-CMS uitvergroot.

Op de website van Fork CMS is dit geen ramp, alle inhoud blijft op de 4 versies beschikbaar. De bezoeker zal wat moeten scrollen om het onderdeel dat hij wou vergroten, opnieuw terug te vinden.

Er zijn echter websites die in de mobiele versie heel wat inhoud weglaten. Dit hebben we te danken aan het tijdperk waar er nog een aparte mobiele website werd aangeboden, de alombekende m.website.be link. Hier was het de bedoeling om een afgeslankte versie aan te bieden voor mobiele bezoekers.

Iemand die in de browser zoomt om iets te bekijken, zal het deel dat hij wou uitvergroten niet meer terugvinden. Deze situatie kan een ramp zijn. Niet alleen voor de bezoeker die zijn winkelwagentje wil uitvergroten maar ook voor de website eigenaar die een klant heeft die niet kan bestellen.

Er zijn ook situaties waar een niet slechtziende persoon 'last heeft' van Responsive Webdesign. Stel, je wil iets tonen op een beamer maar die heeft maar een resolutie van 600x800 pixels (ja die bestaan nog), dan krijg je ook ongewenst een mobiele website geprojecteerd.

De oplossing

De problemen die kunnen optreden bij Responsive Webdesign en toegankelijkheid zijn eerder miniem maar kunnen toch storend zijn. De enige goede oplossing is dat er bij Responsive Webdesign goed nagedacht moet worden en dat de inhoud in alle versies moet terug te vinden zijn. Zo zal je niet alleen de slechtziende bezoeker helpen die zoomt in zijn browser, maar ook de mobiele surfer die ook graag alle inhoud kan raadplegen op zijn mobiel toestel.

Nog beter is dat hij ook voldoet aan de AnySurfer Checklist om optimale toegankelijkheid te verzekeren.

9 reacties

HTML5 figure en figcaption

Bart De Clercq op 04/06/2012

Één van de nieuwe block level elementen in HTML5 is het figure element in combinatie met het inline figcaptionelement. Het is geïntroduceerd in HTML5 om illustraties (afbeeldingen, video's, codeblokken, svg, canvas, ...) met een beschrijving te omsluiten. Je kan het vergelijken met een table en caption. Het caption element (figcaption) geeft een bijschrift over de table (figure). Het wordt ondersteund door Internet Explorer 9, FireFox 4, Opera 11, Chrome 8 en Safari 5.1.

Hoe we het nu doen

Als voorbeeld staat hieronder een afbeelding met een bijschrift. Onder de afbeelding staat het code voorbeeld.

HTML5 logoHet logo van de nieuwe HTML5 standaard.

 

<div>
  <img 
    src="http://images.anysurfer.be/HTML5.jpg" 
    alt="HTML5 logo" 
    title="HTML5 logo"
  />
  <p>
    Het logo van de nieuwe HTML5 standaard.
  </p>
</div>

Met figure en figcaption

HTML5 logoHet logo van de nieuwe HTML5 standaard.

 

<figure>
  <img 
    src="http://images.anysurfer.be/HTML5.jpg" 
    alt="HTML5 logo" 
    title="HTML5 logo"
  />
  <figcaption>
    Het logo van de nieuwe HTML5 standaard.
  </figcaption>
</figure>

De voordelen

Het doel van figcaption is om een uitgebreid bijschrift te geven. Het is niet als vervanging voor het alt of title attribuut die een korte omschrijving geven van wat er te zien is op de afbeelding.

Ook moet niet elke afbeelding in een figure staan met een figcaption als bijschrift. Het kan gebruikt worden om illustraties die meer uitleg vragen, verder toe te lichten.

Enkele voordelen:

  • HTML code wordt semantisch beter gestructureerd. Het figure element bakent illustraties met een bijschrift af.
  • Het figure element kan ook meerdere afbeeldingen bevatten met een figcaption die een algemene omschrijving geeft van alle afbeeldingen.
  • Er kan een relatie gemaakt worden tussen illustraties en een algemene omschrijving.

Figure, figcaption en screenreaders

We mogen er niet van uitgaan dat alle screenreaders dit nieuwe element al op een consistente manier ondersteunen.

VoiceOver (Mac OS X 10.7.4) in combinatie met Safari 5.1.6 en Jaws 12 (Windows 7) in combinatie met Internet Explorer 9, geven beiden hetzelfde resultaat. De twee nieuwe elementen worden niet automatisch voorgelezen, er moet handmatig naar de omschrijving genavigeerd worden zoals in het eerste voorbeeld. De screenreader gebruiker weet dus niet dat er een figure element staat.

Als tijdelijke oplossing tot dat screenreaders deze elementen ondersteunen, kunnen we aan de afbeelding het aria-describedby attribuut toevoegen om de figcaption aan de afbeelding te linken. Op deze manier komen we tot een oplossing waarbij we HTML5 gebruiken én waarbij screenreaders de figcaption automatisch voorlezen. Spijtig genoeg zullen VoiceOver en Jaws de alt attributen overslaan en alleen maar de figcaption voorlezen.

HTML5 logoHet logo van de nieuwe HTML5 standaard.

 

<figure>
  <img 
    src="http://images.anysurfer.be/HTML5.jpg" 
    alt="HTML5 logo" 
    title="HTML5 logo"
    aria-describedby="figcaption1" 
  />
  <figcaption id="figcaption1">
    Het logo van de nieuwe HTML5 standaard.
  </figcaption>
</figure>

Besluit

HTML5 figure en figcaption gebruiken, geeft geen problemen met screenreaders. De figcaption kan perfect voorgelezen worden al gebeurt dit niet automatisch.

Denk echter goed na als je aria-describedby wil gebruiken om de figcaption automatisch te laten voorlezen bij focus op de afbeelding. De alt attributen worden namelijk niet meer voorgelezen en dat is iets dat we niet toejuichen. Screenreader gebruikers kunnen zo informatie missen en dat is niet de bedoeling.

Het wordt dus afwachten hoe screenreaders figure en figcaption in de toekomst zullen ondersteunen.

10 reacties