1.3.1 Lijst zonder bullets

[ShadowBB]

Stel je hebt iets wat duidelijk een lijst is van verschillende soorten van dezelfde soort data (een lijst van personen of adressen of links naar websites over hetzelfde thema). Maar er staan geen bullets voor. Dus in plaats van

• appels
• peren
• aardbeien

staat er

appels peren aardbeien

Als dit niet aangegeven is met een lijst element (zoals bijvoorbeeld een ul element in HTML) faalt dit dan SC 1.3.1?

[ShadowBB]

Op het moment van schrijven komt er zoiets voor op onderstaande pagina: https://www.jeugdengezinutrecht.nl/pagina/openingstijden/626945

Al onze locaties zijn gesloten op de volgende feestdagen:

Maandag 18 april Tweede Paasdag
Woensdag 27 april Koningsdag
Donderdag 5 mei Bevrijdingsdag
Donderdag 26 mei Hemelvaartsdag
Maandag 6 juni Tweede Pinksterdag
Maandag 26 december Tweede Kerstdag

en

Vogelvlinderweg, Vogelvlinderweg 58, 3544 NJ Utrecht
Vleuterweide, Utrechtse Heuvelrug 130-132, 3452 JA Vleuten
J.P. Coenhof, J.P. Coenhof 216, 3531 HX Utrecht
Van Hoornekade, Van Hoornekade 25, 3554 AR Utrecht
't Goylaan, 't Goylaan 75, 3525 AA Utrecht
Al-Masoedilaan, Al-Masoedilaan 188, 3526 GZ Utrecht
F.C. Dondersstraat, F.C. Dondersstraat 1, 3572 JA Utrecht
Amazonedreef, Amazonedreef 43, 3563 CA Utrecht.

[ShadowBB]

Mijn persoonlijke interpretatie is als volgt:

1.3.1 stelt dat alles wat met behulp van vormgeving aangegeven wordt ook gecommuniceerd moet worden op een manier die door software te bepalen is of met behulp van tekst.

Bovenstaande voorbeelden zijn duidelijk lijsten maar zijn niet aangegeven als lijst met behulp van vormgeving, het is de inhoud van de lijst die duidelijk maakt dat het een lijst is, niet de vormgeving. Daarom zou ik dit goed willen keuren.

Een collega van mij stelt dat de "new lines" (of BR elementen) wel degelijk een vorm van vormgeving zijn en in deze context communiceren dat het om een lijst gaat.

Voor de goede orde de definitie van vormgeving (presentation) in WCAG is als volgt:

presentation
    rendering of the content in a form to be perceived by users

Is een met HTML geplaatste new line een vorm van "rendering of the content in a form"? Zo ja dan zou ik stellen dat mijn collega gelijk heeft en dat het vormgeving is en dus moet het ook gecommuniceerd worden op een andere manier en moeten dergelijke situaties dus afgekeurd worden. Zo nee, dan kunnen we dergelijke situaties goedkeuren naar mijn mening.

[BartCardan]

Ik zou het ook niet afkeuren. Het is in feite een probleem voor iedereen. Misschien wel een opmerking / tip?

[Aircl0wn]

Ik keur het momenteel wel af als ze geen <ul> oid gebruiken.

Het doelbewust opmaken van tekst met individuele strings is wat mij betreft opmaak omdat het (probeert) onderscheid te maken tussen de individuele regels en wil voorkomen dat het eruit ziet als een paragraaf aan tekst. Daarmee wordt het visueel duidelijker, maar programmatisch niet.

In eenzelfde lijn met H48: Using ol, ul and dl for lists or groups of links

[BartCardan]

Na het lezen van H48 en de opmerking van @Aircl0wn begin ik toch een beetje te twijfelen. Even voorop gesteld: tot op heden heb ik dit altijd goedgekeurd omdat de visuele presentatie / vormgeving van de lijst bepaald wordt door een vorm van "bullet".

Mijn twijfel ontstaat voornamelijk door de test procedure van H48. Het eerste punt beschrijft daarin:

Check that content that has the visual appearance of a list (with or without bullets) is marked as an unordered list.

Vooral het stukje "with or without bullets" doet vermoeden dat de "new line" misschien toch reden genoeg is om een UL-element te vereisen. In dat geval zou het dus afgekeurd moeten worden voor 1.3.1.

[ShadowBB]

Ik ben het met jullie beiden eens dat H48 dit suggereert. Echter een techniek bepaalt niet of iets wel of niet voldoet aan het SC. Het bepaalt alleen of iets wel of niet voldoet aan de techniek.

De vraag is vooral of we het meerdere keren gebruiken van een nieuwe regel zien als het vormgeven als lijst. De vraag is dus of dit valt onder de definitie "rendering of the content in a form to be perceived by users". @Aircl0wn vind jij dat het meerdere keren gebruik maken van een br element valt onder "rendering of the content"?

[Aircl0wn]

Ja, dat vind ik daar wel onder vallen. Je gebruikt <br /> om onderscheid te maken tussen meerdere regels. Visueel is dat duidelijk en ik kan dan, ook zonder bullets, een beetje snel zien om hoeveel regels het gaat etc. Die informatie mist een screen reader allemaal en voor zover ik weet worden ze niet standaard aangekondigd ook, dus krijg je feitelijk een lange zin.

[ShadowBB]

Ik kan me voorstellen dat die interpretatie voor wat grijs gebied zou kunnen zorgen in de toekomst. Als een nieuwe regel genoeg zou moeten zijn om iets te communiceren dan zou volgens mij ook een nieuwe regel aangekondigd door hulpsoftware genoeg moeten zijn om iets te communiceren toch?

BR elementen zijn nou eenmaal "door software te bepalen". Het is onderdeel van de HTML, daarom zie ik het niet als vormgeving maar als semantiek.

Daarnaast kunnen BR's meerdere betekenissen hebben:

Once upon a midnight dreary, while I pondered, weak and weary, over many a quaint and curious volume of forgotten lore. While I nodded, nearly napping, suddenly there came a tapping, as of some one gently rapping, rapping at my chamber door.

Zou ik geen lijst willen noemen.

[Aircl0wn]

Klopt, de context speelt dus mee in de beoordeling.

In het geval van een gedicht zorgt de BR voor wat opmaak, maar de semantische waarde veranderd er niet door. Dat gebeurt wel als je appels, peren en bananen onder elkaar zet. De visuele semantiek wordt dan "Hey, dit is een lijstje".

Een dikgedrukte tekst markeren we ook niet meteen als foutief. Je kijkt naar de presentatie en concludeert daarna of hiermee een heading wordt bedoeld of niet en handelt daaruit verder. Zo zie ik dit ook.

[ShadowBB]

Hmmm. Ik denk dat je me overtuigd hebt.

Juist het feit dat een <BR> meerdere betekenissen kan hebben is het probleem. Visueel is duidelijk dat het een lijst is, maar in de code niet want <BR> kan meerdere betekenissen hebben. <BR> zelf geeft dus niet aan op een manier die software te bepalen is dat het om een lijst gaat... want het zou ook andere dingen kunnen betekenen.

@BartCardan ben jij het er ook mee eens dat dit afgekeurd zou moeten worden na bovenstaande discussie? Want zo ja dan hebben we een consensus.

[BartCardan]

@ShadowBB Na alles te hebben gelezen is mijn persoonlijke mening dat ik dit inderdaad liever zou afkeuren. Disclaimer: ik heb dit nog niet intern bij Cardan voorgelegd.

[ShadowBB]

@BartCardan Neem rustig de tijd om dit door te nemen met de rest van Cardan. Ik zet de consensus dan voorlopig op failed, maar er gaat een week overheen voordat de issue gesloten wordt en het op de website gepubliceerd wordt. Ook kan de issue daarna altijd nog heropend worden als iemand binnen Cardan het er niet mee eens is.

[ShadowBB]

Samenvatting voor de website:

Lijsten zonder bullets hebben alsnog de vormgeving van een lijst en moet ook softwarematig de lijst aangegeven zijn als lijst:

appels peren aardbeien

Dus bovenstaande voorbeeld faalt SC 1.3.1 als de lijst niet is aangegeven als lijst aangezien de vormgeving wel communiceert dat het hier om lijst elementen gaat maar dit niet bepaald kan worden door software en het niet duidelijk gemaakt wordt met behulp van tekst.

[gjccopinga]

Nog even een nabrander van mij vanuit Cardan. Ik ben het eens met de conclusies. Goede discussie en goede uitkomst!

[rianrietveld]

Deze discussie is opgenomen op de website: https://wcag-audit-discussions.github.io/NL-BE/sc/1.3.1/#lijst-zonder-bullets

[rianrietveld]

Ik sluit deze discussie, de tekst staat op de website en er is al meer dan 10 dagen geen andere mening.