search

nl-design-system / documentatie

Website met documentatie van NL Design system: componenten, patronen, richtlijnen etcetera. Development-versie: https://documentatie.vercel.app/
https://www.nldesignsystem.nl/
European Union Public License 1.2
10 stars 12 forks source link

Succescriteria bij component Button #1392

Open MarjonBakker opened 2 weeks ago

MarjonBakker commented 2 weeks ago

Gerelateerd #1375

Notities Marjon:

Discussiepunten

  1. Vaak hebben criteria met elkaar te maken, zoals 1.1.1 Niet-tekstuele content met 2.4.6 Koppen en labels en 4.1.2 Naam, rol, waarde als het gaat om een alt-tekst die ook de accName van iets vormt. Willen we in zo'n geval kruisverwijzen? Nog zo'n setje: 1.4.11 Contrast van niet-tekstuele content, 2.4.7 Focus zichtbaar, 2.4.13 Focusweergave
  2. Hoe groot maken we de scope hier? Bijvoorbeeld 3.2.4 Consistente identificatie, dat gaat om meerdere buttons op verschillende plaatsen.

Acceptatiecriteria

WCAG 2.2-succescriteria

1.1.1 Niet-tekstuele content

Als het label van een button uit een afbeelding bestaat, dan heeft deze afbeelding een goed tekstalternatief, zodat de button een naam heeft die duidelijk maakt waar de button voor dient.

NL Design System richtlijnen:

1.4.3 Contrast (minimum)

Het contrast van de buttontekst met de achtergrondkleur is hoog genoeg. Dit is te controleren met de Contrast checker.

NL Design System richtlijnen:

1.4.4 Herschalen van tekst

Als je de tekst vergroot tot 200% (via browserzoom en via de browserinstellingen voor tekstgrootte) blijft de tekst in zijn geheel zichtbaar.

1.4.5 Afbeeldingen van tekst

Het label van de button bestaat uit gewone tekst, niet uit een afbeelding van tekst. Tenzij om een logo gaat, zoals het DigiD-logo.

NL Design System richtlijnen:

1.4.11 Contrast van niet-tekstuele content

Als het label van de button niet uit tekst bestaat maar uit bijvoorbeeld een icoon (zoals bij een zoekknop met een vergrootglas), dan is het contrast tussen het icoon en de achtergrond minimaal 3:1. Dit is te controleren met de Contrast checker.

1.4.12 Tekstafstand

Als je de tekstafstand vergroot blijft de tekst in zijn geheel zichtbaar. Dit gaat om afstand tussen letters, woorden, regels en alinea's.

2.1.1 Toetsenbord

Je kunt de button focussen met de tabtoets en activeren met de spacebar en de entertoets.

NL Design System richtlijnen:

2.4.6 Koppen en labels

Het label van de button maakt kort en bondig duidelijk waar de button voor dient.

NL Design System richtlijnen:

2.4.7 Focus zichtbaar

Wanneer een button de toetsenbordfocus krijgt is de focus zichtbaar.

NL Design System richtlijnen:

2.4.13 Focusweergave

Er is een goed zichtbare focusindicator die ook rekening houdt met het contrast met de verschillende achtergrondkleuren waarop de button gebruikt kan worden.

NL Design System richtlijnen:

2.5.2 Aanwijzerannulering

Dit criterium maakt het moeilijker om een button onbedoeld te activeren met een muis, toetsenbord of touchscreen.

2.5.3 Label in Naam

De zichtbare naam van de button is gelijk aan de toegankelijke naam.

NL Design System richtlijnen:

2.5.5 Grootte van het aanwijsgebied (uitgebreid)

De button is groot genoeg om gemakkelijk aan te klikken (44 bij 44 pixels). Kleinere buttons staan niet te dicht op een andere button.

NL Design System richtlijnen:

3.1.2 Taal van onderdelen

Als een buttontekst in een andere taal is dan de taal van de pagina, dan heeft het element een lang-attribuut met de juiste taalcode.

Denk bijvoorbeeld aan buttons voor het veranderen van de taal van een pagina, bij meertalige websites.

3.2.4 Consistente identificatie

Buttons met gelijke functies hebben hetzelfde uiterlijk en hetzelfde label.

4.1.2 Naam, rol, waarde

De button heeft een rol van button en een toegankelijke naam die duidelijk maakt waar de button voor dient. Ook is de toestand (state) duidelijk.

NL Design System richtlijnen:

Robbert commented 6 days ago

Ik zou graag wat nauwkeuriger ingaan op welke state duidelijk moet zijn 4.1.2. Het succescriterium gaat namelijk specifiek over dat states in te stellen moeten zijn, en dat er notifications zijn over wijzigingen van states. Er lijkt niet per se te staan dat states ook programatically determinable moeten zijn.

Yolijn commented 6 days ago

Mooie PR geworden, ik heb hem gemerged! De enige vreemde 🦆 eend in de bijt is wat mij betreft de beschrijving bij criteria 2.5.2

Dit criterium maakt het moeilijker om...

Bij de rest is het concreet wat het betekend en wat je moet doen, bij deze zou ik het nu nog niet weten.

MarjonBakker commented 3 days ago

Mooie PR geworden, ik heb hem gemerged! De enige vreemde 🦆 eend in de bijt is wat mij betreft de beschrijving bij criteria 2.5.2

Dit criterium maakt het moeilijker om...

Bij de rest is het concreet wat het betekend en wat je moet doen, bij deze zou ik het nu nog niet weten.

@Yolijn Klopt, goed gezien. Ik wilde deze acceptatiecriteria zo eenvoudig mogelijk houden, zonder technisch te worden. Technische vereisten kun je dan lezen in de uitleg van het criterium. Bij 2.5.2 vond ik dat heel lastig. We kunnen wel de tekst overnemen over up en down events?

Yolijn commented 3 days ago

@Yolijn Klopt, goed gezien. Ik wilde deze acceptatiecriteria zo eenvoudig mogelijk houden, zonder technisch te worden. Technische vereisten kun je dan lezen in de uitleg van het criterium. Bij 2.5.2 vond ik dat heel lastig. We kunnen wel de tekst overnemen over up en down events?

Check! Zouden we niet de uitlegtekst van het criterium (deels) kunnen gebruiken?

Zorg ervoor dat, als de gebruiker een button indrukt met een aanwijzer zoals een muis of vinger, er de mogelijkheid is om actie te voorkomen of ongedaan te maken.

Dit voorkomt het per ongeluk aanraken en activeren van functies, waarvan het niet de bedoeling was.

MarjonBakker commented 3 days ago

Ik zou graag wat nauwkeuriger ingaan op welke state duidelijk moet zijn 4.1.2. Het succescriterium gaat namelijk specifiek over dat states in te stellen moeten zijn, en dat er notifications zijn over wijzigingen van states. Er lijkt niet per se te staan dat states ook programatically determinable moeten zijn.

@Robbert Hoort dat hier thuis? Je kan doorklikken naar de uitleg van 4.1.2, daar zou volgens mij uitgebreidere uitleg moeten staan. Bij de acceptatiecriteria wil ik het graag zo eenvoudig mogelijk houden.

Of bedoel je de laatste zin te veranderen in bijvoorbeeld: "Ook is de toestand (state) duidelijk en door de gebruiker te veranderen met hulpsoftware"?

Robbert commented 3 days ago

Ik heb de zorg dat bij de meeste teksten ontwikkelaars en designers niet concreet geholpen zijn om een goede component te maken. De teksten lijken, eigenlijk net als WCAG, geschreven te zijn om als basis voor een beoordeling te maken.

Om mensen succesvol te laten zijn, dat er een combinatie van één of meer van de volgende aspecten nodig is:

Robbert commented 3 days ago

Of bedoel je de laatste zin te veranderen in bijvoorbeeld: "Ook is de toestand (state) duidelijk en door de gebruiker te veranderen met hulpsoftware"?

Dat is inderdaad meer wat ik bedoelde.

MarjonBakker commented 3 days ago

@Yolijn Ja, dat is een idee, maar er moet niet teveel dubbelen. Ik stel voor: "Als de gebruiker een button indrukt met een aanwijzer zoals een muis of vinger, is er de mogelijkheid is om actie te voorkomen of ongedaan te maken."