Webrichtlijn 18: Tekstopmaak, afkortingen
Gebruik het abbr (abbreviation) element voor afkortingen indien er onduidelijkheid zou kunnen ontstaan over de betekenis ervan, de afkorting een zeer belangrijke rol speelt in de tekst of wanneer de afkorting niet voorkomt in het Nederlands woordenboek. (R-pd.3.6)
Zoals de webrichtlijnen ook opmerken wordt <abbr> standaard niet ondersteund door Internet Explorer. <acronym> werkt wel, maar heeft een andere betekenis. Welke gebruik jij? Pas je nog technieken toe om <abbr> wel functioneel te maken binnen Internet Explorer? Hoe kijk je aan tegen de balans tussen het nut van dit element, en de hoeveelheid werk om het juist te gebruiken?
Reacties
- 1 Michael Wijnakker op 02-04-2008 om 08:36 uur:
- Sjoerd Visscher heeft ooit ontdekt dat je door
document.createElement('abbr');toe te voegen je de abbr ook bruikbaar (te stijlen) maakt in IE.
Het toepassen van de abbr zoals in deze webrichtlijn wordt voorgesteld is wel een discussie waard.
De webrichtlijn zegt: "Het is geaccepteerd dat alleen de eerste keer dat een afkorting zich voordoet in een tekst voluit gemarkeerd wordt"
Hierbij gaan 'we' er dus vanuit dat elke bezoeker de pagina van boven naar beneden helemaal leest. Dit is helemaal niet zo en vooral niet als er bovenaan de pagina ankernavigatie staat.
Het stijlen van de abbr is verwarrend tov links.
Een aparte stijl toekennen aan de abbr waarin de onderstreping wordt geregeld werkt (vaak) voor alle abbr-elementen en dus ook voor die zonder title en dan wordt het pas echt verwarrend.
Dit voorbeeld uit de webrichtlijnen is echt geen goed idee:<abbr title="Christen-Democratisch Appel">CDA</abbr> (Christen-Democratisch Appel)omdat mensen met een screenreader dit opgelezen kunnen krijgen als "Christen-Democratisch Appel (Christen-Democratisch Appel)" en hierdoor kunnen zij de associatie tussen de afkorting en de uitgeschreven variant niet maken. (http://www.rnib.org.uk/wacblog/articles/too-much-accessibility/too-much-accessibility-double-expanded-acronyms/)
Volgens mij is de makkelijkste en duidelijkste oplossing voor iedereen dat de eerste keer dat de afkorting gebruikt wordt, je de uitgeschreven variant neerzet met de afkorting er tussen haakjes achter.
Ja, ik spreek mezelf tegen door te zeggen dat het de eerste keer moet ;-) - 2 Marcel op 02-04-2008 om 09:31 uur:
- Het verschil tussen de twee tags en begrippen is voor velen sowieso een probleem. Ik snap er zelf ook nog maar weinig van moet ik zeggen - en ik ben toch best goed in begrijpend lezen in 't Engels ;-)
Zie ook dit interessante artikel, welke ook direct een paar problemen aanpakt voor onze screenreader-gebruikende bezoekers:
http://www.benmeadowcroft.com/webdev/articles/abbr-vs-acronym.shtml - 3 Raph de Rooij op 02-04-2008 om 18:24 uur:
- Volgens mij moeten we het eerst over de theorie hebben voordat de praktische toepasbaarheid goed kan worden beoordeeld. De link van Marcel is wat dat betreft een heel goed vertrekpunt. Ik heb gecontroleerd of ons eigen oude vertrouwde woordenboek Nederlands dezelfde betekenis toekent aan de verschillende begrippen. Uit een bezoekje aan www.vandale.nl blijkt de volgende betekenis:
acroniem (ofwel letterwoord):
woord gevormd uit de beginletters van verschillende andere woorden
afkorting:
afgekort woord, verkorte uitdrukking gevormd door de eerste letters gevolgd door een punt
initiaalwoord:
uit de beginletters van een meerledige naam gevormd woord
Hamvraag is, of een initiaalwoord moet worden beschouwd als een acroniem of als een afkorting. Volgens http://nl.wikipedia.org/wiki/Initiaalwoord is een initiaalwoord "een van de ongeveer vijf subgroepen van afkortingen, en moet met name worden onderscheiden van het letterwoord of acroniem, dat wel als woord te lezen is doordat het aan de fonetische eisen van Nederlandse woordvormen voldoet."
Die uitleg is in overeenstemming met de uitleg in het artikel van Ben Meadowcroft.
Voorstel voor een vuistregel: als je het kunt uitspreken als een woord én het eindigt niet met een punt, dan is het een acroniem; anders is het een afkorting.
Een paar voorbeelden:
NAVO: acroniem
enz.: afkorting
BZK: afkorting
VROM: acroniem
Er zijn altijd gevallen die het allebei kunnen zijn; een aardige is mySQL; sommigen spreken het uit als Maaiseewel (acroniem), anderen als MaaiEsKjoeEl (afkorting). Een andere is WCAG: de ingewijden zeggen Weejkeg (acroniem), de rest van de wereld WeejCeeAaGee (afkorting), of hoe die lettervolgorde in een andere taal ook mag klinken.
In dergelijke gevallen is mijn advies om het als een afkorting aan te geven: de incrowd, die meestal verantwoordelijk is voor het bestaan van de acroniem-variant, weet dan nog steeds waar het over gaat.
Er is overigens nog veel meer over te schrijven: naast afkortingen, acroniemen (letterwoorden) en initiaalwoorden zijn er ook nog symbolen en verkortingen. Zie http://taaladvies.net/taal/advies/term/122/ voor meer details. Wie wil kan dus nog een hele boom opzetten over van wat voor tag symbolen en verkortingen moeten worden voorzien ;-)
"I'm still confused, but at a much higher level now"
Raph - 4 Jeroen Pulles op 03-04-2008 om 15:04 uur:
- HTML 5 zegt: "The abbr element represents an abbreviation or acronym."
(http://www.w3.org/html/wg/html5/#the-abbr)
Wat ik persoonlijk wel prettig vind. Ik vind semantiek belangrijk, maar een enorm vocabulair aanleggen om subtiele verschillen te kunnen modelleren, maakt de taal zo complex dat ik moeite krijg om de taal goed toe te passen.
HTML 5 heeft trouwens ook een constructie om duidelijk te maken dat een (eerste) abbr de definitie bevat: het dfn element.
O ja, HTML 5 is natuurlijk nog toekomstmuziek. - 5 Anne van Kesteren op 04-04-2008 om 01:41 uur:
- Ik gebruik geen van beide bijna meer (mwaj, soms nog wel). Dit is typisch iets waar een woordenboek en context genoeg moet zijn en ik niet alle moeite hoef te doen als auteur.
(Sommige mensen genereren deze elementen automatisch. Ik denk dat je dan aan het punt voorbij gaat, want als jij ze kunt genereren, kan de software die de pagina leest dat ook.) - 6 Raph de Rooij op 07-04-2008 om 14:42 uur:
- @Anne [5]: Er zijn genoeg voorbeelden van afkortingen die in het geheel niet voorkomen in een woordenboek. En dat zijn juist de afkortingen waarbij uitleg op zijn plaats is. Een mooi voorbeeld was het ministerie van Sociale Zaken waar ze voor zo ongeveer elk organisatieonderdeeltje een afkorting hadden. Zie dan maar als niet-ingewijde om er wijs uit te worden.
De inzet van techniek om automatisch elementen automatisch te genereren is zeker nuttig, maar naar mijn mening geen substituut voor nadenken over wat er gecommuniceerd wordt.
Ideaal is een afkortingenlijst die door een content management systeem (CMS) wordt gebruikt om automatisch de betekenis bij afkortingen aan te geven en die in datzelfde CMS kan worden beheerd.
Wie weet van het bestaan van zo'n voorziening? In welk CMS is dat dan? En werkt het goed?
De software die de pagina leest kan die elementen niet automatisch genereren, want die heeft geen idee wat afkortingen in een bepaalde context allemaal kunnen betekenen, omdat er geen centraal register bestaat voor afkortingen, acroniemen, initiaalwoorden, symbolen en verkortingen. - 7 Michael Wijnakker op 07-04-2008 om 21:50 uur:
- @Raph Ik ben begonnen om zo'n toepassing te maken in Tridion voor minvws.nl. Dit is niet out-of-the-box, maar kan wel. Het maken van de lijst afkortingen is niet het probleem.
Maar als je die lijst van afkortingen dan wil loslaten op een content-pagina, dan heb je regels nodig.
Bij het bedenken van die regels stuitte ik op de vragen die ik hierboven al heb neergezet.
Of moet de redacteur bij het maken van een pagina zelf de abbr's toevoegen, waarbij hij de in het cms beheerde lijst kan gebruiken? - 8 Koen Willems op 05-05-2008 om 14:30 uur:
- @Michael en Raph:
Momenteel ben ik ook zo'n voorziening aan het bouwen.
Ik doe dat in de vorm van twee plugins voor fckeditor.
De werking is als volgt:
Iedere keer als een redacteur een afkorting aan een tekst toevoegt wordt deze tegelijkertijd toegevoegd aan een tabel in de database. Een vergelijkbare actie vindt plaats als de betekenis van een reeds ingevoerde afkorting wordt gewijzigd.
Ook is het mogelijk dat een afkorting meerdere betekenissen heeft.
Met behulp van een andere plugin kan een document worden doorlopen op de aanwezigheid van bepaalde afkortingen. Een redacteur moet dan steeds aangeven of een afkorting moet worden toegevoegd (vergelijk dat met de gebruikelijke zoek- en vervang dialogboxen).
Momenteel ik hiervoor wat aan het prutsen met het zogenoemde Knuth-Morris-Pratt-algoritme (zie: http://en.wikipedia.org/wiki/Knuth%E2%80%93Morris%E2%80%93Pratt_algorithm).
Ik heb dit nog niet helemaal naar mijn zin.
Het voordeel van deze werkwijze lijkt mij dat er geen noemenswaardige extra werkzaamheden hoeven te worden uitgevoerd bij het beheer van de lijst met afkortingen.
Uiteraard wordt in het CMS een voorziening ingebouwd waarmee CRUD-acties op die lijst kunnen worden losgelaten. - 9 Robert van Egmond op 06-11-2008 om 13:13 uur:
- Nog een praktisch punt:
Hoe tag je een meervoudsvorm van een afkorting?
Een voorbeeld: "CMS'en".
Deze term wordt veel gebruikt, bijvoorbeeld op http://www.frankwatching.com/archive/2008/05/24/zijn-cmsen-klaar-voor-web-20/
Ik kan twee manieren voor het taggen bedenken:
1] ...<abbr title"content management systeem>CMS</abbr>'en ...
2] ...<abbr title"content management systemen>CMS'en</abbr>...
Het verschil zit in wat er binnen de tag staat en de inhoud van het title-attribuut.
Maar... wat is de beste en/of juiste manier? - 10 Koen Willems op 06-11-2008 om 19:16 uur:
- Wat mij betreft optie 1]
Immers, de afkorting is 'CMS', terwijl de toevoeging 'en' bedoeld is om de meervoudsvorm aan te duiden.
Het ABBR is bedoeld om een afkorting mee aan te duiden, zie ook http://www.w3.org/TR/REC-html40/struct/text.html
Trouwens, in dit concrete voorbeeld kun je nog een extra variant bedenken als je uitgaat van de Engelstalige variant 'content management system'. Dan mag je de taalwisseling ook nog aanduiden.
:-) - 11 Sander A op 06-11-2008 om 21:07 uur:
- @Koen:
Je laatste opmerking roept een andere vraag op: slaat de taalaanduiding op de content van het element of op die van het title-attribuut? En aanvullend: dient de taalaanduiding gebaseerd te worden op de gewenste uitspraak of op de taal waartoe de betreffende content deel van uitmaakt?
"Management" is inmiddels ook een Nederlands woord, maar wordt nog steeds op een Engelse manier (sort of) uitgesproken. Een goede spraaksynthesiser kan daar dan ook mee overweg. Er zijn echter ook gevallen waarbij dat waarschijnlijk niet het geval is. Is het dan toegestaan om de taal aan te duiden waarop de uitspraak gebaseerd is?
En wat als, net als bij Content Management System, een afkorting hebt die gebaseerd is op een Engelse term , maar waarvan de afkorting in het Nederlands wordt uitgesproken?
Het hangt er dan feitelijk vanaf of de evt. screen reader het title attribuut voorleest of de afkorting. Volgens mij is dit een instelling die de gebruiker zelf in de meeste gevallen kan kiezen.
Zou lang misschien ook een CSS-property moeten worden?<p lang="nl">Content <span style="lang: en;">Management</span> Systeem</p>
Of zo:<abbr lang="en" title="Cascading Style Sheets"><span lang="nl">CSS</span></abbr>
Hmmm...