Project #4: Sign Up Now
September 26, 2016
Introduction
Passwords are the worst.
I believe there is universal hatred for the phrase:
"Password must contain a special character".
There is one service I use that requires passwords to be updated each month.
My password started out as "MyPassword" (not really).
And now it is "MyPassword!!!!!!" (really ending in 6 !'s).
I had the idea to make a website to parody the process
of signing up for a new service.
It took more time than I expected,
but I also learned more than I would have guesses.
The website is live here:
sign-up-now.s3-website-us-east-1.amazonaws.com.
The Specs
- provide increasingly frustrating error messages
-
I thought it would be funny for the messages
to start out realistic ('password must be longer than 6 characters'),
and get more and more absurd ('password must contain name of the capital and largest city of Qatar')
- have no backend (HTML, CSS, JS only)
- this is a lightweight project
-
there is no incredibly simple and cheap hosting solution for web apps,
at least as compared to using
AWS S3 for static sites
- not look terrible
- no one will take a page seriously if it looks like trash
-
I wanted to try and build a page without
any frontend framework (i.e. Bootstrap)
The Code
The code for this project is simple.
All of the files are publicly available.
What Did I Learn (Technical)
-
JavaScript —
this was my first time using Regular Expressions in JS.
I didn't come across anything unexpected,
but there are nuances to the different methods (.test, .search, .match)
and building the RegEx.
-
Design —
I have a bad habit of slapping Bootstrap on everything.
I recently came across a great
blog post
that convinced me decent design isn't too difficult.
I stole all the code from that article, and
I think the site looks pretty good for 66 lines of CSS.
-
Web Accessibility —
I posted what I built a few places, and a friend wrote to tell me
she thought it was neat but that my tiny page failed certain basic
web accessibility standards.
(My friend's day job is working with accessibility.)
This ended up being a fun rabbit-hole
to chase down, so it gets its own section.
Web Accessibility
The web, on a fundamental level, should be accessible to everyone.
This includes, as examples, people that are blind and color blind.
If web pages are built properly, there are tools that allow all users
to interact with your website. A common and important tool is a screen-reader.
Largely, if you use proper semantic HTML everything will take care of itself.
But what if, for example, you put an <h1> on a page
without any content? This is a common thing to do, if you plan to fill
the h1 with dynamic content using JavaScript after some user-interaction.
To a sighted-user, this is no problem. But it messes up a screen-reader.
It is assumed that an h1 contains the most important text on a page,
and if it's empty things get confused.
Now that you know that's a shitty thing to do,
I hope you'll be more conscious of it
1.
These are things I did wrong—
-
all form fields should have a label associated with it.
If not, a screen-reader cannot associate text with fields.
Check out the commit
.
The label has a
for attribute that links to the id of the form field.
-
text should have at least a 4.5:1 color contrast with its background.
Who knew? I found a
great website to help find alternate colors.
-
if you add something important to a page (like an error message)
without a new page load, that message needs to be announced
by a screen-reader. HTML accepts
ARIA attributes (Accessible Rich Internet Applications)
specifically so the web works better for people with disabilities
2.
I won't go into details, but
I added
an
aria-describedby
to link the error message to the password field. As a result,
it is announced by the screen-reader.
What Did I Learn (Non-Technical)
I often take on big projects (Project #3: Gain Fluency in Go)
that have no obvious end. It was nice and fun
building something with such a small scope.
Additionally, it's sometimes the quick features and projects
that bring people the most joy.
I spent a long time building a
big thing
I couldn't convince anyone to use.
This took a few hours, and ~300 people played with it
(small numbers for BuzzFeed, big numbers for me).
Some people even reached out to say they got a big kick out of it.
Lastly, wins beget wins. I didn't expect to learn about accessibility
with this project. But if you build something and show it to people,
it can lead to unexpected places. Last week I knew next-to-nothing about
web accessibility; now I know slightly more than that 😃.
1
The real truth is, I don't care much about web accessibility.
I do not have any of the disabilities solved by accessibility standards,
nor do any of my friends or family.
With that said, I do a lot of things I don't care about.
In fact, I feel strongly about doing many of these things.
It comes down to low-cost, high-upside.
An example:
I think the word "guys" is gender-neutral.
However, lots of people disagree.
Therefore, use of the word "guys" makes certain people feel less included.
I don't want to make anyone feel excluded—especially
within a community I love.
Therefore, I try not to use the word "guys".
It costs me nothing to do that, and is valuable to other people.
Problem solved!
Similarly, it isn't difficult to build websites that are accessible.
And it has the potential to be hugely helpful to someone else.
If you build things for the web, you have a responsibility
to be a good citizen.
2
If ARIA sounds vaguely familiar, you have seen it before in the Bootstrap documentation:
<input type="text" class="form-control" id="inputSuccess2" aria-describedby="inputSuccess2Status">