Open Veyfeyken opened 1 year ago
Via Christophe Strobbe
Ik heb ook nog eens geprobeerd de discussie op WCAG issue 1512 opnieuw aan te zwengelen.
My small usage-centered contribution :) If the disabled button is being skipped by the screen reader, then the screen reader user will just continue looking for it without understanding what is happening (while sighted users do see it as disabled). With an aria-disabled instead of HTML disabled, the button is still focusable, and announced as disabled. For me this is the minimum. Now if the lambda user has to guess why that button is disabled because the interface is not intuitive, this is a usability issue. If there is any cue for non-disabled users (warning message on mouse-over the button, special cursor on mouse over, or whatever hint about why it is disabled), then it must be conveyed to disabled users too.
Als bij het formulier een fout automatisch ontdekt wordt en dit alleen als gevolg heeft dat de submit knop disabled blijft en er dus geen foutmelding door middel van tekst komt lijkt mij dit wel een toegankelijkheidsprobleem voor SC 3.3.1. Het succescriterium geeft aan dat als de fout automatisch ontdekt wordt dat duidelijk moet worden gemaakt waar het probleem zich voordoet en wat het probleem is in tekst. Daar wordt dan dus niet aan voldaan lijkt mij.
Misschien ook even naar de definitie van input error kijken:
information provided by the user that is not accepted
Note
This includes:
- Information that is required by the Web page but omitted by the user
- Information that is provided by the user but that falls outside the required data format or values
Dus als een of meer verplichte velden niet ingevuld worden, geldt dit als een input error.
De submit-button die disabled blijft, levert op zich geen beschrijving van een fout, en al zeker niet wanneer de aanwezigheid van de button omwille van een disabled
-attribuut voor screenreaders verborgen blijft. (Zelfs met tabindex=0
blijft een button met het disabled
-attribuut buiten de tabvolgorde.)
Als er bij de verplichte velden bij b.v. onblur
een foutmelding verschijnt, dan verandert dat de situatie, maar daarover gaat het hier niet.
Nadelen van een disabled submit button volgens de draft NL Design System Formulierrichtlijnen:
Een poging tot vertalen vanuit gebruiker naar formulierrichtlijnen.
De gebuiker moet zoeken wat er mis is, waarom kan het formulier niet worden verzonden?
Meestal is een disabled button grijs met grijze tekst. Dit is voor veel gebruikers slecht zichtbaar.
Toetsenbord- en screenreadergebruikers kunnen de disabled button geen focus geven en dat is verwarrend en onverwacht in het gebruik.
C: Screenreader gebruikers kunnen op andere wijze navigeren over de knop, het is belangrijk dat de uitgeschakelde informatie wordt overgedragen in tekst of programmatisch. 1.3.1 info en relaties.
D: Toetsenbordgebruikers zijn net als andere gebruikers gebaat bij een duidelijke instructie (A), zodat de verwachting en interactie met het formulier duidelijk is.
Gebruikers kunnen verandering van disabled in enabled soms niet opmerken als deze uit beeld is en blijven zoeken naar wat er mis is.
Is het patroon waarbij de submit button van een formulier het disabled attribuut heeft tot alle verplichte velden zijn ingevuld, een failure op 3.3.1 Error Identification?