Cognitive Accessibility Design Pattern: Provide a Login that Does Not Rely on Memory or Other Cognitive Skills

User Need

I need to be able to use a site without remembering or transcribing passwords and usernames.

How it Helps

People with memory impairments often forget their passwords and are not able to login. Their solutions often are only sometimes helpful and have security risks:

• They may have to look at or listen to text several times to copy or type it into a form field.
• They may reuse a single password or use a simple-to-remember password, which they can remember.
• If they need to change their password or use a complicated password they may store passwords insecurely, such as written on pieces of paper which other people can see.

They may also struggle with other steps during login, such as:

• entering characters in the correct order,
• entering characters correctly with a limited number of tries (resulting in being locked out),
• finding a PIN,
• working out puzzles or distorted letters,
• copy characters correctly from another device.

Users can stop after getting frustrated with time-limited procedures or presentations of digital security tokens. Or they can be locked out of vital services because of their disability.

Without this design requirement, many people cannot use an application or content at all. See Security and Privacy Technologies issue paper for the full description of this issue, and how it stops people from using web services that are often critical. For example, many people cannot make doctors’ appointments, etc., by themselves. This may be partly responsible for the reduced life expectancy of people with learning and cognitive disabilities.

More Details

There are many ways to meet this design pattern:

• Use Web Authentication: An API for accessing Public Key Credentials [[webauthn-2]] to support inclusive alternatives that do not rely on typical cognitive abilities. For example, hardware authentication devices, smartcard or FIDO.
• Provide automatic user authentication based upon the use of a trusted device (to which the user has already logged in with their own identity). The user does not have to transcribe characters, but may have to press a link to identify they have the device.
• Allow a biometrics option.
• Use a system the user is already logged into via third-party authentication services (e.g., OAuth etc.).

Methods of meeting requirements for alternative user authentication would include:

• Clicking a link sent to an email address or a phone number. (Note that this is easy to implement and may be useful for minimal security, such as allowing comments on a blog.)
• Logging in by using information present in users’ personal documentation, such as the total number of a current account balance, with explanation on how to find this information.

Examples

Use:

1. Web Authentication: An API for accessing Public Key Credentials [[webauthn-2]].
2. Single Sign-on (SSO) that allow users to access many sites with a single login (federated login).
3. Two step authentication with Bluetooth links (no copying).
4. Quick Response Codes (QR Code).

Avoid:

1. Using two-step authentication that requires copying.
2. Using a password and not allowing pasting into the field.

User Stories and Personas

User Story

Personas

• Jonathan : A Therapist with Dyscalculia
• Tal : A Student who has Dyslexia and Impaired Eye Hand Coordination

Glossary

• Cognitive Accessibility Glossary