Signature components
Use a signature component when a person must make an explicit declaration and provide a typed name, a drawn signature, or both. A signature component records a confirmation within the service; whether it meets a particular legal or policy requirement depends on the service context and should be agreed separately.
Write the declaration first
The declaration is the important part. State exactly what the person is confirming and place it immediately before the signature control. Keep it plain, specific and complete.
flowchart LR
A[Read declaration] --> B[Confirm agreement]
B --> C[Provide typed or drawn signature]
C --> D[Review before submission]Do not use a signature to make a vague statement appear formal. If the person is confirming eligibility, accuracy, authority or a condition of submission, say that explicitly.
Choose a signing method
| Method | Use it when | Accessibility consideration |
|---|---|---|
| Typed name | A clear text record is sufficient. | Works well for keyboard and assistive-technology users. |
| Drawn signature | A visual signature is genuinely needed. | Provide a typed-name alternative or requirement for audit clarity. |
| Typed or drawn | The service can accept either method. | Make the default and alternatives clear. |
Do not assume everyone can draw a signature on a device. A typed-name route is generally the most broadly usable option.
Review and PDF output
Decide whether a drawn signature image should appear in generated PDFs. Include it only when it is needed for the intended record. Ensure the review and confirmation pages make clear what was signed and when.
Test the declaration, typed and drawn routes, keyboard interaction, error state, review-page display and generated PDF output. Do not expose signature data in notifications or logs unless the receiving process requires it and is properly protected.