Waarom gebruiken zoveel Nederlandse overheden PDF-bestanden ondanks de vele nadelen? Overheid: Stop ermee!
Overheidswebsites staan er vol mee: PDF-bestanden! Rapporten, verslagen, begrotingen of formulieren, bijna allemaal in PDF. Wordt het niet eens tijd dat overheden het overmatige gebruik van PDF-bestanden indammen?
De Britse overheid publiceerde in juli 2018 een artikel met de titel ‘Why GOV.UK content should be published in HTML and not PDF’. De Nederlandse overheid kan op dit gebied veel leren van het Verenigd Koninkrijk. Waarom gebruiken zoveel Nederlandse overheden PDF-bestanden ondanks de vele nadelen? Wat zijn de argumenten voor en tegen en wat zijn de alternatieven?
‘PDF, dat moet toch van de Webrichtlijnen en het archief?’
PDF-bestanden zijn handig. Iedere computer, tablet of smartphone kan deze bestanden openen omdat het (in de meeste gevallen) een open bestandsformaat is. De PDF-bestanden zien er ook nog eens altijd hetzelfde uit. Geen verspringende kopjes of gekke opmaak, zoals je bij andere bestanden nog wel eens ziet. PDF-bestanden zijn ook nog eens relatief eenvoudig te maken.
Er wordt vaak gedacht dat voorleessoftware voor mensen met een visuele beperking goed overweg kan met de meeste PDF-bestanden, maar hier gaan vaak nog dingen mis met de verkeerde PDF-standaard of een slechte structuur. Dit is van belang om iedereen toegang te geven tot overheidsinformatie, conform de WCAG 2.1 (de opvolger van de Webrichtlijnen). We horen ook vaak dat PDF een veilig bestandsformaat is om te publiceren omdat ‘PDF-bestanden niet aanpasbaar zijn’. Tot slot zou het archief PDF-bestanden vereisen voor duurzame opslag en staat PDF op de ‘pas toe of leg uit’ lijst van het Forum Standaardisatie. We hoorden deze argumenten vaak bij het publiceren van de verkiezingsuitslagen in een herbruikbare variant. Het ministerie van Binnenlandse Zaken vroeg gemeenten csv-bestanden te publiceren, maar een groot deel van de gemeenten maakte er een PDF-bestand van.
PDF als gedigitaliseerd papier
PDF-bestanden zijn inderdaad lastiger aan te passen dan Microsoft Word of Microsoft Excel bestanden, maar met een PDF-editor is het zeker nog steeds mogelijk om dingen aan te passen. Belangrijker is dat het moeilijkere aanpassen van documenten een groot nadeel is. Wanneer gebruikers van overheidsinformatie gestructureerde teksten goed willen analyseren of cijfers uit tabellen willen combineren, dan is dit met een PDF-bestand erg tijds- en arbeidsintensief.
Wanneer je informatie vanuit een PDF-bestand kopieert en plakt, weet je dat dit vaak niet goed gaat. De letters verspringen, kopjes komen niet mee en het ziet erg onoverzichtelijk uit. Een data-analist of programmeur wordt er al helemaal ongelukkig van: het komt voor dat je duizenden datapunten wilt analyseren en er bijna niets anders op zit dan de getallen overtypen, met alle mogelijke menselijke foutjes die daarbij komen kijken.
Voorbeeld: bovenste afbeelding is een screenshot van een publicatie van het ministerie van Defensie en de politie over documentfraude. Bij het overnemen van de tabel krijg je het onbruikbare te zien, wat het tweede plaatje laat zien.
Tim Berners-Lee, een van de grondleggers van het internet, geeft het PDF-bestand daarom ook maar 1 van de 5 sterren in zijn Five Star Open Data-Model, vanwege de slechte herbruikbaarheid. Zolang een overheid op de eigen website het originele aanpasbare bestand blijft aanbieden, is het niet nodig om PDF-bestanden te publiceren.
Ook het archief of de Webrichtlijnen vereisen geen PDF-bestanden omdat er ook andere bestandsformaten functioneren met voorleessoftware of duurzame toegankelijkheid in het archief. Het Forum Standaardisatie noemt dan ook andere aanbevolen standaarden zoals HTML en CSS voor website opmaak, maar ook XML of CSV voor het publiceren van bestanden. Een rapport kan op een website gepubliceerd worden in een HTML-variant, waarbij de optie wordt gegeven op automatisch een PDF-versie te genereren. De ‘pas toe of leg uit’ standaard sluit dus geenszins uit om op andere wijze te publiceren. De ‘pas toe of leg uit’ standaard sluit geenszins uit om op andere wijze te publiceren, maar het is zowel bij PDF en HTML zaak om zorg te dragen voor toegankelijkheid voor iedere doelgroep. Dit kan bij beide bestandsformaten fout gaan.
Ook de op het eerste gezicht positieve kanten van PDF-bestanden, zijn eigenlijk nadelen. Zoals dat PDF op elk scherm hetzelfde weergegeven wordt. De Britten schrijven hierover terecht dat PDF-bestanden niet responsive zijn en dus niet meeschalen naar je schermgrootte. Steeds meer websitebezoekers gebruiken een smartphone of tablet. Wanneer je via een website naar de informatie wilt kijken, schalen teksten en afbeeldingen mee naar jouw schermgrootte.Met een PDF-bestand gebeurt dat niet. Dit maakt het lezen van een PDF-rapport tot een exercitie van geduld met veel in en uitzoomen op je telefoon.
PDF-bestanden lijken kortom erg op papieren rapporten uit het pre-digitale tijdperk. We slaan een bestand op en exporteren het naar het PDF-formaat en vervolgens hebben we een bestand dat geschikt is om uit te printen of om offline te gebruiken. Maar dit is niet hoe mensen het internet gebruiken of optimaal gebruik kunnen maken van alle digitale methoden die voorhanden zijn. Via websites zijn veel krachtigere methodes om informatie te structureren, interactieve visualisaties toe te voegen of informatie te doorzoeken.
De Washington Post kopte in 2014 al ‘The solutions to all our problems may be buried in PDFs that nobody reads’. Het downloaden en openen van een PDF-bestand vormt een overbodige drempel. Uit informatie van de Wereldbank is ook gebleken dat de meeste PDF-rapporten van hun website nooit geopend zijn. Jaarlijks besteden we miljoenen euro’s aan rapporten door onderzoeksbureaus, maar de kans dat deze rapporten doorgenomen worden, is relatief klein. Het is ook lastig na te gaan welke informatie in een PDF-bestand nuttig is omdat alleen downloadstatistieken van het hele bestand inzichtelijk zijn en niet van individuele onderdelen. Ook zijn PDF-bestanden lastiger te updaten. Op het moment informatie geactualiseerd dient te worden, moet het gehele bestand vervangen worden, in plaats van een onderdeel.
Maar wat moeten we dan zonder PDF?
De Britse overheid suggereert in plaats van PDF het gebruik van HTML, ofwel webpagina’s. Webpagina’s schalen mee met de schermgrootte van de gebruiker en bieden de mogelijkheid om informatie in gestructureerde pagina’s met interactieve content te plaatsen. Wanneer er tabellen of grafieken getoond worden, dan kunnen deze interactief zijn en kan ook een link aangeboden worden naar de ruwe data in bijvoorbeeld een .csv bestand of een API.
Zo heeft het Planbureau voor de Leefomgeving met behulp van de tool Colophon een rapport dat ze voorheen in PDF-vorm zouden publiceren, in een interactieve HTML-pagina gepubliceerd. Het is nog steeds mogelijk om het rapport in PDF-vorm te downloaden. Ook uitvoeringsorganisatie KOOP (Kennis- en Exploitatiecentrum voor Officiële Overheidspublicaties) gebruikt op wetten.overheid.nl en officielebekendmakingen.nl diverse bestandsformaten. Regelgeving wordt in gestructureerde HTML-vorm aangeboden met verwijzingen naar genoemde artikelen en voorheen geldende regels. De bestanden zijn eveneens te downloaden in gestructureerde XML-vorm, maar ook weer in PDF voor de liefhebber. Steeds meer overheden publiceren gelukkig ook begrotingen en jaarverslagen in interactieve webversies.
Voor cijfermatige informatie of ruwe data is het geen goed idee om in PDF te publiceren en is ook het gebruik van HTML niet praktisch. Daarbij kan ook weer het Five Star Open Data Model toegepast worden dat aanraadt om bestanden dan in bijvoorbeeld .csv formaat te publiceren, een open en gestructureerd bestandsformaat. Met de Wet hergebruik van overheidsinformatie heeft de samenleving ook een recht gekregen om gestructureerde informatie die in PDF-bestanden opgesloten zit, in een herbruikbaar bestand op te vragen.
Voor het overzicht hebben we wat veel voorkomende publicaties van de overheid op een rijtje gezet met een suggestie voor publicatie die praktischer is dan PDF:
| Bestand | Hoe aanbieden? | Waarom? |
| Onderzoeksrapporten | HTML | Biedt de mogelijkheid voor snel doorzoeken, schaalt mee met het device van de lezer | |
| Cijfers (data) | CSV | Kunnen ook machines lezen en analyseren | |
| Begrotingen | HTML, CSV | Hierbij is het van belang dat mensen het op verschillende schermen kunnen lezen (HTML), en de data kunnen analyseren (CSV) | |
| Formulieren | HTML | Wanneer mensen formulieren goed kunnen lezen en invullen, scheelt dat werk in het uitprinten en weer inscannen van (moeilijk leesbare) tekst | |
| Officiële besluiten | HTML | Biedt de mogelijkheid voor snel doorzoeken, schaalt mee met het device van de lezer |
Aan de slag
Het overstappen van PDF naar HTML of andere gestructureerde bestanden, vereist een omslag in denken. Overheden denken nu in statische documenten, maar moeten meer in gestructureerde data gaan denken. Daarvoor hoeven ze niet allemaal programmeurs te worden, maar leren om gebruik te maken van handige webtoepassingen of tools, deze lijst van digitale publicatietools of de reguliere functionaliteiten van het CMS. Deze informatie wordt ‘onder water’ in gestructureerde vorm opgeslagen en kan als gestructureerde informatie op een website gepubliceerd worden, zonder gebruik te maken van PDF bestanden.
Staatssecretaris Knops van Binnenlandse Zaken heeft een grote ambitie voor de digitale overheid. Hij zou zich daarom moeten uitspreken voor het toegankelijk maken van overheidsinformatie via andere wegen dan het PDF-bestand en kan daarbij de visie van de Britse overheid als leidraad nemen. Het recent opgerichte Leer en Expertisecentrum Datagedreven Werken, onderdeel van het ministerie van Binnenlandse Zaken, en het Forum Standaardisatie kunnen hierbij ondersteuning bieden en voorlichting geven. Overheden dienen ook zelf actie te ondernemen. De webredacties, IT- en communicatie-afdelingen staan aan de lat om de organisatie van bruikbare tools en informatie te voorzien om bij te dragen aan deze cultuuromslag.
Kortom: overheid, stap af van PDFs en wordt gebruiksvriendelijker. Dit doe je niet alleen voor de mensen die jullie informatie eenvoudig(er) willen vinden, interactief willen ervaren en op verschillende schermen willen gebruiken, maar ook voor de machines die we moeten gaan gebruiken bij het aanpakken van maatschappelijke uitdagingen.
Tom Kunzler is adjunct-directeur van de Open State Foundation
Deze bijdrage is in nauwe samenwerking tot stand gekomen met Lisette Kalshoven, senior projectmanager bij de Open State Foundation.
Goed dat dit onderwerp onder de aandacht gebracht wordt. Ik hoop dat het mensen aan het denken zet over het publiceren van informatie of diensten in pdf.
Ik ben het er zeer mee eens dat je eerst moet nadenken over wat het doel is van informatie en hoe je het best aansluit bij mensen en software die deze informatie wil gebruiken.
De vraag welk bestandsformaat geschikt is wordt vaak niet gesteld omdat pdf zo makkelijk lijkt. Als je de vraag wel stelt is het antwoord niet ‘pdf’.
Het artikel bevat nog wat onjuistheden. Ik geef graag wat aanvullingen.
In het artikel staat dat pdf-bestanden ‘in de meeste gevallen een open bestandsformaat is’. Ik ben benieuwd naar de onderbouwing. Veel pdf’s zijn geen open bestandsformaat of voldoen niet aan de eisen hiervoor.
Ook staat er dat ‘voorleessoftware voor mensen met een auditieve beperking goed overweg kan met de meeste pdf-bestanden’. Voorleessoftware wordt echter niet gebruikt door mensen met een auditieve beperking, maar mensen met een visuele beperking of bijvoorbeeld mensen met dyslexie. De groep mensen met een functiebeperking die baat heet bij een toegankelijke pdf is echter veel groter dan de gebruikers van voorleessoftware. En daarom zijn oplossingen vaak niet volledig. Het gaat ook om mensen met een motorische beperking, kleurenblinden (heel veel problemen in pdf), mensen die doof zijn en voor wie Nederlands niet de moedertaal is, mensen die spraakbediening gebruiken, mensen met een kort werkgeheugen, mensen die autistisch zijn et cetera.
Met een functiebeperking kun je niet ‘goed overweg met de meeste pdf-bestanden’. We hebben voor verschillende (ook grote) overheden een audit gedaan om alle pdf’s te analyseren, geautomatiseerd en deels handmatig. We kwamen geen bestand tegen dat aan alle eisen voldoet. (Een ander probleem is dat veel pdf’s onbekend zijn bij de organisatie, een extra reden om grip te krijgen op informatie die nu als pdf aangeboden wordt).
Het probleem met het voorbeeld van de tabel in de publicatie op rijksoverheid is dat deze niet opgemaakt is als een tabel. Het probleem is hier niet pdf zelf, maar het gebrek aan resources om een goede tabel en een goede pdf te maken. Met andere woorden; dit illustreert niet dat pdf een slecht formaat is, maar dat de pdf niet goed opgemaakt is.
In het artikel worden de Webrichtlijnen genoemd. Deze bestaan sinds 2016 niet meer. Webrichtlijnen bevatte WCAG 2.0 en Principe Universeel. Inmiddels is WCAG 2.1 de standaard. Belangrijk is ook om te noemen dat je bij inkoop rekening moet houden met toegankelijkheid.
Het Forum Standaardisatie noemt ook digitoegankelijk (EN 301 549 en WCAG 2.1) als standaard (https://www.forumstandaardisatie.nl/standaard/digitoegankelijk-en-301-549-met-wcag-21). Daarnaast is er nu ook wetgeving voor digitale toegankelijkheid. En pdf’s die wel aan WCAG 2.1 AA voldoen, zijn beter bruikbaar. De standaard EN 301 549 kun je gebruiken bij inkopen. Met de wet en de daarin genoemde toegankelijkheidsverklaring wordt gestuurd op het grip krijgen op toegankelijkheid. Inkoop speelt hierbij een belangrijke rol.
Pdf-bestanden die aan WCAG 2.1 AA voldoen zijn wel aanpasbaar. In bijvoorbeeld Acrobat Reader op computer, tablet of mobiel kun je dan een pdf, mits toegankelijk, weergeven in 1 kolom of met een andere kleurstelling.
Ik mis EPUB nog in het artikel. Dit bestandsformaat biedt ook veel mogelijkheden.
Er zijn meer manieren om data uit een pdf te exporteren. Knippen en plakken lijkt me niet de beste manier. Daarmee wil ik niet zeggen dat het me het meest geschikte bestand lijkt voor uitwisselbare data.
Gezien het belang van bruikbare, herbruikbare en toegankelijke informatie vind ik de voorbeelden van het Planbureau voor de Leefomgeving (Colophon) en de Gemeente Berg en Dal geen goede voorbeelden. Ja, het is HTML. Maar in beide gevallen is geen aandacht besteed aan een goede semantische opbouw van informatie en toegankelijkheid. Er zijn erg veel obstakels voor mensen met een functiebeperking.
Overstappen van pdf naar HTML heeft alleen zin als we niet van de regen in de drup komen. Als je als overheid naar iets anders overstapt, zorg dan dat gelijk dat je een toegankelijke product of dienst inkoopt. Gebruik hiervoor de genoemde standaarden. Zorg dat je grip hebt op de kwaliteit. Dit scheelt veel kosten achteraf en voorkomt dat je kan voldoen aan wetgeving.
Overheden moeten inderdaad aan de slag. En pdf is vaak niet het juiste formaat of werpt een extra hindernis voor de gebruiker op. Maar ook bij HTML moet je zorgen voor grip en kwaliteit. En als je pdf’s maakt, zorg dan ze toegankelijk voor iedereen zijn. Een omschakeling vraagt analyse en aanpak van processen. Vaak wordt nog op documentniveau gedacht.
PDF en PDF-A is bedoeld om documenten inclusief alle bijbehorende technische onderdelen te bewaren. Als je over 50 jaar een PDF-A opent, dan zal dit precies zo tonen als nu: omdat de lettertypen erin werden bewaard. Altijd handig als je bijvoorbeeld formules wilt kunnen lezen in de lettertypen zoals ze 50 jaar geleden werden gemaakt. PDF-A is daarom duurzaam en geschikt voor langdurige opslag en ontsluiting. Dat kunnen we van HTML en andere webformaten helaas niet zeggen.
Op het moment dat we dit lezen is er alweer iets veranderd aan de standaarden. Open je over 50 jaar een HTML-pagina, dan mag je van geluk spreken als het desbetreffende lettertype nog op je werkplek bestaat – om nog maar te zwijgen oven een webbrowser die al het oude nog goed ondersteunt. Webinformatie is opgebouwd uit een grote hoeveelheid elementen, zoals stylesheets, graphics en software zoals javascript. HTML (Hyper Tekst Markup Language) is helemaal niet bedoeld voor het presenteren van informatie. Bestaat er een element van je document niet in het document zelf, dan is de kans op informatieverlies groot.
Er is geen enkel bestandsformaat waarbij aanpassing achteraf onmogelijk is. Willen we dat voorkomen, dan mogen we denken aan encryptie – waarbij we ook goed moeten blijven nadenken over het ontsleutelen in 2075 met de hulpmiddelen van “toen”. Ten slotte: We willen in deze moderne tijd “beelden” zien met de analyse van data: grafieken, puntenwolken, verschillen in staafdiagrammen. Dat gaat met CSV niet lukken: “Comma Separated Values” is een oud bestandsformaat waarin je alleen tekst kan opslaan en een scheidingsteken zoals een tab of een komma, toentertijd de lastig schaalbare voorloper van tabellen in relationele databases en objectnotatie met XML.
We mogelijk ons trouwens wel druk maken over het kunnen ontsluiten van interactieve informatie van nu – over 50 jaar: PDF en PDF-A zijn hiervoor nog niet toereikend. De oplossing voor het exact kunnen reproduceren van historische informatie met beeld, geluid en interactie is het bewaren van de programmatuur, de onderliggende besturingssystemen, alle ondersteunende hardware en in het meest extreme, risicomijdende geval: de onderliggende netwerkinfrastructuur. “Open” zal dit met terugwerkende kracht nooit worden. Open standaarden voor opslag en ontsluiting van onze toekomstige, digitale interactieve historie is wat dat betreft onontbeerlijk – waarbij we de eenvoud niet uit het oog mogen verliezen.
@Iacobien en Marcel, dank voor jullie reacties.
@Iacobien, dank voor de nuttige aanvullingen. Ik zal een aantal zaken laten wijzigen in het artikel die je terecht aangeeft die niet helemaal kloppen (die zijn inmiddels aangepast, Red.). Het klopt inderdaad dat PDF lang niet altijd voldoet voor al het publiek en HTML ook niet altijd. Ik ben geen expert op deze onderwerpen, maar heb geleerd van jouw reactie hierop. Erg fijn.
@Marcel, er is in mijn ogen een verschil tussen informatie die je voor nu wil ontsluiten en de vraag hoe je die informatie in de toekomst ook nog zo bruikbaar mogelijk houdt. Wellicht dat een bepaalde PDF-standaard prettig is voor het visualiseren van dit document over 50 jaar. Maar dat sluit niet uit dat voor hedendaagse gebruikstoepassingen op het internet PDF lang niet altijd het primaire of geëigende formaat dient te zijn. Het zou ook niet of/of moeten zijn, maar kan en/en zijn. Dus ontsluit voor nu de informatie in een goed toegankelijke webpagina, aangevuld met andere bestandsformaten die te downloaden zijn en biedt daarnaast voor evt. duurzame opslag (al kan dat ook anders dan PDF) of voor mensen die offline willen lezen of willen printen een downloadknop naar PDF aan. Hiermee kan je aan beide voorwaarden voldoen. En met betrekking tot CSV en XML. Dat zijn juist handige formaten net als JSON om tekstuele maar ook cijfermatige informatie op te slaan. Deze bestanden kunnen de bron zijn voor visualisaties of tabellen die deze bestanden als database gebruikt.
Graag maak ik een paar kanttekeningen:
Het valt niet mee om met een boot over de snelweg te rijden, maar dat maakt niet dat je zomaar alle boten kunt afschaffen. Wat ik bedoel: er is geen universeel bestandsformaat. Vanuit de bron van de informatie zou je meerdere publicatieformaten moeten willen aanbieden, voor verschillende doelen.
De titel van het oorspronkelijke stuk was: ‘Why GOV.UK content should be published in HTML and not PDF’. Precies! Op het web verdient HTML de voorkeur, zeker als het gaat om real time actuele informatie. Maar dan wel goede HTML. Een responsive site die geschikt is voor slechtzienden is niet 1-2-3 gebouwd.
Het verbaast mij dat een lans wordt gebroken voor csv. Waar het gaat om herbruikbare open data is XML een open standaard met veel meer mogelijkheden dan csv.
Een PDF bestand kan niet alleen digiaal duurzaam gemaakt worden, maar ook worden verzegeld met een digitale handtekening zodat verifieerbaar is of het bestand nog in originele staat is.
@Rein
Dank voor je reactie. Je hebt helemaal gelijk dat vanuit de bron meerdere formaten moet aanbieden. Dat benoem ik ook met een aantal voorbeelden. Het stuk is vooral bedoeld om te denken te geven om niet standaard te resorteren naar PDF omdat er voor verschillende doeleinden veel nadelen aan kleven en ik nog steeds zie dat veel overheden uit automatisme PDF only publiceren.
M.b.t. CSV en XML heb je helemaal gelijk. Wij zijn bij Open State Foundation eigenlijk zelfs meer fan van JSON dan van XML omdat JSON meer human-readable is. Maar we zien in de praktijk dat cijfer/databestanden die bij publicaties op het web gepubliceerd worden vaak relatief eenvoudig zijn (plat) en geen geneste structuren nodig hebben waarvoor JSON/XML veel geschikter is. Het voordeel van CSV is dan weer dat het een toegankelijker formaat is voor een grotere doelgroep dan XML of JSON.
Een mooi en duidelijk artikel, waar ik een paar dingen onduidelijk vind.
Voor publicaties heeft het forumstandaardisatie PDF versie 1.7 genoemd.
De “A” versies zijn bedoeld voor archivering.
Verder is er in het eindresultaat een groot verschil tussen een PDF gemaakt vanuit een stuk software en een gescande versie.
Een PDF gemaakt vanuit een stuk software is in de regel ook te gebruiken met knippen en plakken, een voorlees programma zou daar (mogelijk) mee overweg kunnen.
Een gescande PDF is eigenlijk een grafische afbeelding en is (meestal/vaak) niet geschikt voor knippen en plakken, mogelijk dus ook niet om voor te lezen.
Het maken van een responsive website is een éénmalige klus, waarna je alleen in de gaten hoeft te houden, dat de gepubliceerde pagina’s aan de gebruikte standaard voldoen.
Verder wordt er ook de WCAG 2.1 genoemd.
Hierin worden ook de HTML standaarden genoemd, zoals deze worden bepaald en beheerd door het W3C (World Wide Web Consortium, waar Logius zitting in heeft).
Hoe kan het dan zijn, dat zoveel websites van vooral lagere overheden, samenwerkingsverbanden en gemeenschappelijke regelingen er zo een puinhoop van maken.
Regelmatig controleer ik een website met de validator van het W3C, de meeste Rijks-website geven hier geen fouten mee.
Bij de lagere overheden is een foutloze HTML zelfs een uitzondering geworden.
Het record, dat ik ooit gevonden heb, was een website van een samenwerkingsverband, waar per pagina ruim 170 syntax fouten in zaten.
Hebben deze mensen dan geen opleiding gehad?
Vaak schrijf ik een (semi-)overheid aan, over het gebruik van verplichte OpenStandaarden, volgens de pas-toe-of-leg-uit lijst.
Het is zelfs een keer voorgekomen, dat ik per email een antwoord kreeg van het hoofd ICT van een gemeente, met de tekst in een .DOC file als bijlage.
Dit terwijl de vuistregel is, dat een gesloten file formaat (b.v. DOC, DOCx, XLS, XLSx, e.d.) nooit de voordeur mag passeren, (semi-)overheden zijn verplicht ook onderling in OpenStandaarden te communiceren.
Helaas wordt er binnen de overheid en gesubsidieerde instellingen veel te weinig publiciteit gegeven aan deze verplichting.
Waar komen de PDF’s oorspronkelijk vandaan? Dat is veelal van de Word tekstverwerker of Excel. Dat is onderdeel van het tekstproductieproces van een beleidsambtenaar. Het is dus nodig om al bij de bron verandering te bereiken. Ook al omdat weinigen in Word b.v. de outline functie gebruiken of hoofd- en subdocument, waarmee meer structuur in het document komt.
Een mogelijkheid is om teksten in Markdown formaat op te stellen. Ik heb goede ervaringen met typora.io/, een editor die veel praktische belemmeringen al heeft opgelost. Zo kan je alle afbeeldingen (assets) automatisch in een submap plaatsen, zodat de gehele informatie-eenheid zelfstandig kan bestaan. Het is even wennen dat de pagina-oriëntatie (kop/voetregel, paginanummers) niet ondersteund wordt.
Productie van teksten zou dus fundamenteel in een ander formaat moeten gebeuren. Zo zou een echt goed raadsinformatiesysteem de auteurs van raadsvoorstellen moeten faciliteren om vanuit een combinatie van blokken tekst en database-gegevens (behandelschema, betrokkenen, metadata) de raadsvoorstellen in een HTML-formaat te genereren.
Sinds 2012 publiceren wij geheel digitaal, via een semantische wiki: http://www.NORAonline.nl
Onze (architectuur-)afspraken en kennis en ervaring met het ontwerp van de dienstverlening van de overheid kunnen we op die manier eenvoudig met elkaar delen en samen onderhouden. Een paar regels wijzigen om ons verhaal op een specifiek onderdeel aan te vullen is erg eenvoudig en alle historie wordt automatisch bewaard.
Je kunt later de teksten nog met elkaar vergelijken.
Je kunt de teksten desgewenst omzetten naar een pdf.
Soms nemen we pdf’s op in de wiki, omdat de informatie alleen in dat formaat wordt aangeboden.
Maar als we mogen kiezen, dan wordt het een stukje tekst dat altijd vatbaar is voor verbetering en actualisatie !
Continu beta, zoals dat tegenwoordig heet
:-)
In het artikel en in de reacties erop staat niets over online- en offline-beschikbaarheid van documenten. Ik vind het prettig als documenten ook offline te lezen zijn. Kan dat bij HTML ook?
Er is hiervoor een nieuwe en makkelijke oplossing!
Smart-Assist maakt Pdf-documenten 1 op 1 HTML toegankelijk. Upload je Pdf-document en de dienst Smart-Assist zet de informatie om in HTML. De informatie is dan direct online beschikbaar. Daarnaast kun je in de handleiding of het document je vraag stellen en Smart Assist geeft meteen het juiste antwoord.
Meer informatie, zie: http://www.qamanagers.nl/smart
Het is inderdaad heel belangrijk dat websites toegankelijk zijn, zeker die van de overheid. Op digitaaltoegankelijk.com/ staat ook veel over dit onderwerp en over toegankelijkheidsonderzoeken. Zeker de moeite waard.
Het PDF-formaat is zo dood als een pier, alleen houdt iedereen het in stand omdat het zo lastig is als je de eerste bent die een betere standaard introduceert als de wereld om je heen nog niet zover is. De scheiding tussen een hele dure editor en gratis readers met uitstekende commentaar-functies hebben de PDF-cultus gecreëerd en houden deze in stand. Ik snap dat HTML als alternatief genoemd wordt, maar dit vooral online handig. De behoefte aan offline documenten blijft. Offline kopieën zijn reuze handig voor overeenkomsten, contracten, standaarden en ander “bevriesspul”. Die wil je leesbaar en toegankelijk hebben op elk digitale apparaat wat je zoal gebruikt. En dan denk ik niet alleen aan telefoon, maar ook aan tablets en de huidige opkomst van e-inkapparaten. PDF is wat mij betreft dus een randverschijnsel, een niche voor mensen die volledige controle willen hebben over de afmeting van een plakje dode boom en hoe de inkt daar precies over verdeeld moet worden. M.a.w. als je vindt dat de inhoud van je HTML of EPUB per sé op een A4 moet, druk die dan af met een (PDF-)printer op dat formaat.
Inhoud en toegankelijkheid gaan boven opmaak (vorm volgt functie)!