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

1.3.1 Lijst van links zonder bullets #14

Open ShadowBB opened 2 years ago

ShadowBB commented 2 years ago

Stel je hebt links onder elkaar staan (bijvoorbeeld links in een hamburgermenu). Deze hebben geen bullets ervoor staan. Deze is niet aangegeven als lijst (er is dus geen html lijst element of role="list" attribuut gebruikt). Moet dit afgekeurd worden onder 1.3.1?

ShadowBB commented 2 years ago

Ik zou stellen dat de linebreak vormgeving in dit geval niet communiceert dat het een lijst is, maar een menustructuur. Aan de andere kant: die structuur zou dus ook op een 1 of andere manier gecommuniceerd moeten worden, en ik kan eigenlijk alleen een lijststructuur bedenken daarvoor.

Het WAI adviseert ook lijststructuren te gebruiken om menustructuren te communiceren: https://www.w3.org/WAI/tutorials/menus/structure/

Maar dit is een advies (waar 1.3.1 niet eens genoemd wordt).

Dit is uiteraard bovengekomen na de vorige consensus op deze Github over lijsten zonder bullets.

Ik weet op dit moment niet hoe ik dit zou moeten beoordelen, dus vandaar dat ik er een losse issue over start.

sophieschoice commented 2 years ago

Visueel is de relatie en structuur duidelijk voor ziende gebruikers. Programmatisch lijkt me de structuur en relatie ook duidelijk, omdat het voor screenreaders wel als lijst wordt behandeld (of ik moet de situatieschets verkeerd hebben geïnterpreteerd?) omdat het als lijst is opgemaakt.

Ik zou dit niet afkeuren onder 1.3.1.

Is het programmatisch geen lijst (er wordt dus geen <ul> gebruikt), zou ik dat wel durven afkeuren. Semantisch is het correcter om voor iets dat zich gedraagt als een lijst, een lijst moet zijn. Het helpt screenreader gebruikers enorm om te weten dat het lijst van menu-items is en hoeveel items er in die lijst zitten.

Aircl0wn commented 2 years ago

Ligt voor mij erg in lijn met de conclusie over de andere lijsten. Er is wel verschil. Bij de andere discussie had je tekst die aan een stuk voorgelezen wordt. Hier heb je als voordeel dat het losse interactieve elementen zijn die elk afzonderlijk behandeld worden.

Belangrijk is wel wat jullie beiden al aanhalen, die relatie is er zonder lijst programmatisch niet. De kans dat de individuele items niets met elkaar te maken hebben, hetzij als doel (navigatie) of als onderwerp (thema groepering), is vrij klein. Zelfs een verzameling random links is precies dat, links die je niet op een andere plek onderverdeeld hebt. Op dat vlak hebben ze dus een relatie met elkaar.

Ik zou dit afkeuren.

MAAR... 😄 ... De titel deed me wel denken aan lijsten zonder bullets.

De eerste gedachte was dat dit qua titel niet relevant was, maar ik bedacht me dat lijsten zonder bullets (list-style: none;) in Webkit (safari) niet aangemerkt worden met VoiceOver, alleen de losse lijst items. Er linkt dus geen "Lijst, x items".

Die toegevoegde waarde ben je in safari dan dus sowieso kwijt, tenzij je ook weer een role="list" toevoegt.

ShadowBB commented 2 years ago

Programmatisch lijkt me de structuur en relatie ook duidelijk, omdat het voor screenreaders wel als lijst wordt behandeld (of ik moet de situatieschets verkeerd hebben geïnterpreteerd?) omdat het als lijst is opgemaakt.

Ik zou dit niet afkeuren onder 1.3.1.

Ah excuus. Het scenario wat ik schetste was inderdaad zonder ul element (ik heb mijn oorspronkelijke scenario schets verduidelijkt).

Lijkt er op dat jullie dus beiden zeggen dat dit afgekeurd zou moeten worden. In lijn met de vorige consensus ook.

Dit brengt ons wel bij een ietwat vreemd scenario:

Stel je hebt een menu dat naast elkaar staat (niet onder elkaar) en het is niet aangegeven als lijst (wat me niet verplicht lijkt) maar als je inzoomed dan wordt ditzelfde menu onder elkaar geplaatst omdat er geen plek is naast elkaar, nu moet het wel aangegeven zijn als lijst?

@Aircl0wn en @sophieschoice zijn jullie okay met dat scenario en denken jullie dat dit geen problemen gaat opleveren aan dit uitleggen aan developers na een audit?

Aircl0wn commented 2 years ago

Heel zwart-wit gezien lijkt me dat ook een lijst? Het is een visuele groepering van aan elkaar verwante elementen.

Je ziet tegenwoordig dan wel vaak een nav groepering. Dan heb je enige programmatische groepering. Dat is een pattern dat je regelmatig voorbij ziet komen (nav container met alleen maar a tags) maar je mist dan nog steeds relevante informatie als aantallen.

Ik ben daarin dan denk ik vrij (te?) streng maar zou het denk ik ook afkeuren.

FerJo commented 2 years ago

Voordeel van een lijst bovendien is dat je met de toetsen L en I kunt navigeren.

FerJo commented 2 years ago

https://www.w3.org/WAI/WCAG21/Techniques/html/H97.html

Dit mag blijkbaar (vereenvoudigd):

<nav>
<a>
<a>
</nav>
FerJo commented 2 years ago

Een conclusie zou dus kunnen zijn:

Navigatielinks hoeven volgens 1.3.1 niet als lijst aangegeven te worden, MITS het nav-element gebruikt is om de links te groeperen.

Best practice: Geef de navigatielinks aan als lijst, omwille van de voordelen:

ShadowBB commented 2 years ago

Bedankt voor je toelichting @Aircl0wn en gelijk heb je @FerJo . Dus ik denk dat de consensus gaat zijn afkeuren onder 1.3.1 als het niet is aangegeven als lijst en niet is aangegeven met een nav element want dan is er dus een minstens een structuur visueel aangegeven (danwel lijst, danwel navigatie element) die op geen enkele andere manier is gecommuniceerd.

Ik geef nog heel even @sophieschoice (en anderen uiteraard) de kans om te reageren maar zal anders aan het einde van deze week de consensus tag hier aan toevoegen. :) Bedankt allemaal!

sophieschoice commented 2 years ago

Ik ben het eens met de voorgestelde conclusie (goed samengevat @ShadowBB !) en zie verder geen andere aandachtspunten.

Aircl0wn commented 2 years ago

Kan ik me ook in vinden.

Ik heb recentelijk geen nav > a structuren gehad in een audit en ze zijn inderdaad valide, dus ben toch even terug gaan zoeken. Ik heb ze eerder niet afgekeurd voor zover ik 1-2-3 kon vinden, maar wel geadviseerd een lijst toe te voegen waar deze ontbrak.

FerJo commented 2 years ago

Misschien ten overvloede, maar dan zijn de volgende voorbeelden dus allemaal conform (?):

Links in een nav

<nav>
<a>
<a>
</nav>

Links in een lijst in een nav

<nav>
<ul>
<li><a>
<li><a>
</ul>
</nav>

Links in een lijst, zonder nav

<ul>
<li><a>
<li><a>
</ul>
ShadowBB commented 2 years ago

@FerJo Ja. Die zouden dan dus allemaal conform dit SC zijn.

ShadowBB commented 2 years ago

Conclusies voor op de website:

In het geval er meerdere links onder elkaar staan dan is dat een structuur die is aangegeven met vormgeving. Het is of een lijst-structuur of een menu. Als er geen structuur is aangeven op een manier die door software te bepalen is (bijvoorbeeld een lijst of een nav element) dan wordt dit dus afgekeurd op SC 1.3.1.

rianrietveld commented 2 years ago

gepubliceerd: https://wcag-audit-discussions.github.io/NL-BE/sc/1.3.1/