Designing Accessible Sign Up Forms

my name is Michelle and Lee y'all can

also call me Mitch

and today I'm going to be speaking to

you about designing accessible signup

forms so I know that not everyone reads

the BIOS on the Macan website so you

might be wondering who is this chick I'm

a designer a developer and an

accessibility Crusader here I've

inserted myself into a scene from Monty

Python and the Holy Grail so my husband

lost his leg in a motorcycle accident

and he uses a prosthetic here's a photo

of him his prosthetic and accessibility

is something that we always factor in

when we're making travel plans so

recently we were planning a trip with

friends who have children and so I

visited a travel website that

specializes in kid-friendly property

rentals and it's aimed at families and

it offers global destinations so it's

safe to assume that they have a global

audience so I get to the home page and

here it is and at first I was pretty

excited you know it's very fun it's

colorful and it's been featured on some

very trendy lifestyle blogs it's like

that's a good sign

however as I started using it especially

when I began to sign up for the service

I began to notice some really glaring

accessibility issues and so I thought it

would be an interesting exercise to

redesign the user flow of signing up I

know to be clear this company has no

idea who I am

and they didn't pay me for this they

don't know about this presentation but I

I really believe that we designers can

have an outsized impact on users with

disabilities by focusing on really

common design patterns

such as signing up for service so let's

talk about what is not accessible in

this website so for starters none of the

links have a focus date they've actually

disabled the default focus date which is

really bad practice it would be really

nice if there's a skip to main link so

that users who are navigating the site

with the tab key could skip over the

navigation and not have to tab through

the entire thing every time they load a

page so you click on the sign up link in

the main nav and you get this pop-up

window here and at the top there's a

button that says sign up with Facebook

and below that there's a form to sign up

with email and below that there's a link

to login if you already have an account

so what this means is that if you're a

user who already has an account you have

to tab through the sign up with Facebook

button in this entire form to get to

that login link and that's that's a lot

of tabbing also the text contrast is way

too low I could barely see it with my

glasses on and so the text on the right

side of the form that's actually labels

that's it's a first name and last name

so those are labels but the text on the

left the seven plus character is an

optional that's placeholder text so that

means it disappears when the user starts

typing so let's say your user with a

cognitive disability like poor

short-term memory maybe of a migraine or

maybe you're just busy and distracted

and you start to type in your password

and as you're typing you forget that it

needs to be seven or more characters so

maybe you went to like a six character

password when you do that you're taken

to this page and at the top of the page

there's another sign of the Facebook

button and then below that it says oops

and you see the errors are listed and

then the field in question has been

highlighted

um a really strange placement for the

sign up a Facebook button I it really

doesn't need this much hierarchy it's

nice to offer it as an option

still if signing it with Facebook is

easier but a screen reader is going to

read that first and that's not really

the point of this page I do like that

the header one that says oops makes the

intent of this page really clear you

know you read that you know that

something went wrong it would also be

nice if the title tag in the markup in

the head of the markup reflected that

there are errors on this page it could

say something like two errors or it

could even say oops or something so an

assistive technology device would read

that title tag and also you know sighted

users who are you know looking at their

browser tabs would be able to see that

in that little browser tab at the top um

I do like that the errors are listed at

the top so you you see them right away

we're not obscuring them that's nice it

would be better if the container that

the messages are in was programmatically

focusable so that way that you could

actually tab to it and navigate to that

container and the way you do that is you

give it a tabindex of negative one

it'd also be great if the error is

linked to their related input on a form

this short it's really not a big deal to

navigate down to that input but if this

was a very long form that could be a lot

of Labor and a lot of cognitive load and

the error text contrast this red on pink

is way too low

all right so let's say you get that form

submitted then you're taken back to the

home page and now there's this blue bar

at the top and it tells you to like

update your profile it's really not

clear at this point whether you

successfully signed up for the service

you know this blue bar is very easy to

overlook because it blends in so well

with the design and the text contrast

for that content in the blue bar is way

too low so you're unlikely to notice it

at all so this is kind of like that

metaphor an accessibility community of

taking someone out on a date and leaving

them in a field this is you you don't

know how you got here or where to go all

right

so let's take a look at my redesign

all right so starting with a home page I

didn't really dig into the entire home

page but I added a skip to main link

all right and then when you click the

sign-up link in the main navigation and

you get this pop-up window there's a

button to sign up with Facebook there's

a button to sign up with email and

there's a link to login if you already

have an account but so here we have

really three options you can tap through

which means that a user doesn't have to

tab more than three times to get to the

one that's right for them I want to note

a couple things in the markup so these

buttons the icons within the buttons the

Facebook icon and the little envelope

for sign up with email these have an

Aria hidden attribute they really don't

add to the content of the buttons

because the text makes it really clear

you know what their intent is and so

it's not necessary to for screen readers

or assistive technologies to understand

those icons and their X at the top right

so we see an X and we understand

intuitively that you know that means

you're gonna close the window right but

uh assistive technology can't pick up on

this visual cues so it's an SVG file and

it has a title attribute as well as some

hidden text that says close window in

order to provide some extra information

to assistive technologies all right so

let's say you click on the button that

says sign up with email then you're

taken to this page let's create your

account and we have a form to sign up so

for starters the elements have a focus

date so this first form field is in

focus State you can see that it's gotta

yellow highlight around it it's a little

hard to see over the on the projector

but there's a drop shadow on this field

and it's a little bit lighter so there's

a number of visual differences that make

it stand out as being in focus state

other things to note so the required

fields have asterisks so we have a

visual indicator that they're required

they also have an acquired attribute in

the markup and some visually hidden text

saying this this field is required and

if you're wondering like you know why do

we have you know both the required

attribute and the visual

and texts like this it seems like a lot

different types of assistive technology

is work differently so we just want to

make sure we're addressing all of them

all right and also all the form fields

have labels and just to be clear that

text in the middle of the field is

actually label it's not placeholder text

so labels are great because well for

starters they tell you what type of

information is being asked for so they

have that very practical purpose umm

labels also increase the hit area of a

form field so if a user taps or clicks

on the label instead of the field

they'll actually select the entire sound

field and this is great for users with

motor impairments or just you know some

of us who are a little less coordinated

uh top aligned labels or vertically

aligned labels as opposed to

horizontally aligned labels that could

be on the left or right so top aligned

labels reduce form completion time

because they require only a single eye

fixation to take in both the label and

the field you couldn't really just see

it all at a glance and so that actually

reduces the completion time for your

entire form I want to note that the

design pattern I chose of having this

label text within the field and it gets

a little smaller when you click on it

and make some space for you to type this

design pattern is pretty controversial

and you could argue that a user might

see a form field with this label and

think that you know that value has

already been provided they don't need to

fill it out or maybe they'll think it's

a placeholder text it it could be a

little deceiving on however it's a

pattern that you see in Google's

material design system and also on the

Apple website so I think it's becoming

more and more common and this is

definitely the kind of thing you would

want to test out with users to confirm

if it's confusing or not I think that we

can try new things as designers and you

know

Advanced Design on the web and still

make sure that we're always looking to

our users and making sure that it's

really serving them alright so moving

down the form to the password field so

thinking about passwords and we forget

our passwords a lot and sometimes we

must enter them we are in the middle of

typing and we get distracted or maybe we

have a cognitive disability like ADHD

and we can't remember you know how many

characters we've typed you know or maybe

we have a motor impairment and it's hard

to tap the correct keys so I thought it

would be really useful for the user to

have the option of showing the password

so there's a button on the right side of

the password field and it says show and

when you click it you can see the

password and it changes to hide and you

can click hide and then your password

will be hidden if you have a privacy

concern all right and then um all of

these form elements meet we have two

point one contrast requirements so we

can 2.0 specified color contrast

requirements for text and that was kind

of a loophole because you could have

other you know parts of your interface

that are really essential to

understanding the design and they they

could have really low contrast and still

technically meet with a 2.0 so we have

non-text content such as these form

fields and specified the contrast

requirements for that so you know it's

really important that you can see these

in order to attract with this page and

so we want to make sure that they are

covered as well

all right so let's talk about this date

input below so here we have a question

you must be 18 years old or older to

sign up please verify your birthday and

this is a really common question in

similar competitor websites to ask users

to verify their age before they could

sign up for the service well I was doing

some competitive analysis I thought well

it would be good to include this

question while we're redesigning this

whole experience and that got me

thinking about date inputs you know

what's you know date formats they're not

universal and my husband grew up in

Europe and so he uses European date

formats which go day month year and I

grew here in the US and so I used the

date format and month date year and for

this reason I had forgotten his birthday

a lot of times

in our anniversary's and many other

important days so I wanted to make date

and put really unambiguous and make it

really clear you know exactly how the

user needed to fill out this portion of

the form in order to answer you know

quote-unquote correctly

cuz that's I mean it could be correct in

the sense that they filled it out but it

could be the wrong date for their

birthday and then they wouldn't be

eligible for the service so so it's

thinking okay what's the right way to

ask for date input to maximize I you

know the accuracy of the information

that you're receiving so my first

thought was okay we'll use a calendar

date picker because you can see the

calendar and its really an Nvidia as

what day you're picking and calendars

are pretty universal um but actually

according to Nielsen Norman group but

they're really best when you're asking

for a range of dates and they're also

the most user friendly when you're

asking for dates that are really close

to the present time and a birthday could

be any time of year

okay so calendar date pickers out so

then I thought all right how about a

select input so user they might not even

see the label maybe they're not paying

attention but they would click that

drop-down arrow and they would see a

limited list of options and it would

make it really clear what they were

selecting it was the months they could

be spelled out if it was the days of the

month it for the year etc um however

select inputs increase interaction costs

because they're adding a lot of clicking

and scrolling and

so okay select inputs were out however

Adams silver in his book form design

patterns Nielsen Norman group and the UK

government which is really big on

accessibility all recommend asking the

user to provide dates through text input

three fields for month day year this is

the simplest most straightforward option

so of course that was the right one uh

and furthermore even if you have some

other method of asking the user to

specify a date like a calendar date

picker it's really best practice to let

the user provide it via text input in

addition to whatever widget that you

have in place so DQ has a great

accessible calendar date picker but they

also allow for text input and that's

part of that design pattern that they've

created and I link to that at the end of

this presentation by the way so okay

cool we've got text input and the UK

government in their accessibility

documentation take it a step further and

they recommend that you add the

autocomplete attribute to text inputs

for things like birthdays that the user

might have entered into their browser in

the past so that it autocompletes and

we're making it a bit of a smoother

experience so okay cool this is all

great but I don't want to leave it alone

because you know I was thinking what

about when you're not asking for

birthdays what if you're asking for

information that the user probably

hasn't typed into their browser before

you know how would you address that and

you know my first thought was oh like I

could use chosen KS that's like great

plugin it's very pretty it's definitely

an industry favorite so I went to the

chosen KS github repo and I took a look

at their issues to see if anyone has

longed issues about accessibility and

you know how that had been handled

have an accessibility documentation

which was already a red flag and once I

looked at the issue section I realized

that for the people who created chosen

accessibility is kind of an afterthought

you know it's definitely not a thing

they're prioritizing so I didn't want to

use that but there are a lot of options

out in the wild and I've linked them at

the end of this presentation you should

definitely take a look I reached out to

the web accessibility initiatives

interest group it's an email list it's

just a group of wonderful people who are

very excited and interested in

accessibility and I said hey guys what

are some accessible autocomplete plugins

or autocompletes that exist in the world

and I got some really great feedback so

I definitely take a look at that if you

decide to create your own autocomplete

you're gonna cut it all up from scratch

yourself that's definitely an option a

few things to note about that so for

your list of options of predetermine

options you want to wrap that in a UL

tag so html5 also has a data list

element it was specifically created for

autocomplete so you'd think that would

be the right answer but it's not

compatible with Safari or ie9 so until

it is that one's out all right

you also want to use the Aria attribute

role equals combo box so that's the

attribute that will describe two

assistive technologies what is happening

here and you want to make sure that your

list of options are navigable by

keyboard so I'm creating this you know

requires a fair amount of JavaScript but

depending on your user flow it might be

worth it to you know invest that time

and filling out that interface

some of you might be wondering you know

how about just having the user check a

box to verify that they're 18 years old

or older wouldn't that be simpler so for

starters that's not as fun right but

also you know there could be a business

reason to want to gather demographic

data about your users so there might be

times when you do want to collect their

birthdate all right so as you're filling

out your form you want to get some

feedback to know if you're doing it

right and I'm not a huge fan of the

traditional design pattern in which you

fill out a form you know go through all

the fields and maybe you have to look

stuff up or think about it and then you

hit submit and it takes you to a new

page and maybe you have some errors so

you have to go back and like think about

you know what you did wrong and it's

just it's a lot of cognitive load and

extra steps so I was thinking it would

be really nice to have some inline

dynamic validation that would totally

user you know whether or not they

correctly filled out each field as they

go so I did some research into that just

to confirm whether that was no great

idea or not and the london-based

usability for Etra in partnership with

Luke Wroblewski he's the author of the

book web for design highly recommend

also link to at the end of this

presentation they did a study when there

in which he compared odd forms with

inline dynamic validation with the more

traditional design pattern of hitting

submit and then seeing errors and they

found that those with inline validation

were easier to fill out participants

completed them more quickly they were

less error prone there's a higher

success rate and a higher rate of

satisfaction among users there was a 22%

greater success rate a 22% decrease in

errors and a 42 percent decrease in

completion time so that's pretty

significant it's worth noting that this

this approach works best

when you're asking for information

that's not self-evident to the user like

their name or their zip code so in that

way this form might not be the ideal use

case and you know in line validation may

also be kind of annoying to some users

you notice it's appearing as they're

trying as they're typing so it's

possible that you know it would make

more sense for a longer form or a more

complex form and you would again

definitely want to use your test this a

few things to note about how this is

built so if a field is filled out

incorrectly you want to add an RA

invalid attribute to flag that there is

some kind of issue to assistive

technologies

because there's new information

appearing on the page as you go you

could employ Drupal oral alerts to

notify assistive technologies that

there's some new information on the page

right we have only these icons on the

left there checked next to the correct

fields and X's next to the in correctly

completed fields these icons are they're

pretty large they're very clear they

meet minimum contrast requirements for a

non text content that we talked about

earlier and even though they're red and

green which is not great for users who

are colorblind they're distinct enough

from one another that you know hopefully

there won't be any confusion and the

errors that appear in line are directly

above the fields that they relate to and

they're wrapped in the label tag so that

they're associated with those fields

when it's assistive technology is

parsing the page

all right so you fill out the form you

get it successfully submitted and you're

taken to this page and it's a success so

all right you know that you've had

success you can feel pretty confident

that you've submitted the form and

there's some options for moving forward

there's a link to update your profile or

you can start browsing home so users

know that they've signed up and they

have next steps and a really clear path

forward going back to that metaphor

about you know taking someone out on a

date we're not leaving them in a field

we're walking them to their doorstep

alright so all of these examples that I

showed you these are best practices and

they're all backed by research but you

absolutely want to be testing your work

with users with disabilities that is

hands-down the best way to validate if

it's truly accessible and here's a list

of resources I've loaded my slides to

the mid camp website so recommend you

take a look at them and I'm going to

open the floor for questions yes I

noticed that there was a passport

verification

you mean like re-entering your password

yeah I looked into that and

a lot of people feel that asking the

user to enter their password twice it's

kind of a blocker it's asking them to

take another step I believe there's been

some research into how users respond to

it and it does result in higher

abandonment rates I think showing the

password is nice because that way they

can double-check to confirm whether

they've entered it correctly yet

percent to anticipate when if the person

didn't know like mother

spelling along yes exactly

I recommend yeah so sorry did you say

are there any auditing tools

oh yeah there's so many good ones out

there um I will start by saying that an

auditing tool doesn't replace having a

real user test it but it can be a really

good first step to catch all the

low-hanging fruit so DQ is excellent and

they created ax score which is like a

library of excessively guidelines Google

uses it so if it's good enough for

Google it's probably good enough for the

rest of us and it's actually been

integrated into Chrome's accessibility

feature so that's pretty nice so there

are some like different tools built off

of ax core but DQ also has like their

own testing tools so those are great I

also like site improve and they have

some free browser plugins they're really

useful you could also sign up for their

service and that does a more

comprehensive site scanner as their

browser plugins are really just for

scanning individual pages what else oh

goodness

a patch yellow group has a lot of

testing tools accessibility sheriff and

there's there's so many blog browser

plug-ins out in the wild like wave is a

great one so I would recommend starting

with those there's also some great

guides for manual testing I think the

web accessibility the WOAI

web accessibility initiative website has

some resources for learning how to do

your own manual testing and those can

you know help you catch a lot of issues

even if you're not able to do testing

with users with disabilities which which

is ideal but not always possible

so the way you were specifically

focusing on forms and your presentation

but in your example site they're not

using any

indicators for links in terms of color

underlining in names that drives me

crazy it it's really bad practice um

there are times when is considered

unnecessary to provide visual indicators

but those are only for things like a

navigation where you know someone will

look at a navigation at the top of the

page and assume those are links but you

should still have a visual indicator for

like focus and hover state but yeah a

lot of websites the links will only be

distinguishable by color and maybe the

color doesn't even contrast very much

with the content around it and it's it's

pretty problematic especially because

it's so easy to resolve I mean the very

least you could underline the link and I

know some people hate underlining links

and things that looks ugly but there's

some great CSS solutions for creating

more elegant or more interesting

underlines you have background color you

know it could be bold it could I don't

know move a little when you hover over

there's I think there's really no good

reason not to address that but a lot of

people just choose not to

yes you're like I'm like the focus on

poverty

and you don't like good minds

how does that translate

yeah so mobile phones won't have the arm

hover state but they'll still have the

focus slash active see so yeah that's a

good question because sometimes you

create this beautiful hover State and

then you realize so what we're going

your mobile device and what a bummer

yes

yeah it's

so for accessibility it's really

important not to assume you know exactly

what devices your users are engaging

with so that's why you'd still not have

focused aid for mobile

[Music]

right