I examined the Universal Login Page that appears in my Auth0 application, and was surprised to see that the social login button I am using is not operable via keyboard. In fact I found 3 issues that make the page a hard-to-use experience for disabled users:
- There is a CSS rule that disables the normal browser behaviour of highlighting which element on the page currently has focus:
.auth0-lock.auth0-lock a:active, .auth0-lock.auth0-lock a:focus { outline: none }. I get it that not everyone likes to see a blue outline around links and buttons, but for users that navigate a page by keyboard, having no visual clue about where their focus currently is makes for a fairly unusable interface. There are solutions out there for detecting the case of a keyboard navigator and adjusting the CSS rules accordingly ( eg GitHub - ten1seven/what-input: A global utility for tracking the current input method (mouse/pointer, keyboard or touch). ). Seems like a simple compromise. - The inability for a keyboard user to see when they have moved focus onto a social login button is somewhat insignificant since it is not actually possible to move focus to a social login button! This fails WCAG recommendations: “Keyboard: Error. Interactive elements must be focusable.”
- A user with low or impaired vision will have trouble even finding the social login button, since the color contrast of the text label is insufficient to pass WCAG recommendations: “Colour and Contrast: 3.56. Does not meet WCAG standards for accessible text.”
These are all easy to fix, and presumably would have been easy to identify with a minimum of accessibility testing. The FireFox Developer Edition web browser has a handy Accessibility tab built into its Developer Tools panel for example which could be used to identify a similar problems.