Design Rationale - Liamvanbart1/Framez GitHub Wiki
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)
We hebben vijf weken de tijd gekregen voor deze opdracht, die fungeert als afsluiting van deze periode.
In de afgelopen tijd hebben we veel nieuwe kennis opgedaan over HTML, CSS en JavaScript ook met betrekking tot toegankelijkheid (HCD) en zijn we ook aan de slag gegaan met LiquidJS en NodeJS.
Deze opdracht is een kans om al die opgedane vaardigheden samen te brengen en toe te passen in een concreet project. Daarom hebben wij gekozen voor variant 2 aangezien wij in dit korte tijdframe geen ruimte hebben om nieuwe technieken te leren (Wordpress). Een mirror maken van de bestaande wordpress website met accessibility in gedachte past niet bij het niveau dat wij nodig hebben voor de eindopdracht.
In overleg met onze docenten zijn wij tot de conclusie gekomen dat variant 2 de enige optie is waarbij we op een goed product en aan onze leerdoelen kunnen komen. Om toch variant 1 op weg te kunnen helpen kunnen wij de elementen waarbij onvoldoende op gescoord is op de WCAG test meenemen in het ontwerp voor variant 2, hiervoor kunnen we een aantal prototypes leveren per element dat onvoldoende heeft gescoord om de site accessible kan maken. Door er dus een creatief proces van te maken in plaats van een lijst af gaan van wat er opgelost moet worden hopen wij op betere accessibility te komen dan momenteel voorgesteld wordt door de 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.
- Zo weinig mogelijk
-
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.
- Interactieve elementen moeten de correcte
-
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.
- Elk formulierinvoerveld moet een gekoppeld
-
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