Toegankelijkheid voor bouwers
27 juli, 2010
‘Tijdrovend’, ‘ingewikkeld’ en ‘kan niet’ zijn de meestgehoorde argumenten van ontwikkelaars om het toegankelijk bouwen van het project te verwerpen. Gelukkig zijn alle argumenten nonsens. In dit artikel een samenvatting van de quick wins voor toegankelijk bouwen.
Het is 2010, tabellen voor opmaak kunnen écht niet meer.
Het lastige is natuurlijk dat er diverse niveaus van toegankelijk bouwen zijn. Het is echter mijn stellige overtuiging dat iedere zichzelf respecterende front-end ontwikkelaar er op uit is om de meest schone en semantisch correcte code op te leveren. Ik ben dan ook uitgegaan van de webrichtlijnen versie 2 in deze lijst van aandachtspunten.
Algemeen
- Scheid content van opmaak en interactie. Geen javascripts in de broncode maar in losse bestanden, geen inline style-attributen maar een goed georganiseerde stylesheet.
- Plaats de meeste relevante content bovenaan in de broncode. Dit ijkpunt zal niet meer in WCAG 2 terugkomen naar wat ik heb begrepen, maar blijft wat mij betreft wel degelijk relevant. Het contentvlak is bij het navigeren door een site nog steeds het meest relevante onderdeel. Om daaronder het menu, de gerelateerde content, de metanavigatie en de footer elementen – bij voorkeur in die volgorde – te plaatsen voelt voor mij als het op maat aan aanleveren van de informatie naar de gebruiker.
- Gebruik tabellen alleen voor tabulaire data, tabellen voor opmaak kunnen écht niet meer. Geen argument is sterk genoeg om dit nog te bestrijden.
- Redirecten van gebruikers naar je nieuwste product, het openen van pagina’s in een nieuw venster; het zorgt allemaal voor verwarring bij de gebruiker. Best onhandig als je graag wilt dat hij of zij je nieuwste dienst of product afneemt.
- Gebruik de toets-applicatie van de Webrichtlijnen om webpagina’s te controleren op 47 van de 125 webrichtlijnen. Hiermee vang je vrijwel alle veelvoorkomende problemen af. Hierin is bijvoorbeeld ook de W3C HTML-validator verwerkt.
- Gebruik bij voorkeur het XHTML 1.0 strict-doctype of het html5-doctype, in combinatie met bovenstaande validators.
- Gebruik meta-data voor het aanwijzen van RSS-feeds in de <head>.
Feedback aan de gebruiker
- Formuliervelden dienen te zijn voorzien van corresponderende label-elementen. Groepeer gerelateerde invoervelden in aparte fieldsets (bijvoorbeeld persoonlijke informatie los van de betalingsgegevens), en gebruik het legend-element om het formulier kort samen te vatten.
- Geef de belangrijkste taal aan in het HTML-attribuut boven aan de pagina met <html xmlns=”http://www.w3.org/1999/xhtml” xml:lang=”nl” lang=”nl”>
- Veranderingen in taal dienen te worden aangegeven. Dit kan goed worden opgelost met bijvoorbeeld een <span lang=”en”>This text is written in English</span>.
- (i)frames zijn soms helaas niet te vermijden omwille beleid van hogerhand. Mocht het dan toch nodig zijn, voorzie deze elementen dan van een juiste titel via het title-attribuut, waaruit blijkt waar het betreffende (i)frame voor dient.
- Gebruik een goede en valide headeropmaak voor je content. Verdeel tekst in kleinere happen content met <h2> en <h3> elementen. Blinde gebruikers maar ook zoekmachines gebruiken dit om snel de pagina te kunnen scannen op relevantie.
- Voorzie je website van een sitemap om de gebruikers een goed overzicht te geven van de diepte en breedte van je website.
- Bij gebruik van Flash en/of Silverlight is het belangrijk dat er a) geen heftige flikkeringen plaatsvinden waar bijvoorbeeld gebruikers met ADHD of kans op epileptische aanvallen last van kunnen hebben b) een mogelijkheid is om animaties te pauzeren danwel volledig uit te zetten.
Gelaagd bouwen
- Zorg ervoor dat alle content bereikbaar, toegankelijk en bestuurbaar is, ook wanneer Javascript is uitgezet, of wanneer de gebruiker geen Flash- of Silverlight-plugin heeft geinstalleerd.
- Hyperlinks moeten functioneren zonder JavaScript
- Hyperlinks moeten het outline-attribuut behouden, zodat met navigeren met behulp van alleen het toetsenbord duidelijk is waar de gebruiker zich bevindt.
- Houd rekening met de verschillende vormen van input, zoals bijvoorbeeld touch-devices zoals de iPhone en iPad, door gebruik van de :active-pseudoclass, en het toegankelijk maken van dropdown-menu’s.
- Wees terughoudend met tekst opnemen in afbeeldingen; liever een goede structuur bedenken waarin dit over de afbeelding wordt geplaatst als normale content.
Schone code
- <center>, <font>, <b> etc. zijn al sinds 1822 niet meer toegestaan in code. Er van uitgaande dat je dat zelf al niet meer gebruikt; zorg dat ook het CMS dat wordt geïmplenteerd deze code stript wanneer redacteurs kopiëren en plakken uit Word; ook de controle op dit soort zaken is de taak van een front-end developer. (update: In HTML5 krijgen sommige elementen blijkbaar een nieuwe semantische waarde. Interessant en buitengewoon verwarrend in mijn optiek.)
- Lijsten moeten worden opgemaakt <ul> of <ol>
- <blockquote> mag uitsluitend worden gebruik voor citaten, en dus niet voor het inspringen van tekst (het gebeurt, heus waar!)
- HTML5 staat het gebruik van het target-attribuut toe. Dat houdt niet in dat je het dan ook weer móet gebruiken. Er is een reden dat target=”_blank” lange tijd werd afgeraden; het brengt mensen in verwarring; we zien het bij Tam Tam nog regelmatig mis gaan bij usability testen voor externe partijen. Daarom is mijn advies om het niet te gebruiken en eventueel met Javascript en class=”external” te werken om te zorgen dat het naar wens functioneert voor gebruikers die er zelf voor kiezen Javascript wel of niet te gebruiken.
CMS inrichten
- Tabellen dienen te zijn voorzien van rij- en kolomheadersom associaties duidelijk te maken ten opzichte van de content. Maak dit mogelijk in het CMS.
- Biedt in de editor de mogelijkheid om teksten te kunnen voorzien van language spans.
- Afkortingen moeten kunnen worden verduidelijkt met het <abbr>-attribuut. Bijvoorbeeld <abbr title=”Centraal Bureau voor Statistieken”>CBS</abbr>
Als je deze ijkpunten meeneemt in de bouw van een website of -app, zul je zien dat niet alleen de code aan de achterkant, maar ook de beleving aan de voorkant en de zoekmachine-vindbaarheid van je project aanzienlijk zal toenemen.
Bedenk tevens dat voor front-end developers een taak is weggelegd aan de CMS-kant. Het is onze taak om back-end developers te wijzen op de ondersteuning van elementen zoals <abbr> en <cite> in de editor van het gekozen CMS.
In het opstellen van deze lijst ben ik wellicht zaken vergeten, en misschien heb je een verscherping of aanvulling van een van de ijkpunten. Laat het me dan weten, dan neem ik het op deze lijst.
Categorieën: Best Practice, Schone code, Toegankelijkheid
-
@Alexandervn schreef op 27 juli, 2010 om 19:10 uur
Goed stuk. Je kunt trouwens ook rel=”external” gebruiken als attribuut voor een Javascript-variant van target=”_blank”, dat is denk ik duidelijker dan een class.
-
@ipenburg schreef op 27 juli, 2010 om 22:09 uur
In de tijd dat een ontwikkelaar nog met de hand een statische site in elkaar zette had dit misschien nog allemaal nut, maar op het web 2.0 is het toch vaak belangrijker om ergens geautomatiseerd of user generated content vandaan te halen die niet toegankelijk is, en dat dan ook blijft.
-
@ schreef op 27 juli, 2010 om 22:31 uur
Niet zozeer oneens, maar wel een kleine kritische opmerking. Het b-element wordt ook in de laatste standaard gewoon ondersteund:
http://www.w3.org/TR/html5/text-level-semantics.html#the-b-element
- Jorrit
-
Jeroen schreef op 28 juli, 2010 om 00:05 uur
@alexandervn: Eens, dat gebruikte ik voorheen altijd. Echter, als je goed kijkt naar de waarde van het rel-attribuut, is dat niet helemaal op z’n plaats. Het beschrijft de relatie, niet de locatie ;-)
@ipenburg Dat ben ik niet helemaal met je eens. Het mooie van deze tijd is de wildgroei aan API’s waarmee je content als platte data (bijna altijd XML) binnenkrijgt, en er dus vervolgens je eigen opmaak aan kunt geven.
@Jorrit: Tsja, eens. De vraag is; is het verstandig, net als met het target-attribuut eigenlijk. De semantische waarde van bold tekst is iets anders dan strong of emphasized tekst ;-)
-
Jeroen schreef op 28 juli, 2010 om 00:26 uur
@Jorrit:
“The b element should be used as a last resort when no other element is more appropriate. In particular, headings should use the h1 to h6 elements, stress emphasis should use the em element, importance should be denoted with the strong element, and text marked or highlighted should use the mark element.”
Vrij duidelijk dus dat het geen aanrader is ;-)
-
@valuedstandards schreef op 28 juli, 2010 om 09:40 uur
Jeroen, (mooie site en goede opsomming trouwens :-)
Een korte aanvulling v.w.b. de
benielementen: deze zijn in HTML5 niet slechts bedoelt voor opmaak maar hebben wel degelijk semantische waarde: http://html5doctor.com/i-b-em-strong-element/.Persoonlijk vind ik het een beetje verwarrend en onrealistisch gesteld aangezien ik denk dat vrijwel niemand deze elementen juist zal gaan gebruiken, maar ze zijn dus wel opnieuw gedefiniëerd en krijgen een unieke semantische waarde.
Oh, en volgens mij is het niet de maar het
doctype:-) -
@ipenburg schreef op 28 juli, 2010 om 09:43 uur
@Jeroen: Je kan wel opmaak geven aan gestructureerde content van derden, maar niet verwachten dat die content beschikbaar is als markup met alle gewenste lang-attributen en abbr-elementen erin. Zelfs al zou het technisch mogelijk zijn om een language span in deze reactie te stoppen, dan is nog niet iedere gebruiker altijd even alert om die dan ook te benutten.
-
Jeroen schreef op 28 juli, 2010 om 09:52 uur
@Valuedstandards Bedankt voor het compliment!
Ik was niet op de hoogte van de nieuwe semantische waardes van de “oude” elementen, ik deel je mening dat het vooral verwarrend is. Ik ga daar nog even dieper naar kijken, en misschien is het wel een artikeltje waard, of een bericht richting het W3C ;-)
Ik pas het lidwoord direct aan, haha…helemaal waar ;-)
@ipenburg Je reactie is tweeledig; enerzijds geef je aan dat externe data niet is voorzien van de juiste mark-up. Dat is natuurlijk niet tegen te spreken, en is ook niet redelijkerwijs te realiseren zonder foutmarges. Ik ga hier nog even over nadenken. Ik kan me voorstellen dat je aangeeft dat deze data van externe sites afkomstig is, maar er kan in sommige gevallen ook redactie over worden gevoerd (met uitzondering van bijvoorbeeld Twitter).
Anderzijds geef je aan dat gebruikers niet altijd even alert zijn. Dit is een behoorlijk andere discussie; dit is namelijk de kern van wat toegankelijkheid inhoudt; iedereen in het team is verantwoordelijk. Daar kun je geen uitzonderingen in maken wat mij betreft.
-
@ipenburg schreef op 28 juli, 2010 om 10:23 uur
@valuedstandards: Het is niet alleen verwarrend en onrealistisch, maar als je dus HTML fragmenten uit een database of via een API binnenkrijgt zou je op één of andere manier moeten kunnen achterhalen voor welke HTML versie een b of i element in die content oorspronkelijk bedoeld was om zeker te weten of de unieke semantische waarde daar van toepassing kan zijn.
-
@ipenburg schreef op 28 juli, 2010 om 11:11 uur
@Jeroen: Web 2.0 houdt in dat ongeveer de hele wereld onderdeel van het team is, en dat twitter inderdaad het ultieme voorbeeld is waar je weinig mee kan wat verregaande toegankelijkheid betreft. Daarnaast zitten er waarschijnlijk ook weer haken en ogen aan het voeren van een redactie over content omdat door het toevoegen van markup juist de twijfel over semantiek wordt weggenomen. Die twijfel was in de wetenschappelijke oorsprong van HTML ongewenst, maar wordt in een sociale context juist belangrijker voor een rijkere communicatie.
-
Jeroen schreef op 28 juli, 2010 om 11:24 uur
@ipenburg: Eens, en dat zal ook wel het spanningsveld blijven de komende tijd tussen toegankelijkheid en sociale media en invloed van gebruikers. Ik heb net een project rondom toegankelijkheid mogen afronden bij Microsoft Nederland, en zij hebben natuurlijk ook nog de uitdaging van vele engelse termen in merknamen. In samenspraak met Accessibility zijn daar goede afspraken over gemaakt, maar met 2500 contenteigenaren is het echt een uitdaging om dat goed uit te rollen.
Ik vind je reactie naar @ValuedStandards in dat opzicht ook een interessante invalshoek; wie bepaalt de semantische waarde uiteindelijk? Is datgene wat de gebruiker bedoeld gelijk aan de interpretatie van de redacteur?
Bedankt voor de goede feedback!
