Webapplicatie laten maken

Een webapplicatie is software die in de browser draait: één codebasis, bruikbaar op elk apparaat en een update staat direct voor iedereen klaar. Binnen die vorm verschillen de eisen sterk per soort toepassing. De tabel laat zien waar het ontwerp op moet letten.

Moet de toepassing in de App Store of Google Play staan, of offline in het veld werken, dan is een app misschien beter. Die afweging tussen progressive web app, native en cross-platform staat bij app laten ontwikkelen. Gaat het vooral om gegevens uitwisselen tussen systemen, kijk dan bij API-koppelingen. Lost een standaardpakket of een formulierenbouwer uw vraag al op, dan is maatwerk niet nodig en zeggen we dat.

De stack kiezen we op beheerbaarheid, niet op mode. Een webapplicatie die vijf jaar of langer meegaat, moet te onderhouden zijn door ontwikkelaars die u later zelf vindt.

• TypeScript aan de voorkant en waar het past ook op de server, omdat typen fouten vinden voordat een gebruiker ze vindt.
• Server-side rendering voor pagina's die snel moeten laden en ook zonder JavaScript leesbaar moeten zijn.
• PostgreSQL als database: open source, breed ondersteund en met PostGIS uit te breiden als er locatiegegevens bijkomen.
• Een gedocumenteerde API beschreven in de OpenAPI Specification, zodat andere systemen kunnen koppelen zonder in de code te kijken.

Voor de publieke sector is de NL API Design Rules (officieel NLGov REST API Design Rules) een verplichte standaard op de 'pas toe of leg uit'-lijst van Forum Standaardisatie. Die moet worden toegepast bij het aanbieden van REST API's die overheidsinformatie of functionaliteit ontsluiten. Bouwen we een API voor een overheidsorganisatie, dan volgen we die regels en toetsen we de API-beschrijving daar automatisch op in de buildstraat. Zit er een kaart in de applicatie, dan komt daar een eigen stack bij; die staat beschreven bij GIS- en kaartoplossingen.

Voor overheidsinstanties is digitale toegankelijkheid geen keuze. Het Tijdelijk besluit digitale toegankelijkheid overheid zegt in artikel 3, lid 1:

Overheidsinstanties maken hun websites en mobiele applicaties toegankelijk door toepassing van standaard EN 301 549.

Bron: wetten.overheid.nl, gelezen op 11 oktober 2026. Artikel 4 verplicht een toegankelijkheidsverklaring. Bevat de applicatie een kaart, dan geldt een uitzondering: artikel 2, lid 2, onder d, sluit onlinekaarten uit, mits essentiële informatie op navigatiekaarten op een toegankelijke, digitale wijze wordt verstrekt. De rest van de applicatie valt er wel onder; zie toegankelijke kaarten.

De geldende versie van EN 301 549 verwijst naar WCAG 2.1. Op 3 september 2026 is EN 301 549 versie 4.1.1 gepubliceerd, met een verwijzing naar WCAG 2.2. Die versie geldt pas als norm nadat de Europese Commissie haar heeft geharmoniseerd; een termijn daarvoor is niet bekend (Digitoegankelijk, 8 september 2026). Ons uitgangspunt is daarom om nu al tegen de succescriteria van WCAG 2.2 op niveau AA te bouwen, zodat een nieuwe norm geen herbouw betekent.

In de praktijk stellen we het volgende voor.

• alles is met het toetsenbord te bedienen, met een zichtbare focus;
• formulieren hebben labels, foutmeldingen zijn begrijpelijk en worden voorgelezen;
• kleurcontrast en tekstgrootte zijn op orde, ook bij 200 procent zoom;
• we testen met een schermlezer en niet alleen met een automatische scanner, omdat die maar een deel van de criteria kan controleren.

Voor een formeel oordeel laat u een onafhankelijke partij een onderzoek doen volgens de W3C-methode WCAG-EM. Dat onderzoek is ook de basis voor de toegankelijkheidsverklaring. Wat dit voor gemeenten betekent, staat op de pagina over software voor gemeenten.

Overheidsorganisaties hoeven formulieren, knoppen en tabellen niet voor elke applicatie opnieuw te laten ontwerpen. NL Design System is een open source verzameling design systems waarin overheden componenten delen die zijn getest op bruikbaarheid en toegankelijkheid. Een organisatie legt haar huisstijl vast als thema en gebruikt daarmee de gedeelde componenten.

Voor een webapplicatie heeft dat drie voordelen. De toegankelijkheid van de basisonderdelen is al onderzocht, waardoor testen gerichter kan. Gebruikers herkennen patronen uit andere overheidsdiensten. En een andere leverancier kan later met dezelfde componenten verder werken.

Heeft uw organisatie nog geen thema, dan kan dat onderdeel zijn van de eerste iteratie. Voor organisaties buiten de overheid is NL Design System niet verplicht, maar de componenten en richtlijnen zijn wel vrij te gebruiken. Een eigen componentenbibliotheek bouwen loont alleen als er meerdere applicaties op worden gebouwd en iemand die bibliotheek blijft onderhouden. Ontbreekt een component, dan kan een nieuw onderdeel worden teruggegeven aan de community.

Bij een webapplicatie is de inlogmethode vaak de lastigste ontwerpkeuze. Medewerkers loggen bij voorkeur in via het account dat ze al hebben, zodat een vertrekkende medewerker op één plek wordt uitgeschakeld. Voor inwoners of klanten gelden andere eisen, afhankelijk van welke gegevens ze zien.

Verder leggen we vroeg vast:

• welke rollen er zijn en wat elke rol mag zien en wijzigen;
• welke acties worden gelogd, hoe lang die logs bewaard blijven en wie ze inziet;
• welke beveiligingsheaders de server meestuurt, zoals een Content-Security-Policy die het laden van onbekende scripts blokkeert;
• hoe gevoelige gegevens in de database worden beschermd.

Als toetslijst gebruiken we de OWASP ASVS, op het niveau dat bij de gevoeligheid van de toepassing past. Voor applicaties met persoonsgegevens of een publieke inlog adviseren we een penetratietest door een onafhankelijke partij vóór de livegang. Hoe dit past in de afspraken over code en eigendom, staat bij maatwerk software.

Een webapplicatie ontwerpen begint bij de taak van de gebruiker, niet bij de schermen. Daarom werken we in deze volgorde.

1. Taken en gebruikers. Welke taak moet iemand afronden, op welk apparaat, en wat gaat er nu mis?
2. Klikbaar ontwerp. Een eenvoudig prototype dat u met een paar echte gebruikers test voordat er code wordt geschreven.
3. Bouwen in iteraties. Elke iteratie staat op een testomgeving die u zelf kunt openen.
4. Prestaties en apparaten. We spreken een laadtijdbudget af en testen op de browsers en apparaten die uw gebruikers echt hebben.
5. Livegang en monitoring. Foutmeldingen en beschikbaarheid worden gemeten, zodat problemen zichtbaar zijn voordat gebruikers bellen.

Na de livegang kijken we naar het gebruik: waar haken mensen af, welke foutmeldingen komen vaak voor? Dat bepaalt de volgende verbeteringen, niet een lijst die vooraf is opgesteld. Voor die metingen is geen tracking van individuele bezoekers nodig; geaggregeerde gegevens over fouten en afhaakpunten zijn genoeg en houden de privacyverklaring eenvoudig.

Voor een webapplicatie of app is meer nodig dan een functionele wens. Het helpt als deze zaken vroeg geregeld zijn.

• Teksten en de eigenaar daarvan: wie houdt na de livegang instructies en hulpteksten actueel?
• Huisstijl of een bestaand NL Design System-thema.
• Het domein of subdomein, en iemand die DNS-records kan aanpassen.
• Voor native apps een ontwikkelaarsaccount op naam van uw organisatie in de App Store en Google Play, zodat de app van u blijft.
• Een plek om te hosten; zie cloud- en data-infrastructuur voor de afwegingen.
• Bij een overheidsorganisatie de persoon die de toegankelijkheidsverklaring publiceert en bijhoudt.

Twijfelt u of uw vraag een webapplicatie, een app of eigenlijk een koppeling tussen bestaande systemen is, neem dan contact op. Een eerste gesprek gaat over de taak, niet over de techniek. Wat u daarvoor meeneemt, is een beschrijving van de gebruikers en een voorbeeld van hoe het nu gaat, ook als dat een papieren formulier of een e-mailstroom is.