Richtlijnen formulieren: Links versus buttons, wanneer gebruik je welk element?

[rianrietveld]

In de richtlijnen voor formulieren kan de onderstaande tekst worden opgenomen. Maar hiertegen zijn goede bezwaren.
Als NLDS is het belangrijk dat we een gefundeerde bruikbare richtlijn hebben waar consensus over is.
We voeren de discussie hierover bij dit issue.

Deze richtlijn is voor nu niet opgenomen in de docimentatie
Discussie bij orginele PR: nl-design-system/documentatie#400
nl-design-system/documentatie#400 (comment)

Links versus buttons, wanneer gebruik je welk element?

Het fundamentele verschil tussen een button en een link is het doel en de opvolgende actie.

Een link verwijst naar een andere locatie, op of buiten de webpagina. Een button zorgt voor een actie, zoals het formulier versturen, informatie wissen, een modal openen of het uploaden van een bestand.

Ook de toetsenbordinteractie is anders. Een link bestuur je met alleen de “enter”-toets, een button bestuur je met de “enter”-toets of de spatiebalk. Screenreadergebruikers krijgen de informatie “button” of “link” voorgelezen als het element focus krijgt en hebben dus verschillende verwachtingen van de werking.

Maar hoe gaan we hiermee om in het design? Standaard ziet een button eruit als een knop en een link is een onderstreept woord of zin.
Soms wordt hiervan afgeweken om een knop minder visueel gewicht te geven. Kies dan voor een ander ontwerp van de button en gebruik dat consistent binnen de website. Kies niet voor een button die eruitziet als een link en andersom.

Door te zorgen voor een consistente weergave van links en buttons, voldoe je aan:

• het WCAG-succescriterium 3.2.4 Consistente identificatie;
• de WCAG richtlijn 3.2 Voorspelbaar: maak het uiterlijk en de bediening van webpagina's voorspelbaar.

[rianrietveld]

Ook relevant is de discussie bij gov.uk: (alphagov/govuk_elements#272 (comment))

[bramsmulders]

In het verleden heb ik eigenlijk altijd 2 componenten(of styles) gehad in een codebase: Link & Button.

Semantisch:

Allebei deze componenten kunnen een a of button element zijn aan de hand van hun context. Navigeer je ergens naartoe kies je een a, trigger je een actie op dezelfde pagina of controleer je iets binnen een formulier kies je button.

Visueel

Een Link component kan ook een button element zijn, bijvoorbeeld: Een modal trigger in een lopende tekst wil je semantisch een button laten zijn, maar visueel moet het een link zijn.
Daarnaast kan een Button component ook gebruikt worden als CTA knop naar een andere pagina. Dan moet het semantisch een a zijn, maar visueel een knop.

Ik denk dus dat je prima beiden door elkaar kunt gebruiken, maar dat de "intent" duidelijk moet zijn.

[pbb72]

Er zijn meer verschillen tussen een link en een knop dan alleen semantisch en visueel. Het probleem is ook niet begrenst tot gebruikers met een handicap.

Zoals eerder vermeld is het effect van de spatiebalk verschillend. Een knop wordt geactiveerd met een druk op de spatiebalk, terwijl bij een link het effect is dat de getoonde pagina een scherm omlaag gaat (hetzelfde effect als met de Page Down knop). Wanneer een link er visueel als een knop uitziet, en een gebruiker deze activeert met de spatiebalk, kan het gebeuren dat de gebruiker de indruk krijgt dat het scrollen het beoogde effect van de "knop" was.

Een ander verschil is dat met links altijd een navigatie gebeurd, welke ongedaan gemaakt kan worden met het gebruik van de "terug" knop in de webbrowser. Dit is echter niet noodzakelijkerwijs het geval met een knop. Wanneer een knop er visueel als een link uitziet, kan het goed gebeuren dat een gebruiker terug wil navigeren met de knoppen in de webbrowser, en daarmee "te ver" terug gaat of in het ergste geval eerder ingevulde informatie verliest.

Ten slotte bieden links een eigen context menu, toegankelijk via de rechter muisknop of Shift-F10 op het toetsenbord, en de mogelijkheid om de link in een nieuw tabblad te openen, via Ctrl-click of het context menu. Deze mogelijkheden biedt een knop niet. Wanneer een knop er visueel als een link uitziet, kan het gebeuren dat een gebruiker de "link" wil openen in een nieuw tabblad zonder de navigatie van de huidige pagina te verliezen, en met Ctrl ingedrukt op de "link" klikt. Wanneer de "link" echter technisch een knop is, zal geen nieuwe pagina geopend worden maar de knop zal geactiveerd worden, met mogelijk ongewenste effecten als gevolg.

Dit zijn slechts drie van de verschillen die gemakkelijk (en veelvuldig) over het hoofd gezien worden. Natuurlijk is het mogelijk met JavaScript deze verschillen op te vangen. Maar dat vereist dat een ontwikkelaar op de hoogte is van alle verschillen, ook die mogelijk met een toekomstige versie van de navigatie-software (webbrowsers, maar ook toegankelijkheidssoftware) geïntroduceerd worden.

Links mogen best een visuele boost krijgen, maar dat moet op een andere manier gebeuren dan ze er als een knop uit te laten zien. En eerlijk gezegd zie ik geen redenen om een knop er als een link uit te laten zien.