search

WCAG-Audit-Discussions / NL-BE

Nederlandstalige discussies over hoe WCAG en de successcriteria te interpeteren.
https://wcag-audit-discussions.github.io/NL-BE/
24 stars 1 forks source link

Weergave kruimelpad op mobiele waargave #59

Open rianrietveld opened 4 months ago

rianrietveld commented 4 months ago

Op desktop heeft een kruimelpad alle ruimte. Bijvoorbeeld voor de pagina Rijbewijs Home > Aanvragen en regelen > Paspoort, id-kaart en rijbewijs > Rijbewijs

Maar op mobiel neemt dit relatief heel erg veel ruimte in. Eén manier is om het kruimelpad te beperken tot bijvoorbeeld een icoontje van een pijltje terug.

Keuren jullie dit af?

Wat persoonlijke afwegingen: Het kruimelpad volledig weergeven drukt de paginatekst omlaag, neemt relatief teveel ruimte in en is daardoor verwarrend en geen optie. Er gaat nu geen functionaliteit verloren, de bezoeker kan terug naar de voorliggende pagina. Ik zou dit niet afkeuren, maar het kan beter.

Ik zou iets meer context in tekst bij het pijltje zetten, "terug" kan verwarrend zijn als de bezoeker midden in de pagina valt vanuit een extrene link. In dit geval "< Paspoort, id-kaart en rijbewijs", dus alleen de bovenliggende pagina benoemen.

De NN Group: Breadcrumbs 11 Design Guidelines for Desktop and Mobile. Consider shortening the breadcrumb trail to include only the last level(s).

DiedeGu commented 4 months ago

Ik ben een programmeur, geen auditor dus dat mag je natuurlijk mee nemen in de waarde van mijn mening.

Ik zou zelf zeggen dat je beter geen breadcrumb kan tonen dan een pijl of terug knop. Het volledige breadcrumb pad helpt op desktop omdat het juist geen terug knop is. Die terug knop zit al in de browser, de breadcrumbs laten je zien waar in de pagina hiërarchie je je bevind en stellen je in staat meteen naar een relevante bovenliggende categorie te springen.

Het bieden van een terug knop op de plek van de navigatie om mobiel is daarmee een vervaning van de terugknop op desktop maar niet van een breadcrumbs mijn inziens. Waarom ik dat verder afraad is omdat je, in ieder geval in chrome op mobiel, links kan swipen om terug te gaan en de terug knop onder aan in het scherm kan gebruiken. Je heb daarmee dus al twee alternatieven op browser niveau en ik vind het dan niet gewenst als developers zelf ook nog alternatieven gaan aanbieden naast wat op een hoger niveau al goed word opgelost.

rianrietveld commented 4 months ago

@DiedeGu Ja, dit is speciaal voor mobiel en om het kruimelpad korter weer te geven, dus niet echt een terugknop. Daarom ben ik het met je eens dat een pijltje alleen onvoldoende is.

Als de desktoppagina een kruimelpad heeft, zou deze functie er op mobiel ook moeten zijn. Door de link plus linktekst naar de bovenliggende pagina te geven bied je een soort verkort alternatief voor het kruimelpad.

fschroiff commented 4 months ago

Ik vind dingen verstoppen geen goed idee. Wat heb je er dan nog aan?

Het Gov.uk design system heeft een collabpsible breadcrumbs component. Hier worden op kleine schermen alle tussenstappen verstopt en blijven alleen "Home" en "Current page" over. Vind ik ook niet ideaal.

Misschien moeten we een toegankelijk drop-down menu weergeven op kleinere schermen.

Aircl0wn commented 4 months ago

Onder 1.4.10 Reflow zou je dit kunnen afkeuren als je het kruimelpad inkort.

Strikt genomen alleen op de specifieke viewport van dit succescriterium, maar impliciet wordt natuurlijk de hele gamma aan breakpoint van je design bedoeld.

Je hebt immers verlies van informatie en/of functionaliteit.

Bij een eerste laag (dus home > thema > detail kun je nog beargumenteren dat de pijl terug dezelfde functie heeft (functionaliteit), maar je vraagt wel een cognitieve belasting van de gebruiker om te onthouden welk thema dat dan is (informatie).

Dit probleem wordt natuurlijk nog groter dan je meerdere lagen hebt (home > thema > sub-thema > onderwerp ) en je de tussenliggende stappen helemaal overslaat.

Om het nog ingewikkelder te maken zou je kunnen beargumenteren dat, wanneer diezelfde informatie bijvoorbeeld allemaal in het hoofdmenu zit, je dan een alternatief hebt en dan hoef je het weer niet af te keuren. 🤷 Dus directe navigatie naar een thema of subthema en indicatie visueel en programmatisch in welk deel van de paginaboom de bezoeker zit.

erikkroes commented 4 months ago

2.4.8 is AAA, maar deze technique laat wel zien dat een kruimelpad waarde heeft: https://www.w3.org/TR/WCAG20-TECHS/G65.html

Als dat pad er bij de ene viewport wel is, en bij de andere niet, dan mis je waarde; de ervaring is niet gelijkwaardig. Alleen een pijltje biedt niet diezelfde waarde en is geen volwaardig alternatief. Als ze de pijl wel als alternatief zien, dan mogen ze die op alle viewports gebruiken. Dan zit je sowieso goed 🤷🏿‍♂️

rianrietveld commented 4 months ago

@erikkroes De link naar bovenliggende pagina tonen, vind je dat wel een optie? Want twee regels kruimelpad is ook geen werken.

gjccopinga commented 4 months ago

Er wordt in deze discussie denk ik nog een andere denkfout gemaakt. Het gaat hier niet alleen om mobiel. Of misschien zelfs wel helemaal niet (SC 1.4.10). Het gaat hier om mensen die slechtziend zijn en inzoomen op een desktop. Bijvoorbeeld naar 400%. Ze krijgen dan een kleinere weergave. Die is wel vergelijkbaar met mobiel, maar heeft wel een ander doel of andere doelgroep. Denk hierbij dus ook vooral aan oplossingen op desktop maar dan flink ingezoomd.

Wat ik belangrijk vindt in deze is inderdaad de 'waarde' of het doel van het broodkruimelpad. Als dat alleen maar is om één pagina 'terug' te kunnen gaan in de informatiestructuur, dan heb je niet een heel broodkruimelpad nodig. Het doel is denk ik breder dan dat, Het broodkruimelpad geeft door alle niveau's weer te geven meer informatie (over de informatiestructuur) en ook meer flexibiliteit om sneller stappen 'terug' te doen.

Vanuit die redenatie keuren wij het dus wel altijd af als er maar één link staat, of alleen een terug link. In principe moet alle informatie of functionaliteit die het broodkruimelpad biedt terugkomen (en dus niet zozeer voor een mobiel, maar wel voor desktop met inzoomen). Daar heb je verschillende opties voor denk ik. Zo'n dropdown zou bijvoorbeeld kunnen werken. Maar misschien kun je hem standaard ook verbergen en met een enkele actie zichtbaar maken. Dan neemt het standaard niet te veel ruimte in en alleen als je hem wilt gebruiken. Zo zijn er denk ik wel meer oplossingen te bedenken om het vormgeving technisch acceptabel te maken.

rianrietveld commented 4 months ago

@gjccopinga wat is de eerste denkfout? Natuurlijk gaat het hier om mobiel en ingezoomde weergave :-)

Goed punt van je:

Het broodkruimelpad geeft door alle niveau's weer te geven meer informatie (over de informatiestructuur) en ook meer flexibiliteit om sneller stappen 'terug' te doen.

Maar als het menu dit ook aangeeft is het dan zo hard af te keuren?

@ShadowBB @julezrulez wat doen jullie voor een verkort kruimelpad.

erikkroes commented 4 months ago

Volgens mij kan ik me aardig vinden in wat @gjccopinga schrijft.

Een kruimelpad is een antwoord/oplossing. Wat is de vraag? Wat wil je oplossen of aanbieden met een kruimelpad? Welke waarde wil je toevoegen, door dat ding te tonen? Als je dat weet wordt het een design-uitdaging. Wat kun je bedenken voor een kleine viewport, wat precies datzelfde biedt als het kruimelpad?

gjccopinga commented 4 months ago

Misschien nog een andere invalshoek. Stel je komt via een andere weg op zo'n pagina met een broodkruimelpad uit. Bijvoorbeeld via de zoekmachine van de website, of zelfs gewoon via Google. Zo'n broodkruimelpad geeft dan waardevolle informatie over waar je terecht bent gekomen en hoe de informatie op die pagina zich verhoudt tot de rest van de informatie op de website. Het helpt je te oriënteren op de website en om eventueel snel naar andere lagen van die informatiestructuur te gaan. Die functionaliteit wil je liefst toch ook bij een ingezoomde weergave (of mobiel) hebben.

De vraag is ook of dat heel duidelijk wordt uit het menu of de menu's. Dat ligt er misschien ook maar net aan hoe een hoofdmenu wordt weergegeven (met eventueel submenu's vast op een pagina {al dan niet links of rechts op de pagina}).

Dus, als er een toegankelijk alternatief is voor het broodkruimelpad door middel van de menu structuren, dan kan ik me voorstellen dat het niet afgekeurd hoeft te worden. Maar meestal is zo'n broodkruimelpad ook juist een toegankelijk alternatief voor (visuele) informatie die niet toegankelijk via de menu's wordt weergegeven (bijvoorbeeld door kleur gebruik).

gjccopinga commented 4 months ago

@gjccopinga wat is de eerste denkfout? Natuurlijk gaat het hier om mobiel en ingezoomde weergave :-)

Hmm, haha, goede vraag wat dan de eerste denkfout is. Ik weet al niet meer waarom ik dit zo heb opgeschreven. Waarschijnlijk bedoelde ik met eerste denkfout dat een verkorte versie een goed alternatief zou zijn voor een heel broodkruimelpad en dat dat dan geen verlies van informatie of functionaliteit zou zijn. Ik zie dat namelijk dan wel als verlies van informatie en functionaliteit.

julezrulez commented 4 months ago

Mobiele weergave, ingezoomde weergave.... beter is: lage resolutie. Ik heb namelijk een collega gehad die zijn beeldscherm op 800x600px had staan, wat hem de gelegenheid bood altijd teksten te kunnen lezen zonder te hoeven inzoomen.

Over het kruimelpad:

Genoeg redenen om zo'n kruimelpad te houden.

Het navigatiemenu is wat mij betreft alleen een goed alternatief als in dat menu het volledige pad te herleiden is. In veel gevallen zie je enkel dat de keuze op het hoofdniveau visueel gemarkeerd is, zie bijvoorbeeld eur.nl. Dat is onvoldoende. Uitzondering natuurlijk als de website niet veel groter is dan het aantal menu-items.

erikkroes commented 4 months ago

Iemand zou eens moeten schrijven over dat verhaal rond mobiele versies!

Oh wacht 😄 https://www.erikkroes.nl/blog/no-your-website-does-not-have-a-mobile-version/

ShadowBB commented 4 months ago

Ik keur het niet af omdat ik de terugknop (en verdere terugknoppen) zag als goed alternatief. Want daarmee kun je ook door het hele pad heen navigeren (al is het wel minder gebruikersvriendelijk natuurlijk omdat er meer kliks voor nodig zijn). Dus het voldoet niet aan het SC, maar er is een goed alternatief, dus het voldoet aan WCAG.

Maar Gerard zijn argument doet mij twijfelen. Als we een kruimelpad inderdaad zien als een manier om de structuur te laten zien dan moet die structuur wel in het hoofdmenu terugkomen inderdaad, want anders ontbreekt die informatie, en die informatie zou een gebruiker wel kunnen deduceren door de website te verkennen, maar dat lijkt me geen goed alternatief.

rianrietveld commented 3 months ago

Wat is ons gezamenlijk standpunt in deze? Ik stel voor om wat Jules schrijft als handleiding te gebruiken.

Over het kruimelpad:

Mee eens? 👍 Niet mee eens? 👎

Veyfeyken commented 3 months ago

Het uitgebreide kruimelpad vervangen door een enkele link in een kleine viewport of zoomed in beschouw ik niet echt als verlies van functionaliteit. De functionaliteit is de mogelijkheid om dat pad terug te volgen. Die functionaliteit verdwijnt niet. Het volledige pad ineens kunnen zien beschouw ik maw niet als de functionaliteit.

Het is een serieus twijfelgeval maar ik vind het niet 'brekend' genoeg om af te keuren.

hidde commented 3 months ago

Hm, sorry, maar it depends.

Ik beschouw het vervangen door een enkele link in de meeste gevallen niet als verlies van functionaliteit, want “de structuur van de site kunnen herleiden” is vaak niet het doel van de breadcrumb. Soms is het überhaupt niet mogelijk, want veel sites hebben geen eenduidige structuur; zo horen producten in een webshop vaak bij meerdere categorieën. Waar “structuur herleiden” wel het doel is, is dat in de meeste gevallen ook op allerlei andere manieren mogelijk, bijvoorbeeld via navigatie, mits die dan wel op lage resolutie goed volledig beschikbaar is.

Dat gezegd hebbende, er zijn wel gevallen waarin je niet wegkomt met het weglaten van delen van de breadcrumb onder specifieke condities (zoals resolutie), vooral breadcrumbs die vrij diep gaan vallen wmb in die categorie.

Ik sluit me ook aan bij de voorbeelden van wat je beter kunt doen dan alleen de eerste link tonen, zoals Jules' opmerking dat je de breadcumb op lage resolutie onder een uitvouwmechanisme zou kunnen stoppen.

Aircl0wn commented 3 months ago

Iedereen heeft het over functionaliteit, maar het SC benoemt ook het verlies van informatie.

Als je in een webshop settings normaal de categorie toont en op mobiel niet, dan mis je informatie, toch?

Een kruimelpad is ook niet alleen om naar een vorige pagina te gaan (vervangen back button), de meeste mensen komen na een zoekopdracht op een specifieke pagina binnen en willen van daaruit mogelijk naar andere relevante content navigeren.

julezrulez commented 3 months ago

In het gezamenlijk standpunt staat duidelijk dat er een goed toegankelijk alternatief is, en daaronder valt wat mij betreft een link die het pad zichtbaar maakt of een uitvouwmechanisem (dus kruimelpad onder een knop). Bij het eerste moet wel in het alternatief duidelijk zichtbaar zijn welk pad je moet doorlopen om op de pagina van het kruimelpad terecht te komen. @Veyfeyken Gijs, volgens mij bedoel je precies hetzelfde als wat Rian in het gezamenlijk standpunt heeft omschreven. Misschien moeten we de tekst van het standpunt iets beter maken?

Veyfeyken commented 3 months ago

@julezrulez Wat ik als voldoende beschouw (enkel parent page tonen in mobile breadcrumb), staat nu niet in het standpunt. Dus ik denk niet dat we hetzelfde bedoelen.

bij lagere resoluties mag je het kruimelpad verbergen onder een uitvouwmechanisme, maar nooit helemaal weglaten.

Ofwel moet je het uitbreiden. Bijvoorbeeld:

bij lagere resoluties mag je het kruimelpad verbergen onder een uitvouwmechanisme of beperken tot één link naar de parent page, maar nooit helemaal weglaten.

jeffreylauwers commented 3 months ago

Ik ben veel verschillende vormen tegen gekomen wat betreft het responsive gedrag van Breadcrumbs. https://github.com/orgs/nl-design-system/discussions/224

Het zou mooi zijn als we tot een toegankelijke standaard komen.

Ik ben voorstander van de variant waarbij bij een small viewport enkel het bovenliggende niveau als link wordt getoond. En bij voldoende ruimte de volledige hiërarchie. Ik zal toelichten waarom.

Tijdens mijn ontwerp ga ik altijd uit van het 'mobile first' principe. Dus ook voor het Breadcrumb component ga ik in eerste instantie uit de weergave bij een small viewport. Op dat moment is de functionaliteit: Één niveau omhoog navigeren in de hiërarchie.

Wanneer er meer ruimte is kunnen we alle bovenliggende niveaus tonen. Hiermee wordt het tonen van de complete hiërarchie en de mogelijkheid om niveaus over te slaan een extra (bonus) functionaliteit. Deze extra functionaliteit komt naast andere opties om hetzelfde te doen. Zoals:

Hiermee lijkt deze optie aan te sluiten op het ‘Offer choice’ Design principe. https://inclusivedesignprinciples.org/#offer-choice

Je zou deze extra functionaliteit bij voldoende ruimte kunnen vergelijken met:

Ik zie een nadeel bij Breadcrumbs die over meerdere regels lopen bij een small viewport.

Ik zie enkele nadelen bij het 'uitvouwmechanisme' bij een small viewport.

Het voordeel van enkel het bovenliggende niveau tonen zorgt daarnaast voor een rustigere weergave. Ik kan me voorstellen dat dit zorgt voor een minder cognitieve belasting.

julezrulez commented 1 month ago

Wellicht is het zinvol om de focus niet zozeer op mobiele weergave te leggen maar op weergave bij een lage resolutie. Het gaat bijvoorbeeld om mensen die er bewust voor kiezen om hun grote scherm op 600x800 pixels te zetten of mensen die meer dan gebruikelijk standaard inzoomen of een groter lettertype kiezen op hun device. Dus het gaat hier niet per se om "small viewports" als in kleine beelschermpjes.