V8: Accessibility changes for login screen

[RachBreeze]

This PR has a number of accessibility changes for the login screen:

• Separates out the validation of email address and password. Prior to this the error message displayed "username or password", which was confusing as in many cases the prompt is for "email" not "user name"
• Added aria-required prompt on inputs for screen readers
• Added the required prompt to inputs as per the inviteUserPasswordForm
• Includes localisation support for error messages on login

[emmaburstow]

Hi @RachBreeze

Thanks for this work! I've assigned the label. We'll take a look and let you know if we need anything more from you,

Em

[RachBreeze]

Hi @emmaburstow thank you

[zersiax]

@RachBreeze I am reasonably certain that adding required as an HTML attribute adds an implicit aria=-required, so you may not need aria-required here. Did you give this a try? :-)

[RachBreeze]

@zersiax I suspect not, looking at the order of my PRs I found an issue in Angular which was triggering "invalid" prompt to be played to an NVDA screen reader user when a user tabs into an empty required text box prior to entering any information but this was when the textbox was on an ng-form element not a form one. Once I've finished my current PR I can take another look

[RachBreeze]

I have reviewed the PR and when I use "required" and you are correct the user hears "required" but they also hear "invalid entry" when the user tabs into the textboxes and not when they tab out which is why I used aria required. The work @Matthew-Wise is doing on NGAria should also improve accessibility of the alerts

[RachBreeze]

Sorry 65161 referenced incorrectly

[emmaburstow]

Rachel, this is ace. Lots of work here ad I've done my best to check all over - I'm happy with the approach and I'm happy to approve. 👍

[RachBreeze]

Closing as PR has diverged too far from main branch

[nul800sebastiaan]

@RachBreeze I've merged this one with v8/contrib and it went well, there's not any conflicts that I can see. Any other reason you wanted to close this one? I think it can be reviewed as-is now?

[RachBreeze]

Hi @nul800sebastiaan
Thank you, that was the only reason for closing it. It would be great to review as is

[nul800sebastiaan]

@RachBreeze I don't understand this change (adding if (formHelper.submitForm({ scope: $scope })) { which was not there before) and the removal of the block:

            if (vm.login && vm.password && vm.login.length > 0 && vm.password.length > 0) {
                vm.loginForm.username.$setValidity('auth', true);
                vm.loginForm.password.$setValidity('auth', true);
            }

Can you explain why these changes were made?

[nul800sebastiaan]

I'm still not entirely sure about formHelper.submitForm but that seems to work just fine in a lot of scenarios I tested to make logins fail etc (incl. causing server errors by breaking the web.config).

I added back the block above

            if (vm.login && vm.password && vm.login.length > 0 && vm.password.length > 0) {
                vm.loginForm.username.$setValidity('auth', true);
                vm.loginForm.password.$setValidity('auth', true);
            }

As you can read from the comments this was there because when server errors happen you can never resubmit the login as filled in because they both need to change first. This doesn't hinder the a11y fixes for marking fields as invalid when they are invalid though, so that new code works fine.