Design Rationale voor de Meesterproef

In de Design Rationale schrijf je de debriefing, de probleemdefinitie, toon je de oplossing en schrijf je een uitleg van de code. De Design Rationale is een verantwoording van je ontwerp. Je maakt met je team één design rationale. Tip: Doe dit in de wiki van je project repo.

source - DLO

Ontsluiting van het digitale archief van Framer Framed voor een specifieke doelgroep met specifieke eisen op het gebied van toegankelijkheid. (WCAG)

Must haves:

• Toegankelijk voor Mensen met een visuele beperking (slechtziend of blind)
• Toegankelijk voor gebruikers van screenreaders of spraaknavigatie
• Moet zoveel mogelijk voldoen aan de 50 toetsingscriteria van WCAG

Nice to haves:

• Toegankelijk voor gebruikers zonder muis

Toegankelijke applicatie voor mensen met een beperking

We gaan een applicatie maken die bedoeld is voor mensen met een beperking, maar dat betekent niet dat we moeten inleveren op de styling. We ontwerpen een design dat aansluit bij de huisstijl van Framer Framed.

We maken de applicatie toegankelijk door:

• Goede semantische HTML te schrijven:

  • Zo weinig mogelijk <div>-s.
  • Gebruik maken van correcte elementen zoals <nav>, <main>, <header>, <footer>, <article>, en <section>.
  • Een logische hiërarchie in koppen met <h1>, <h2>, etc.
  • Gebruik van <button> voor knoppen en <a> voor links.

• Contrast en zichtbaarheid:

  • Voldoende kleurcontrast tussen tekst en achtergrond (minimaal 4.5:1 voor tekst).
  • Zorg dat tekst tot 200% vergroot kan worden zonder verlies van functionaliteit of layout.

• ARIA-labels:

  • Interactieve elementen moeten de correcte aria-labels hebben.

• Toetsenbordnavigatie:

  • Navigatie met het toetsenbord moet mogelijk zijn.
  • Zorg dat de :focus-toestand visueel goed zichtbaar is.

• Formulieren goed labelen:

  • Elk formulierinvoerveld moet een gekoppeld <label> hebben.

• Gebruik van "Skip links":

  • Voeg "skip links" toe om snel naar de hoofdinhoud te kunnen navigeren.

https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-data#specifications

• Site herkenbaar als een Site van Framer Framed
• Site moet aanvullende functies hebben aan de huidige site van FF
• Het doel van de site duidelijk communiceren

Het waarom en hoe

We hebben voor een paginastructuur gekozen met de huidige informatie aan de linkerkant van het scherm en diens relaties aan de rechterkant (op desktop). We hebben deze structuur gekozen omdat het heel overzichtelijk is, en in tegenstelling tot de huidige bibliograph map toegankelijk met toetsenbord. De structuur zorgt ervoor dat als je met een screenreader op de pagina gaat, eerst alle huidige informatie word opgelezen en daarna de informatie van de relaties. Dit zorgt ervoor dat je linear door kan klikken naar de verschillende pagina's.

We hebben overwogen om breadcrumbs toe te voegen voor de verschillende pagina's. Een argument tegen breadcrubs is dat site onoverzichtelijker zou voor screenreaders door de hoeveelheid links, die we tot nu toe tot een minimum hebben gehouden. Dit zou echter verholpen kunnen worden door een skiplink voor de header en breadcrumbs. We hebben deze plannen helaas niet kunnen uitvoeren doordat er niet genoeg tijd was.

Dit project is opgebouwd in liquidJS. Doordat deze taal met components werkt, worden er geen aparte pagina's gemaakt voor elk onderdeel. Dit zorgt ervoor dat de site veel lichter is gebouwd en dus makkelijker geladen kan worden met laag internet, wat een van de wensen van de klant is.

Wij hebben ons kleurgebruik geinspireerd op de kleuren van de bibliograph, met kleuren voor elk type element. Voor de kleuren zelf hebben we een kleurenblindvriendelijk kleurenpallet gebruikt, waarbij elke kleur voldoende contrast heeft met een zwarte tekstkleur. Op de site hebben wij een legenda gemaakt om dit ook naar de gebruiker te kunnen communiceren.

De routes in de back-end voor de detailpagina’s van personen, organisaties en evenementen zijn /person/:uuid, /organisation/:uuid en /event/:event. Deze routes laten niet alleen informatie zien over één specifiek item, maar ook over alles wat daarmee in verbinding staat — zoals andere personen, organisaties of events. Dat maakt het mogelijk om de onderlinge netwerken en samenwerkingen binnen het archief te tonen.

Wanneer iemand bijvoorbeeld naar een persoonspagina gaat via /person/:uuid, haalt de server de gegevens van die persoon op uit de Framer Framed API. Daarbij worden ook de relaties van die persoon opgehaald, zoals bij welke evenementen hij of zij betrokken was of met welke organisaties ze in samenwerking waren. Wat wij hebben toegevoegd aan het originele archief, is dat we niet stoppen bij deze eerste laag van relaties. We halen ook de relaties van die relaties op namelijk de subrelaties. Dit betekent dat als een persoon gekoppeld is aan een event, we ook kijken welke andere personen of organisaties er weer aan datzelfde event gekoppeld zijn. Zo krijg je als gebruiker een veel vollediger beeld van hoe alles met elkaar samenhangt.

Hetzelfde gebeurt op de pagina’s voor organisaties bij /organisation/:uuid. Dit ziet er in de code misschien onlogisch uit omdat de API niet een logische structuur gebruikt (soms heet een organisatie bijvoorbeeld ineens person in de data). Toch zorgen we er in de code voor dat dit goed word opgevangen zodat alle informatie op de juiste plek terechtkomt.

Voor evenementen via /event/:event geldt precies hetzelfde. Alleen ‘assets’ zoals afbeeldingen worden uitgesloten (deze staan in de API ok als relatie), omdat deze elementen geen relevante content bevatten en dus geen detailpagina krijgen. Assets inladen zorgt er ook voor dat de laadsnelheid van de pagina erg traag wordt omdat er veel meer afbeeldinge. geladen moeten worden.

Door deze manier van werken waarbij we relaties en subrelaties ophalen, kunnen gebruikers het archief op een natuurlijke manier verkennen. Ze zien niet alleen losse gegevens maar ook hoe mensen, organisaties en events met elkaar verbonden zijn. Dit wordt allemaal server-side gedaan en in overzichtelijke liquid templates gepresenteerd, zodat de pagina's dynamisch worden gevuld en goed werkt met screenreaders waardoor voldoet aan de toegankelijkheidseisen van het project.

De search is te bereiken via app.get("/search"). Dit component maakt het mogelijk om het hele archief te doorzoeken op basis van vrije tekstinvoer. We hebben ervoor gekozen om op de home pagina een grote zoekbalk neer te zetten zodat de gebruiker meteen kan zoeken naar dingen ook staat hij op de andere pagina's in de header dus de gebruiker kan altijd zoeken. Wat deze zoekfunctie bijzonder maakt, is dat het resultaten uit verschillende categorieën — zoals personen, organisaties en evenementen — in één overzicht toont. Wel moesten we filteren op uuid en namen aangezien sommige resultaten dit niet hebben waardoor het kapot ging. Na het filteren werkt het goed.

We hebben ervoor gekozen om de sub relaties op de detailpagina's niet te tonen, omdat dat veel te veel informatie was. We hebben in plaats daarvan details en summary gebruikt om de gebruiker de optie te geven deze extra informatie te bestuderen.

De feature om images aan en uit te kunnen zetten hebben we gemaakt op aanvraag van de opdrachtgever. Hierdoor reduceren we laadtijd en de hoeveelheid internet nodig om de site te bezoeken. Hierdoor kunnen mensen in andere landen (waar internet veel duurder is) ook gebruik maken van de site.