Onlangs woonde ik een presentatie bij over digitale toegankelijkheid volgens de WCAG en de 🇪🇺 European Accessibility Act (EAA). Iedereen, inclusief mensen met een beperking🧑‍🦯, moet zonder drempels onze digitale producten kunnen gebruiken. Dat lijkt me logisch, en dat wordt binnenkort zelfs een wettelijke eis! ⚖️

Ik had hier zelf nog nooit bij stilgestaan, maar het blijkt in praktijk een kleine moeite om een groot verschil te maken: 🏆

👉 Vergroot de tekst in je browser of telefoon eens naar 150% of zelfs 200%. Wat doet dat met je layout? ✅ Zorg dat alles leesbaar en toegankelijk blijft voor slechtzienden.

👉 Loop je (web) app eens door met een screen reader. Kun je alle elementen herkennen en makkelijk navigeren? ✅ Zo maak je je app bruikbaar voor iedereen.

In de WCAG standaard staan hiernaast heel veel suggesties die het gebruik van (web) apps voor iedereen gemakkelijker maken. Een bron van UX inspiratie voor iedereen om eens doorheen te bladeren. 🌐

Omdat ik voor het vinden van bezienswaardigheden 🏛️ en goede eetgelegenheden 🍽️ regelmatig gebruik maak van Google reviews, deel ik zelf al jaren mijn ervaringen voor anderen. Zo ben ik in Google Maps langzamerhand opgeklommen tot een “Local Guide” van (bijna) niveau 8, met onder andere ruim een miljoen fotoweergaven.

Om dit bij te houden ga ik er soms even voor zitten om korte reviews ✍️ te schrijven, foto’s 📷 te uploaden en simpele vragen ✅ te beantwoorden over de plaatsen waar ik ben geweest. Hierbij is het telkens weer fascinerend hoe goed Google weet waar ik allemaal ben geweest.

Maar deze week gebeurde er iets vreemds: Ik kreeg vragen over een bedrijf waar ik een paar weken geleden slechts met een bemiddelaar over heb (gebeld en) gemaild. 🕵

🤔 Zou Google werkelijk mijn emails en fysieke locatie combineren tot een (hallucinante) nieuwe werkelijkheid?

Stop dus met fantaseren 🦄, en begin met bouwen! 🚀

Ken je dat? 🤔 De harde eis dat er eerst een volledige specificatie 📚 moet zijn voor we “veilig” aan de realisatie kunnen beginnen? Bij een van mijn klanten lag er na een jaar zwoegen een enorme berg documentatie, waar zelfs de auteurs het overzicht kwijt waren 😅. – Wat zouden we ook alweer bouwen?

Het probleem: te veel tijd in plannen, te weinig tijd in de praktijk. Documentatie is waardevol, maar alleen als het project vooruit gaat. Analyseren blijft belangrijk, maar er komt een punt waarop je gewoon moet starten met bouwen! Door direct aan de slag te gaan, leren we sneller en ontdekken we vroegtijdig wat werkt (en wat niet) 💡.

Een paar tips om te voorkomen dat je in analyse blijft hangen:

1️⃣ Bouw al vroeg prototypes of (beter nog) een “minimum viable product”: Laat iets tastbaars te laten zien in plaats van alleen een wolk van mooie woorden. 📦

2️⃣ Werk iteratief: Bouw en test in korte cycli; en gebruik elke stap om feedback te verzamelen en te leren. ♻

3️⃣ Betrek de echte gebruikers: Schrijf geen ellenlange rapporten en bouw geen mockups, maar toon regelmatige demo’s van het echte product en voer inhoudelijke gesprekken over wat de gebruikers nodig hebben. 🎬

Eindresultaat? Een beter product, in minder tijd. Dus… waar wacht je nog op? Tijd om te bouwen! 🛠️

Open-source code gebruiken is verleidelijk makkelijk: even iets van GitHub plukken, en voilà! 🍄 Maar niet elke open-source licentie komt zonder verplichtingen. Sommige licenties zijn “besmettelijk” ☢️. Als je code met zo’n licentie in je project opneemt, kunnen “copyleft” licentie-eisen inhouden dat je mogelijk jouw eigen code openbaar moet maken.

De bekendste besmettelijke licenties zijn:

☢️ GNU General Public License (GPL)
☢️ Affero General Public License (AGPL)

Voeg je code met een van deze licenties toe aan je eigen project, dan kunnen de licentie voorwaarden zich uitbreiden naar jouw code. Niet ideaal als je werkt aan een commercieel product. 💣

Gelukkig valt veel open source code onder een van de populaire “permissieve” licenties 🌈, die veel minder eisen stellen:

🌈 MIT-licentie
🌈 Apache-licentie 2.0
🌈 BSD-licentie

Met deze licenties kun je de code (meestal) zonder zorgen gebruiken en aanpassen.

Tips om problemen te voorkomen: 🛟

1. Check altijd de licentie voordat je een library toevoegt of kopieert.
2. Twijfel je? Win dan juridisch advies van experts in.
3. Zoek alternatieven: Die zijn er meer dan je verwacht.
4. Gebruik tracking tools zoals FOSSA, Snyk of Black Duck geven je automatisch inzicht in de gebruikte licenties binnen je project.

Open source is een geweldige bron, maar kent zijn eigen regels. Voorkom verrassingen door licenties serieus te nemen. Zo blijf je een hoop werk en stress bespaard. 💣

Meten is weten! 📈

Het aantal producten waar ik aan mee heb mogen werken is inmiddels vrij groot.🏅 Maar het aantal projecten hiervan met zichtbare sturing op de directe doelstellingen is helaas bedroevend laag. 🤔

En nee, ik bedoel hiermee niet nutteloze metrieken als”velocity” 🚲 of afgewerkte user stories 🗑️. Ik heb het over concreet meetbare doelstellingen voor het resulterende product 📦, en in hoeverre hier voortgang in wordt gemaakt.

Een voorbeeld hiervan is een project waar we met een klein team een “recommender” voor films herbouwden. 🏗️ Hierbij besloten we om vanaf het begin de kwaliteit van de aanbevelingen te meten, en alles ondergeschikt te maken aan het doorlopend opdrijven van die waarde. 📈

💡 De eerste sprint leverde een meetmethode op basis van data uit een bekende externe filmdatabase, en als eerste implementatie een willekeurige 🎲 keuze uit de beschikbare titels. De score was voorspelbaar dramatisch, maar de infrastructuur hiermee aanwezig met een “aanbeveling” als product resultaat. 🎯

Daarna werd het fascinerend: 🧐

Door het meten van elke verbetering van onze algoritmen, ontdekten we dat de briljante ideeën uit het verleden helemaal niet zo’n geweldige impact op het resultaat hadden. 📉 En voor sommige oplossingen bleek de impact op de performance al helemaal de verbetering niet waard te zijn. 😳

Het eindresultaat van het project was een veel eenvoudiger oplossing met een gemeten betere functionaliteit dan de vorige implementatie. 🏆