- Contents:
- Login forms are the most common means of authenticating users.
- They usually consists of a username/email address, a password, and a primary CTA.
Guidelines
- Observe standard text entry usability guidelines when creating a login form.
- Redact password entry as the user types, and provide a show/hide functionality
- Clearly mark when authentication fails.
- Show the user what went wrong and what action needs to be taken in order to successfully authenticate.
- Provide inline validation for incorrect email entry formats.
- Provide a link to reset credentials if the user does not remember the correct combination.
- Allow the user to opt-in to having their credentials cookied for faster authentication on subsequent visits.
- Properly label the login form and provide an alternate link to enrollment for new users
Available Functionality
Password hide and show.
Click the prototype to interact with it
Opt-in to login with fingerprint on mobile apps.
Accessibility
Requirements for Automated Accessibility Testing with the aXe tool:
- Every form field must be labeled.
- The Sign In button must have a name that is read to screen reader users.
- Minimum color contrast levels must be met.
Ensure that all elements are available to screen reader users (Android/Talkback; iOS/VoiceOver):
- Swipe to ensure that you can access all static content (and welcome or other message/instructions, logo alternative text, or introductory text like “Not a Hilton Honors member?”) and to interact with CTAs (including “close window/go back” options), form elements and links.
- Unlike desktop screen readers, all of the page content – not just interactive elements – should receive a VoiceOver/Talkback outline.
- Make sure that all content is accessed in a logical order (e.g., when you swipe from the password field, do you move to the Remember Me checkbox?)
- Make sure that the field labels are announced correctly (Username, Password) and that by doubletapping in the field, content can be entered.
- Make sure that the Remember Me checkbox is announced correctly, and that the screen reader announces whether or not it is checked/selected. Double tap to select/unselect and make sure the change is announced by VoiceOver.
- When links are announced by the screen reader, make sure that there is an announcement if they open in a new window.
- Make sure that the Sign In button is announced as expected and can be activated with the double tap gesture.
Examples Implemented on OHW/Global Web
- Global Web Honors sign in form (adaptive): https://secure3.hilton.com/en/hh/customer/login/index.htm
- Implementation for sign in on OHW can be found in NHCGUEST-70
Known Accessibility Issues:
Sign in buttons most often are white text over the #009BE1 blue. This leads to a color contrast ratio of 3.1:1 and will most likely be shown as a failure in aXe testing. The error can be marked as a false positive as long as the font style is Bold or Xbold at 20px.
Requirements for Automated Accessibility Testing with the aXe tool:
- Every form field must be labeled.
- The Sign In button must have a name that is read to screen reader users.
- Minimum color contrast levels must be met.
Requirements for Manual Accessibility Testing:
- Ensure that all elements are available from the keyboard only:
- Tabbing through the form elements and links should happen in a logical order.
- Users should be able to tab to all form elements (Username and Password fields, Remember Me checkbox, etc.)
- When hover states are used, the same effect should be shown when the element receives keyboard focus.
- When each element receives keyboard focus, it should have a visible focus indicator (visible focus varies by browser).
- It should be possible to select elements from the keyboard only:
- Checkboxes should be able to be selected with the spacebar
- Buttons should be able to be activated with the spacebar or enter key
- Links should be able to be opened using the enter key
Ensure that all elements are available to screen reader users (with JAWS/IE, NVDA/Firefox, or VoiceOver/Safari):
- Use the up/down arrows to access static content (and welcome or other message/instructions, logo alternative text, or introductory text like “Not a Hilton Honors member?”)
- Use the tab key to interact with form elements and links.
- Make sure that the field labels are announced correctly (Username, Password).
- Make sure that the Remember Me checkbox is announced correctly, and that the screen reader announces whether or not it is checked/selected.
- When links are announced by the screen reader, make sure that there is an announcement if they open in a new window.
- Make sure that the Sign In button is announced as expected.
Examples Implemented on OHW/Global Web
- Global Web Honors sign in form: https://secure3.hilton.com/en/hh/customer/login/index.htm
- Implementation for sign in on OHW can be found in NHCGUEST-70
Known Accessibility Issues:
Sign in buttons most often are white text over the #009BE1 blue. This leads to a color contrast ratio of 3.1:1 and will most likely be shown as a failure in aXe testing. The error can be marked as a false positive as long as the font style is Bold or Xbold at 20px.
See Also
Further Reading
Related Elements
Related Components
Version History
| Date/Time of Change | Who Made the Change | Change Details |
|---|---|---|
| May. 08 2017 5:57pm | Initial content entry |