<?xml version="1.0" encoding="utf-8"?>
Open full project

Accessible Login and Signup for a SaaS platform

This project explores how an accessible signup and login flow can reduce user errors while maintaining accessibility and trust.

The focus is on clear validation, predictable feedback and inclusive interaction patterns that work across devices.

The experience is designed to support a wide range of users and explores validation logic, error handling, loading states and success feedback.

Platform

TaskFlow Pro. Project management SaaS.

Device

Mobile and desktop.

Summary

This project explores an accessible login and signup experience designed to reduce errors and support a wide range of users.

Accessibility

  • Follows WCAG 2.1 AA guidelines.
  • Clear text labels and semantic structure support screen readers.
  • Sufficient color contrast. Color is never the only way feedback is shown.
  • Fully keyboard accessible with visible focus states and logical tab order.
  • Touch targets meet minimum size requirements.

Usability

  • Progressive disclosure for password requirements to reduce visual noise.
  • Validation feedback appears after field completion. This avoids distracting feedback during typing while still preventing common errors.
  • Errors are specific and actionable.
  • Common email typos are detected and suggested. (gmial → gmail)
  • Password strength feedback uses both text and visual indicators.
  • Clear loading, error and success states.

Visual Design

  • Simple layout with clear hierarchy and consistent spacing.
  • Primary actions are easy to identify.
  • Consistent patterns across login and signup reduce cognitive load.

Goal

To create a login and signup flow that feels clear, predictable, and usable for as many users as possible, without sacrificing accessibility.

Prototype

The prototype includes full validation logic, error handling, loading and success states.

Share your insights — leave a project review and help others grow their skills

Reviews

1 review


Hey Sanna.

I see a lot of good practices in your project. I really like that users can see what they’re typing when creating a password and that you guide them with clear validation rules.

I’m curious how you imagined the validation for incorrectly entered email addresses. Are you checking only the format, or are you also handling common mistakes like misspelled email providers?

I also wanted to ask about your decision to use two password fields. With all the good practices you already included in the first field, showing the password and validating it clearly, the confirmation step might not be necessary. For many users, repeating the password can feel tedious.

Since you have a “forgot my password” flow, users have a way to recover if they make a mistake. There’s even a case study showing that removing the confirm password field increased conversion by 56.3%, which makes this worth reconsidering. What do you think?

Hey Petar! Thanks for the questions and feedback! Yes, I imagined the validation to also handles common provider typos, such as gmial.com and suggests corrections. With the goal to prevent errors before submission, for example for users on mobile or with motor or cognitive challenges. I agree that the password confirmation fields can add friction, especially when the password is visible and clearly validated. In this concept, I included the second field mainly as a safeguard for users who rely on autofill, screen readers, or who may switch focus unintentionally.. That said, there is arguments for removing it, esp since there is a clear password recovery flow. In a real product, I would do a user test on both approaches. Interesting case study example. My next iteration would probably explore a version without the confirm field to reduce friction and improve conversion. Thank you for your feedback which helped me reflect on the balance between error prevention and simplicity.
(edited)

5 Claps
Average 5.0 by 1 person
5 claps
4 claps
3 claps
2 claps
1 claps
<?xml version="1.0" encoding="utf-8"?>