4.1.2 Onderscheid role "button" vs. role "link"

MikeClickr commented 2 years ago

Case

Binnen een app die ik review, wordt navigatie binnen en buiten de app aangeboden. Ik zoek naar een rationale.

Discussie

Binnen apps is het gebruikelijk om de rol "button" te hanteren. Ik stel voor om het volgende aan te houden:

Voor schermelementen die navigatie binnen een app verzorgen, adviseer ik om altijd de rol "button" te gebruiken. Bijvoorbeeld voor buttons, links naar andere schermen, lijstitems in een lijst, menu-items enz. Ook als de navigatie naar een WebView leidt met daarbinnen een webpagina, adviseer ik om de rol "button" te gebruiken voor de aanroep van dat scherm. Schermlezer: "Bouwprojecten, knop".
Voor schermelementen die navigatie buiten een app verzorgen, adviseer ik om altijd de rol "link' te gebruiken. Bijvoorbeeld als een browser of een andere app wordt gestart. Bijvoorbeeld voor links naar een website die niet in WebView opent of voor links die een andere app openen. Bijvoorkeur met een AccessibilityHint: "Signal, link, Tik dubbel op te openen".
Binnen een WebView worden webpagina's geladen, die rollen conformeren aan de richtlijnen voor web.

Is dit een goede interpretatie van de richtlijn van rollen voor apps?

sophieschoice commented 2 years ago

Hm, goede vraag. Vooralsnog gebruik ik dezelfde denkwijze als bij websites: is iets een actie? -> knop. Gaat het ergens naartoe? Link.

ShadowBB commented 2 years ago

Zowel de native Android als de native Apple navigatie mechanismen gebruiken "button" om te navigeren binnen de app. Gebruikers zijn dit ook gewend binnen apps (en tot op zekere hoogte zelfs dat dit ook af en toe gebeurd bij websites). De referenties van zowel Android als Apple zijn hier dan ook niet heel duidelijk in.

Het klopt volledig wat @sophieschoice zegt. Buttons zijn eerder bedoelt voor "acties" en veel minder voor "navigatie". Maar binnen apps wordt het sluiten van het ene scherm en het openen van het andere scherm veel meer gezien als een "actie" dan als slechts het verplaatsen naar een andere plek binnen de app (hoe de gebruiker het dan ook uiteindelijk ervaart lijkt maar weinig invloed te hebben op de keuzes van zowel Android als Apple).

Dus op dit moment geef ik ook het advies wat overeenkomt met wat Mike meld. Knoppen voor interne navigatie, deeplinks voor links naar websites. Deeplinks met parameters voor acties in externe apps of dingen zoals afspraken exporteren enzo.

Maar tijdens een audit keur ik beide goed. Zolang de rol naar de hulpsoftware gecommuniceerd wordt alszijnde of een link of een knop en de naam verder duidelijk maakt wat het werkelijk doet (meestal puur navigeren) keur ik het goed voor SC 4.1.2.

Dus je geschetste scenario zou ik goedkeuren onder 4.1.2

gjccopinga commented 2 years ago

@MikeClickr : lijkt me een goede interpretatie voor de rollen en een goed uitgangspunt. Ik ben het ook eens met de verwoording van @ShadowBB . Bij het onderzoeken is het belangrijkste dat een rol wordt gecommuniceerd die aangeeft dat er een interactieve component staat en wat die doet (door de toegankelijkheidsnaam van de interactieve component). Ik ben dus niet heel streng om een link af te keuren als er een knop zou moeten staan of andersom.

julezrulez commented 2 years ago

@gjccopinga Zou je een formulier die met een link verstuurd moet worden goedkeuren in sommige situaties? Indien ja, zou je dan een voorbeeld van een toegankelijkheidsnaam kunnen geven?

gjccopinga commented 2 years ago

@gjccopinga Zou je een formulier die met een link verstuurd moet worden goedkeuren in sommige situaties? Indien ja, zou je dan een voorbeeld van een toegankelijkheidsnaam kunnen geven?

@julezrulez Even voor de duidelijkheid. Mijn opmerkingen gaan over Apps, omdat ook de vraagstelling daar over gaat. Binnen een website zou ik bij formulieren wel het liefste gewoon knoppen zien voor het versturen van het formulier. Soms staat er een link om te annuleren. Dat vind ik dan wel oke. Verder adviseer ik altijd om knoppen te gebruiken voor het uitvoeren van 'acties'.

Als er toch een link zou (moeten) staan voor het versturen van een formulier, dan zou ik in de toegankelijkheidsnaam voornamelijk de functie er van omschrijven. Je kunt door middel van tekst toch wel 'compenseren' voor eventuele onduidelijkheid van een rol. Bijvoorbeeld "Verstuur het formulier". Eventueel met "het formulier" als verborgen tekst. Maar, zoals gezegd heeft dit zeker niet de voorkeur en zou ik ook niet aanraden. Mijn advies is om bij formulieren op websites gewoon een knop te gebruiken (button element of input type="submit").

ShadowBB commented 2 years ago

Een formulier dat verstuurd wordt met een link ben ik in zowel apps als websites volgens mij nog nooit tegen gekomen, dus ik heb nog geen mening gevormd of ik dit zou afkeuren of niet. Maar ik zou het tenminste sterk afraden.

Volgens mij zijn we het met zen allen eens over deze. Ik zet een voorlopige consensus op deze issue: Dus buttons voor interne navigatie en links naar websites en externe apps is een best practice. Maar beiden zouden goedgekeurd worden tijdens het onderzoeken van apps.

MikeClickr commented 2 years ago

Dank voor jullie reacties, ik zie draagvlak voor mijn voorstel. Het alternatief om dezelfde systematiek als web te hanteren, kan ook goedkeuring krijgen. Ik heb mijn voorstel voorgelegd aan twee gebruikers met visuele beperking en zij geven aan dat de rol "button" het meest gangbaar is binnen apps. En daarnaast vinden ze het goed dat verwijzingen buiten de app (naar een browser, andere app) niet alleen de rol "link" krijgen, maar dat ook specifiek benoemd wordt wat er geopend wordt , bijvoorbeeld: "Signal, link, Tik dubbel om te openen".

ShadowBB commented 2 years ago

Ja, dat laatste lijkt me een goede rol (hehe) voor de "accessible name". Want die moet goed het "linkdoel" communiceren.

ShadowBB commented 2 years ago

@MikeClickr Het is gebruikelijk dat de persoon die de issue geopend heeft ook een conclusie van de discussie schrijft voor op de website. Heb jij daar tijd voor? Zo nee dan kan ik die taak op mij nemen.

MikeClickr commented 2 years ago

@MikeClickr Het is gebruikelijk dat de persoon die de issue geopend heeft ook een conclusie van de discussie schrijft voor op de website. Heb jij daar tijd voor? Zo nee dan kan ik die taak op mij nemen.

Ik heb daar nu geen tijd voor, vrijdag eventueel wel. Ik vind het ook prima als jij het doet en ik review. Idee @ShadowBB ?

ShadowBB commented 2 years ago

Conclusie voor op de website:

Zowel knoppen als links mogen binnen apps gebruikt worden voor interne navigatie binnen de app en externe navigatie buiten de app. Hoewel het de verwachting is van de gebruiker dat buttons gebruikt worden voor interne navigatie en links gebruikt worden voor externe navigatie worden beide rollen dus goedgekeurd.

ShadowBB commented 2 years ago

@MikeClickr Hoe is bovenstaande? Veel langer dan dat kan ik het niet maken. XD

MikeClickr commented 2 years ago

@ShadowBB Ik zou het liever zo formuleren, meer richting de gewenste richting, graag je reactie:

Gebruik de rol 'button' voor navigatie binnen een app, gebruik de rol 'link' voor navigatie buiten een app. Afwijkend gebruik van beide rollen voor navigatie wordt ook goedgekeurd. Gebruik bij voorkeur een AccessibilityHint om aan geven welke externe app wordt gestart.

ShadowBB commented 2 years ago

De website hoort vooral te melden wat goed en afgekeurd wordt voor zover ik begrepen had. De best practice is dan een bonus. De AccessibilityHint hebben we het om die reden dan ook niet over gehad.

Ik heb echter zelf geen problemen met jou verwoording en het toevoegen van de AccessibilityHint best practice aangezien je het wel genoemd had in je initiële case en niemand het tegenspreekt (ik ook niet. Ik ben het er mee eens). Dus ik heb geen problemen met jou bewoording voor op de website.

MikeClickr commented 2 years ago

Oké prima, als het toch jouw voorstel wordt, zou ik nog wel explicieter vermelden dat het over 'rollen' gaat.

ShadowBB commented 2 years ago

Goed punt! Hoe is dit @MikeClickr :

Conclusie voor op de website:

Zowel button als link rollen mogen binnen apps gebruikt worden voor interne navigatie binnen de app en externe navigatie buiten de app. Hoewel het de verwachting is van de gebruiker dat button rollen gebruikt worden voor interne navigatie en links gebruikt worden voor externe navigatie worden beide rollen dus goedgekeurd. Een andere best practice is om AccessibilityHint te gebruiken om aan te geven welke externe app wordt gestart in het geval de link naar een andere app navigeert.

MikeClickr commented 2 years ago

@ShadowBB Prima, ik zou een apart onderdeel voor 'Apps' maken op de website, dan hoef je 'app' niet in elke conclusie te melden. Iets korter:

De rollen 'button' en 'link' mogen beiden gebruikt worden voor navigatie. Hoewel het de verwachting is van de gebruiker dat de rol 'button' gebruikt wordt voor interne navigatie en de rol 'link' gebruikt wordt voor externe navigatie, worden beide rollen dus goedgekeurd. Een andere best practice is om AccessibilityHint te gebruiken om aan te geven welke externe app wordt gestart in het geval de link naar een andere app navigeert.

ShadowBB commented 2 years ago

Yep. Beide suggesties ben ik het mee eens. Zowel de verkorte tekst als dat het waarschijnlijk handiger is om een aparte sectie voor website, pdf en app discussies te hebben. Maar zolang we die secties nog niet hebben denk ik dat het wel handig is om te noemen dat het hier over apps gaat:

De rollen 'button' en 'link' mogen beiden gebruikt worden voor navigatie binnen apps. Hoewel het de verwachting is van de gebruiker dat de rol 'button' gebruikt wordt voor interne navigatie en de rol 'link' gebruikt wordt voor externe navigatie, worden beide rollen dus goedgekeurd. Een andere best practice is om AccessibilityHint te gebruiken om aan te geven welke externe app wordt gestart in het geval de link naar een andere app navigeert.

MikeClickr commented 2 years ago

Prima, wat mij betreft kan het zo worden toegevoegd op de website.

ShadowBB commented 2 years ago

Hey Mike, bedankt voor de feedback en goedkeuring.

We sluiten de issue pas via de pull request die dit op de website zet.

WCAG-Audit-Discussions / NL-BE

4.1.2 Onderscheid role "button" vs. role "link" #22

Case

Discussie