Search topics
Signature pads with no way to type a signature
A form's signature field is a drawing pad and nothing else, so anyone who can't draw with a mouse, a finger or a stylus can't sign the form or send it.
new SignaturePad(canvas) The problem
People who use a keyboard, a switch, voice control or a screen reader can't sign a rental agreement whose only signature field is a drawing pad, so they can't send it.
A bike rental shop asks each customer to sign its rental agreement online before they collect the bike. The form has a Full name field, then a Signature box with a pen line and a Clear button, then "Sign and send". The box is a signature pad, a canvas that draws a line wherever the mouse, a finger or a stylus moves while it is pressed. It feels like signing on paper, which is why the shop chose it.
A keyboard user fills in the name, presses Tab, and lands on Clear: the pad was skipped. Nothing they can press draws in it. They press "Sign and send" and get "Please sign in the box." The agreement can't be signed, so the bike can't be rented.
WCAG 2.1.3, Level AAA, asks for everything to work from a keyboard, with no exceptions. 2.1.1, the Level A version, allows one: a function whose underlying job needs a path traced by the pointer, not only where it starts and ends, such as freehand drawing. A drawn signature may be one. The W3C's notes on pointer gestures say that "entering your signature may be inherently path-based (although acknowledging something or confirming your identity need not be)."
So the pad may rely on the exception 2.1.1 allows, but at Level AAA there is no exception to use. The way to pass is not to make the pad drawable by keyboard, but to give the function, signing the agreement, a way that needs no path at all: typing a name.
The browser has nothing to offer here. A canvas is a bitmap: it has no role, takes no focus and reads no keys unless the author adds them, and signature pad libraries such as signature_pad listen for pointer, mouse and touch events only. The hidden field that carries the signature is filled from the drawing, so nothing else can fill it.
Signing usually comes at the end of a flow: a rental, a delivery, a consent form, a lease. Someone who has filled in every field with a keyboard, a switch or their voice reaches the last step and can't finish. On a phone with a screen reader on, a touch goes to the screen reader first, so drawing takes a pass-through gesture, in a box the person can't see.
3 of 10 groups affected
- No vision (affected)
- Low vision (not affected)
- Colour vision (not affected)
- No hearing (not affected)
- Hard of hearing (not affected)
- No speech (not affected)
- Motor (affected)
- Reach, strength (affected)
- Cognitive (not affected)
- Seizures (not affected)
- Limited manipulation Keyboard and switch users have no way to draw a line: Tab passes the pad without stopping, and no key puts anything in it. Voice control can click the pad, but can't move a pointer along a path to sign.
- Without vision The canvas is silent, so a screen reader user hears the word Signature and the Clear button with nothing between them, and drawing a signature in a box they can't see is guesswork.
- Limited reach and strength Holding a mouse button down, or a finger on the glass, while moving it along a path takes strength and steady hands; a head pointer or a mouth stick can press, but can hardly write.
axe and similar scanners see a canvas with no role, which is not a control, and a Clear button with a name, and report nothing. They don't try to sign, so they don't learn that the form can't be sent without drawing. AI tools asked for a signature field may reach for a canvas library and add nothing else, as the examples of libraries such as signature_pad show a pad alone. The EaseWeb audit sends a review lead for each canvas or SVG at least 120 by 60 pixels that listens for pointerdown or mousedown, takes no focus, and has no text field in its fieldset, or failing that its parent, so a person can check whether what it draws can be typed.
Try it
Sign the rental agreement and send it, using the keyboard alone.
Type a name, then press Tab: does anything let you sign without drawing? Then apply a fix and try again. The pad still draws with a mouse or a finger.
Broken Can you fix this?
The fix
Let people sign by typing their name.
<form class="agreement"> <p class="field"> <label for="name">Full name</label> <input id="name" name="name" autocomplete="name" required> </p> <div class="signature"> <p>Signature</p> <canvas id="pad" width="400" height="140"></canvas> <button type="button" id="clear">Clear</button> <input type="hidden" name="signature" id="signature-data"> <p id="signature-error" class="error" hidden>Please sign in the box.</p> </div> <button type="submit">Sign and send</button></form>What is wrong3 points
The name field and the buttons are fine. The signature is where it fails.
- Tab moves from Full name to Clear: the pad is never a stop, and no key draws in it.
- The hidden field is filled only from the drawing, so there is no other way to sign.
- "Sign and send" refuses the form until something is drawn, so a keyboard user can't send it at all.
Type or draw
<form class="agreement"> <p class="field"> <label for="name">Full name</label> <input id="name" name="name" autocomplete="name" required> </p> <fieldset class="signature"> <legend>Signature</legend> <label for="typed-signature">Type your full name to sign</label> <input id="typed-signature" name="typed-signature" autocomplete="name"> <p>Or draw your signature</p> <canvas id="pad" width="400" height="140"></canvas> <button type="button" id="clear">Clear drawing</button> <input type="hidden" name="signature" id="signature-data"> <p id="signature-error" class="error" hidden>Type your name or draw your signature.</p> </fieldset> <button type="submit">Sign and send</button></form>How it is fixed5 steps
- Group the signature in a
fieldsetwith the legend "Signature", so both ways to sign are read as one question. - Put a labelled text field first, "Type your full name to sign". Tab reaches it, a screen reader reads its label, and voice control can dictate into it.
- Keep the pad after it, under "Or draw your signature", for people who like to draw.
- Accept the form when either one is filled in, and only read the drawing when there is one.
- If neither is filled in, say both ways in the error and move focus to the typed field.
This fixes the Before and passes 2.1.3: signing no longer needs a path, because a typed name does the same job. The drawing stays as a shortcut for people who want it.
Why this fix: Make a gesture a shortcut, never the only way
Both pass. Type or draw keeps the pad for people who expect to sign by hand, and costs a second field and a check that accepts either one. A typed name only is the smallest form and the least to maintain, and suits a business that has no use for the drawn mark. Choose by what the signature is for: if the business or a regulation needs the drawn mark kept, keep the pad beside the field; if the signature only records agreement, a typed name does that alone.
Whether a typed name counts as a valid signature is a legal question for the business, not a technical one, and the answer depends on the agreement and the country. Several e-signature services offer a typed signature beside a drawn one, and some let the form's owner switch the typed one off, which can leave drawing as the only way to sign.
A Full name field and a typed signature both ask for the name. Don't fill the signature in from the name field, since then the person never signs anything; autocomplete="name" lets the browser offer it with one choice.
An upload of a picture of a signature is not enough on its own. A file input works from a keyboard, but someone who can't draw may have no picture of their signature to hand.
Making the pad draw with the arrow keys is not a fix either. A line drawn with arrow keys is not a signature, it is slow and hard work for anyone who presses keys with effort, and a screen reader user still can't see what they drew.
Some functions have no typed way at all: freehand drawing, painting, or a game steered along a path. Such content can't pass 2.1.3, and the W3C's notes on the criterion say so. A drawing tool can still give keyboard ways to everything that isn't a path, such as shapes, colours and moving what has been drawn, which 2.1.1 asks for.
If the drawing only stands for agreeing, as on many forms, the signing itself doesn't need a path, and a pad with no other way may fail 2.1.1 at Level A too. That failure belongs with div buttons that can't be reached with Tab and its topic; the fixes here mend both.
Verify the fix
4 checks, no mouse.
Test with: Keyboard, Screen reader, Speech input
Record the OS, browser and assistive-technology versions, the build, the date, and the actual result of each step. Repeat after the form or the signature library changes.
Limits
This is a starting pattern, not a guarantee for every application. It shows how to give a signature a keyboard way; it doesn't decide whether a typed name is legally enough for your agreement. Dragging and other gestures with no single-pointer way are covered in pinch, drag and tilt gestures with no button. Check the complete flow with people who rely on a keyboard, a switch, voice control or a screen reader.
This is a recreated teaching example, not a finding about a named client. The code is a starting pattern: test it in your own product. No completed assistive-technology test is claimed here.
EaseWeb service
Fixed it? Keep it from coming back.
I turn guides like this one into rules your coding agents follow and checks your CI runs. Then I retest by hand with a keyboard and screen readers, periodically.