SJRK-402: Implement UI for sign-up

Description

Implement the UI for the account sign-up page in the Storytelling Tool. This work will include form validation and basic error reporting/handling.

The sign-up page should call a server endpoint to test functionality, if this work is tackled before the implementation of log-in and log-out UIs.

Attachments

Comments

• Gregor Moss commented 2020-12-01T17:02:13.356-0500

  Some concerns to keep in mind (courtesy of @@Dana):

  • how will we validate email address? i.e. what format should the email address have?
  • if we do client-side validation and opt for built-in HTML functionality and CSS to show errors, do we debounce user input to avoid marking a partially-entered value as invalid?
  • if we debounce, how long? attention should be paid to accessibility concerns around screen reader experience, i.e. how we announce an invalid entry

• Dana commented 2020-12-01T17:22:34.264-0500

  • When to show the errors? When user begins to type in the field (how would these notifications be handled by a screenreader)? or wait until the Sign up button is selected?
  • Do we show in-line error messages or provide a notification dialog? Looking at WebAIM I think inline messages are the best for clarity (directly associating the error with corresponding form field) https://webaim.org/techniques/formvalidation/#form
  • Having all/any error messages appear inline only when user selects the Sign up button seems best for accessibility, simplicity and consistency.

• Justin Obara commented 2020-12-02T07:48:09.500-0500

  @@Dana, I believe @@Lisa Liskovoi has some examples and best practices for this, so it's probably best to check with her. However, below are some of my current thoughts.

  I don't think you'd want to validate the input until after they've finished entering into the field(s). If you did it as input was being entered, even with some delay, it may affect those that have difficulty entering text. See (WCAG Guideline 2.2 Enough Time and Understanding Guideline 2.2).

  I'd probably suggest validating on submit; that way the user can understand why the form doesn't submit and we can mark the fields as necessary. If we did the validation after leaving the field, there would be some asymmetry with the e-mail field and the password/confirm comparison. That is we couldn't validate the the password and password confirmation fields are the same until they are both filled. Also this article provides some examples and reasons for why it's more accessible to validate on submission including having an always enabled submit button.

• Cindy Li commented 2021-02-26T10:57:18.044-0500

  The pull request that implements this feature has been merged into the main branch at this commit.