On the login page, the error messaging container currently does not include an aria-live attribute. It also does not have a role attribute set to alert. This is an issue for screen reader users. Both attributes should be set to a container that is present when the page first loads so that screen readers may monitor those for status changes, and notify the user as required. Otherwise, screen reader users will not be made aware that their login attempt failed if/when it does.
Created attachment 180727 [details] [review] Bug 39494: Announce status messaging on login page So that screen readers announce errors, add a role attribute set to "alert" and a aria-live attribute set to "assertive". Since the page reloads on each login attempt, the page will effectively be loaded with both attributes set (if there is an error) and so screens readers should be able to detect and announce the message. Test plan: 1) On the Koha OPAC, navigate to Home > Log in to your account 2) Attempt to login, entering an incorrect password 3) Inspect the HTML, and notice that the relevant element now has a role attribute set to "alert" and an aria-live attribute set to "assertive". Repeat steps 2-3, but instead of an incorrect password error, trigger: A) a timeout error B) a different IP address error C) a too many login attempts error D) an authorisation error (where we are authenticating with a third party) E) a shibboleth authentication error F) a CAS login error G) an invalid username/password error for an anonymous patron H) an anonymous patron error I) a password expired error
Note: The current patch is likely the simplest / most basic solution to implement that came to mind. Another approach might be to rewrite the error messages in opac-auth.tt so that they all use a shared <div class="alert alert-info"><p aria-live="off" role="alert"></p></div> element, dynamically setting aria-live to "assertive" when relevant, and passing the appropriate message. It would likely also involve adding a method in Auth.pm to assign the relevant error message. I will happily go with either, but though I would start with the simplest.
Created attachment 180736 [details] [review] Bug 39494: Announce status messaging on login page So that screen readers announce errors, add a role attribute set to "alert" and a aria-live attribute set to "assertive". Since the page reloads on each login attempt, the page will effectively be loaded with both attributes set (if there is an error) and so screens readers should be able to detect and announce the message. Test plan: 1) On the Koha OPAC, navigate to Home > Log in to your account 2) Attempt to login, entering an incorrect password 3) Inspect the HTML, and notice that the relevant element now has a role attribute set to "alert" and an aria-live attribute set to "assertive". Repeat steps 2-3, but instead of an incorrect password error, trigger: A) a timeout error B) a different IP address error C) a too many login attempts error D) an authorisation error (where we are authenticating with a third party) E) a shibboleth authentication error F) a CAS login error G) an invalid username/password error for an anonymous patron H) an anonymous patron error I) a password expired error Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Created attachment 182187 [details] [review] Bug 39494: Announce status messaging on login page So that screen readers announce errors, add a role attribute set to "alert" and a aria-live attribute set to "assertive". Since the page reloads on each login attempt, the page will effectively be loaded with both attributes set (if there is an error) and so screens readers should be able to detect and announce the message. Test plan: 1) On the Koha OPAC, navigate to Home > Log in to your account 2) Attempt to login, entering an incorrect password 3) Inspect the HTML, and notice that the relevant element now has a role attribute set to "alert" and an aria-live attribute set to "assertive". Repeat steps 2-3, but instead of an incorrect password error, trigger: A) a timeout error B) a different IP address error C) a too many login attempts error D) an authorisation error (where we are authenticating with a third party) E) a shibboleth authentication error F) a CAS login error G) an invalid username/password error for an anonymous patron H) an anonymous patron error I) a password expired error Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com> Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Simple is good to start, thanks Chloe. Refactoring-wise, I think perhaps we can do that another time or highlight the idea to Owen :) Passing QA, this is a small but important accessibility improvement which causes no regressions for general users.
Pushed for 25.05! Well done everyone, thank you!