XClose

Accessibility

Home
Menu

DocuSign accessibility statement

This accessibility statement applies to the DocuSign application.

DocuSign is a third-party application run by DocuSign. We want as many people as possible to be able to use this application, which means that you should be able to:

  • change colours, contrast levels and fonts
  • zoom in up to 300% without the text spilling off the screen
  • navigate the website using just a keyboard
  • navigate the website using speech recognition software
  • listen to most of the website using a screen reader

Due to DocuSign being a third-party platform, some aspects of its accessibility are outside of UCL's immediate control. 

There are a number of customisation options for your browser and device that could help you use this website and other websites more effectively. AbilityNet has advice on making your device easier to use if you have a disability.

Feedback and contact information

Please contact us if you have an accessibility query including:

  • If you are experiencing issues with accessing information or using the website
  • If you find an accessibility problem not listed on this statement
  • If you have positive feedback on the accessibility considerations made. 

When you contact UCL's DocuSign Team, there is a process in place to acknowledge your contact, tell you who is dealing with your query and give you a timescale by which you can expect a reply.

We aim to respond to all contacts within 2 working days.

Reporting accessibility problems with this website

We formally test the accessibility of key user journeys that represent the breadth of content across our website on a regular basis against WCAG (Web Content Accessibility Guidelines) 2.2 AA standards.

We’re always looking to improve the accessibility of this website. If you find any problems not listed on this page or think we’re not meeting accessibility requirements, please contact us.

Read tips on contacting organisation about inaccessible websites.

Enforcement procedure

The Equality and Human Rights Commission (EHRC) is responsible for enforcing the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 (the ‘accessibility regulations’). If you’re not happy with how we respond to your complaint, contact the Equality Advisory and Support Service (EASS).

If you are in Northern Ireland and are not happy with how we respond to your complaint, you can contact the Equalities Commission for Northern Ireland who are responsible for enforcing the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 (the ‘accessibility regulations’) in Northern Ireland

Technical information about this application's accessibility 

University College London is committed to making this application accessible, in accordance with the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018.

Compliance status

This application is partially compliant with the Web Content Accessibility Guidelines (WCAG) 2.2 AA standard, due to the non-compliances and exemptions listed below.

Non-accessible content

The content listed below is non-accessible for the following reasons.

Non-compliance with the accessibility regulations

Sending functionality 

When using the sending functionality within DocuSign, the following two points can lead to a confusing user journey for anyone who relies upon a screen reader, which each fail WCAG 1.1.1 Non-text Content (A).:

  • Font icons (such as the status icons in the Manage Inbox) lack proper alternative text – assistive technologies may announce the font character instead. 
  • Decorative font icons (such as the key icon in the Document details page) are not hidden from assistive technologies, which may also announce the font character instead. 

The below can cause unnecessary or confusing information to be provided to users of assistive technologies such as screen readers. The following three points fail WCAG 1.3.1 Info and Relationships (A):

  • The heading structure is not logical on some pages.
  • Some text is incorrectly marked up as a structural heading.
  • One of the date fields does not correctly expose errors to assistive technologies.

The list of areas below can make it challenging for users who rely on assistive technology. The below all fail WCAG 1.3.2 Meaningful Sequence (A).
Content is presented in the correct reading order with these exceptions:

  • On the Manage page, the first column of the "Recipients" table is not visible but the word "untitled" is announced to screen reader users.
  • On the Manage page, the "Actions" table header is visually hidden and only announced to screen reader users.
  • On the Advanced Options dialog, the "Recipient Privileges", "Reminders", "Expiration", and "Comments" buttons are announced twice by the screen reader.

The calendar widget on the manage section is not keyboard-operable. However, alternatively, the date can be directly entered into the date field. Additionally when navigating through the site using a keyboard the options under ‘New’ are not accessible. This limits the functionality of the site for users who rely on keyboard-only navigation. This fails WCAG 2.1.1 Keyboard (A).

When creating a Conditional Field, the focus may become trapped between the fields on the document and the document button in the right panel. This fails WCAG 2.1.2 No Keyboard Trap (A).

In most cases, the Focus order of interactive elements is logical and intuitive, and in a sequence that preserves meaning and operability, with the exceptions noted below: These both fail WCAG 2.4.3 Focus Order (Level A).

  • When the "Filters" button is selected on the Manage page, the keyboard focus is moved backwards to the "Search Inbox and Folders" input field. 
  • When configuring routing rules, the Text field receives focus but is not interactive. 

In most cases, the focus is properly managed with the exceptions noted below. These fail WCAG 2.4.3 Focus Order (A): 

  • When creating a Conditional Field, after the user selects the “Create Rule” button in the Properties Panel, the rule banner appears at the top of the page, but the focus is not moved to the added content. 
  • When the “Add Comments” button in the toolbar is selected, the focus is not moved to the added content. 
  • On the Manage page, when an envelope is moved to a folder, a toast message appears and remains visible unless the user closes it, but the focus is not moved to the toast message. 
  • When a Dropdown field is used, and the user selects the “Add Option” button in the Properties Panel or Edit Values modal dialog, an input field is added above the “Add Option” button, but the focus is not moved to the added content. 
  • When configuring routing rules and the user selects the “Add Condition” button, input fields are added above the “Add Condition” button, but the focus is not moved to the added content. 
  • In the Advanced Options dialog, when the navigation buttons are selected in the right panel, the focus is not moved to the respective section 

Most accessible names for interactive elements include the visible label with the following exceptions: The below options fail WCAG 2.5.3 Label in Name (A).

  • In the Help menu, the link text "Download on the App Store" and "Get it on Google Play" are not included in the accessible names for the links.
  • When creating a Conditional Field, the visible text for the input field in the rule banner at the top of the page is not included in the accessible name.
     

The checkboxes on the Template Sharing dialog are missing labels. This can cause information to be missed by users who rely upon screen reader technology. This fails WCAG 3.3.2 Labels or Instructions (A).

The following two issues fail WCAG 4.1.2 Name, Role, Value (A):

  • Dynamic filter results are not announced to screen reader users.
  • Some calendar widgets are not using appropriate roles.

In most cases, the contrast ratio between text and its background colour meets the minimum contrast requirement with the following: These fail WCAG 1.4.3 Contrast (Minimum) (AA).

  • When configuring routing rules, the colour of the error message text (#D13239) does not meet contrast requirements against its background colour (#E9E9E9).
  • On the Prepare page in the Delay section, when the "Days", "Hours" or "Date" fields have errors, the red colour of the error message text (#D13239) does not meet contrast requirements against its background colour (#E9E9E9).
  • When adding a text field to a document, the colour of the placeholder text used for text fields (#857443 after .60 opacity applied) does not meet contrast requirements against the background colour (#FFD65B).

When content is scaled up to 200% the following areas have a loss of content or functionality. This fails WCAG 1.4.4 Resize text (AA).

  • The Recent Activity section of the Home page.
  • The Bulk Send table, the search functionality, the Inbox area, the Inbox navigation, and the Recipients section of the Manage page.
  • The Conditional Field Rule banner of the Add Fields page.
  • The Advanced Options dialog, the Select Template dialog, and the Recipients Access Code field of the Prepare page.

On the Add Fields page, the image that represents the Signature field on a document contains text. Also, the Docusign logo is the only other image that contains text. Since the text in the logo is part of a brand name, it's presentation is essential and considered an exception. This fails WCAG 1.4.5 Images of Text (AA).

When content is set to a width of 320 CSS pixels, the following areas have a loss of content or functionality, or require horizontal scrolling: These all fail WCAG 1.4.10 Reflow (AA).

  • On the Home page, the Recent Activity section experiences a loss of content. 
  • On the Manage page, The Bulk Send table, the search functionality, the Inbox area, the Inbox navigation, and the Recipients section experience both a loss of content and functionality. 
  • On the Prepare page, the Advanced Options dialog, the Select Template dialog, the Search Contact dialog, and the Recipient Access Code field experience both a loss of content and functionality. 
  • The Add Fields page experiences both a loss of content and functionality. 

1.4.11 Non-text Contrast (Level AA)
Most controls, control states, and graphical objects throughout the application meet the 3:1 contrast ratio requirement to be able to see these elements correctly, with the following exceptions:

  • On the Home page, when an envelope is expiring soon, the fill and grey track of the progress bar does not have sufficient contrast.
  • On the Manage page Inbox area, the grey track of the progress bar and the focus state of active elements in the Shared Access banner do not have sufficient contrast.
  • On the Add Fields page, the blue circular comment indicator that appears when a comment is placed on the document does not have sufficient contrast.

In the Sender Experience, the text spacing requirements can be applied without resulting in a loss of content or functionality with one exception: The below fails WCAG 1.4.12 Text Spacing (AA).

  • In the Properties Panel, the text "4000" in the "Character Limit"

Most content that is triggered on hover or on keyboard focus meets the dismissible, hoverable, and persistent requirements with the exceptions below. These fail WCAG 1.4.13 Content on Hover or Focus (AA).

  • On the Home page, the tooltip that appears when a pointer hovers over the “Signed by” control is not dismissible or persistent.
  • On the Add Fields page, the tooltips that appear when a pointer hovers over the field category buttons are not dismissible. 
  • On the Add Fields page, the tooltips that appear when a pointer hovers over the buttons in the toolbar are not dismissible or persistent. 

Most headings and labels are clear and descriptive with these exceptions below. These fail WCAG 2.4.6 Headings and Labels (AA):

  • On the Home page Create Signature dialog, the label for the “Clear” buttons is not sufficiently descriptive.
  • On the Home page Welcome banner, the label for the create signature button is not sufficiently descriptive.
  • On the Prepare page Search Contact dialog, the visually hidden labels for radio buttons in the table are not sufficiently descriptive.
  • On the Add Fields page Properties Panel:
    • The label for the “Set Up” button in the AutoPlace section is not sufficiently descriptive.
    • When creating a rule for a checkbox field, the accessible name for the select input field is not sufficiently descriptive.
    • When configuring checkbox fields, the label for the checkboxes that allow the sender to mark a checkbox field as checked for the recipient is not sufficiently descriptive.
    • When configuring radio button fields, the label for the radio buttons that allow the sender to mark a radio button field as selected for the recipient is not sufficiently descriptive. 
    • The label for the input field for the AutoPlace “placeholder” text is not sufficiently descriptive. 

Most interactive elements have a visible focus indicator when they receive keyboard focus with one exception. This fails WCAG 2.4.7 Focus Visible (AA).

  • On the Manage page, the "New Bulk Send" button does not have a visible focus indicator.

On the Add Fields page, the draggable controls for the Smart Sections cannot be operated with a single pointer without dragging movements. This fails wCAG 2.5.7 Dragging Movements (Level AA).

When the language of the menu item differs from the default language of the page, that language is not set via the "lang attribute" on the container of the menu item. This fails WCAG 3.1.2 Language of Parts (AA).

Meaningful icons, functional images, links, or buttons that are repeated across multiple pages are consistently identified with one exception. The badge indicator on the Help button indicates “new help messages" on the desktop version of the site, but in the mobile navigation, the same badge indicates "updated". This fails WCAG 3.2.4 Consistent Identification (AA).

Status messages are provided and are programmatically determined through their role or properties and are announced by assistive technologies without receiving focus with the following exceptions. They all fail WCAG 4.1.3 Status Messages (AA).

  • On the Home page Profile Photo dialog, when the user uploads an image, changes the shape of the profile picture, or rotates the image, a status message indicating success or failure is not provided.
  • On the Manage page: New Folder dialog, the error message that appears when the user leaves the "Folder name" field blank is not implemented as a status message.
  • On the Prepare page the following issues occur:
    • The error message that appears when the user leaves the "Custom number of days" field blank is not implemented as a status message.
    • In the Delay section, the error message that appears whmobile-friendlyuts “0” in the “Days” field is not implemented as a status message.
    • When using VoiceOver and Safari, the error message that appears when the user leaves the “Email Subject” field blank is not announced.
  • On the Add Fields page: 
    • When the user searches for fields in the "Search Fields" input, the search results are not implemented as a status message. 
    • When a user activates the Undo and Redo buttons, a status message indicating success or failure is not provided. 

Signing functionality

In the responsive view of the site, two informative images do not have any alternative text (e.g., “Open in a new tab”). This fails WCAG 1.1.1 Non-text Content (A).

The following points can cause users who rely upon screen readers to experience a confusing site journey, and therefore fail WCAG 1.3.1 Info and Relationships (A):

  • Field Groupings Indication: When they appear on the document being signed, visually grouped checkboxes are not grouped programmatically.
  • Content Structure: Most of the content is marked up in a way that conveys semantic meaning with two exceptions:
    • The controls in the toolbar are presented as an unordered list but are not marked up as such.
    • The pages in the Thumbnails panel are presented as an unordered list but are not marked up as such.
  • Semantic Markup Used for Headings: Most headings are implemented with semantic markup with two exceptions:
    • On the Thumbnail Panel, text appears as a visual heading but is not marked up as such.
    • On the Electronic Record and Signature Disclosure dialog, text appears as a visual heading but is not marked up as such.
  • Field Error/Description Association: Most field error messages and field descriptions are programmatically associated with input fields with one exception: 
    • On the Assign to Someone Else dialog, error messages are not programmatically associated with input fields. 
  • Page Structure: Some landmark regions are not defined: 
    • On the signing page, the header and main landmarks are not defined. 
    • On the Drawing dialog, the toolbar is not contained in a region. 
  • Table Description Association: On the History dialog, the Activity History table is introduced by a heading, but the heading is not programmatically associated with the table.

Most content is presented in the correct reading order with two exceptions as noted below. These fail WCAG 1.3.2 Meaningful sequence (A).

  • When the “I agree” checkbox is visible before signing, visually hidden content is announced by the screen reader in browse mode.
  • During signing, field validation occurs while typing. When an error is triggered, the error message is not announced to screen reader users. However, if the user navigates away from, then back to the field, the error message is announced.

Where colour is used to convey any meaning, that same meaning is conveyed with another visual cue with the two exceptions noted below. This fails 1.4.1 Use of Colour (A).

  • If the document being signed contains a drawing field, colour is used as the only visual cue to distinguish colours on the drawing toolbar.
  • During signing, when required fields do not have keyboard focus, the only visual cue indicating the field is required is a red border surrounding the field

The “Start” button that appears on the signing page is not keyboard accessible. This fails WCAG 2.1.1 Keyboard (A).

In most cases, field input errors are described in text with two exceptions. These fail WCAG 3.3.1 Error identification (A).

  • During signing, if the user selects the “Finish” button when a required field is left blank, an error message does not appear. However, the field with the error is indicated visually with a red, dotted border. In addition, a tooltip appears that indicates the field is required.
  • During signing, field validation occurs while typing. If the user continues typing, the error message is not announced to screen reader users.

Most input fields include instructions where needed with a few exceptions. The below points fail WCAG 3.3.2 Labels and instructions (A).

  • On the Adopt Your Signature/Initials modal dialog, although an alternative method to draw signatures/initials is provided, it is not described to users. In addition, the content and purpose of the <canvas> element used for drawing signatures/initials is not described to users.
  • On the Drawing dialog, the purpose of, and the alternate approach to, the drawing canvas and drawing toolbar is not described to users.
  • The “I agree” checkbox that appears before signing is missing visible instructions indicating the field is required.

In the responsive view opt-out modal dialog is missing dialog roles and attributes that allow screen reader users to understand the purpose of the content. This fails 4.1.2 Name, Role, Value (A).

When input fields in the Signing Experience ask for information about the user, the input purpose of these fields is not identified via the autocomplete attribute. Examples include Text input fields on the Adopt Your Signature/Initials dialog and Text input fields on the document being signed. This fails WCAG 1.3.5 Identify input purpose (AA).

In most cases, the contrast ratio between text and its background colour meets minimum contrast standards, but in the Thumbnail Panel, when the thumbnail page is not focused, the colour of the page number text (#FFFFFF) does not meet contrast requirements against its background colour (#A9A9A9). This fails WCAG 1.4.3 Contrast (Minimum) (AA).

Whilst most of the text in the Signing Experience can be scaled up to 200% magnification without loss of content and functionality the following item have issues at that level and beyond. They both fail WCAG 1.4.4 Resize of text (AA).

  • The Thumbnail Panel content is removed from the view.
  • The Signing toolbar controls (Zoom In, Zoom Out, Download, Print, and Help) are removed from the view.

Whilst the majority of the web application can be resized to a width of 320 CSS pixels / a height of 256 CSS pixels without loss of content or functionality, and without requiring scrolling in two dimensions, there are exceptions. These include the Phone and SMS authentication pages. This fails WCAG 1.4.10 Reflow (AA).

While the majority of additional content that appears on hover or focus is dismissible, hoverable and persistent, tooltips that appear on hover and focus in the comments section and in the signed document page are persistent. However, it is not possible to hover over the tooltip itself using the mouse. This fails WCAG 1.4.13 Content on Hover or Focus (AA).

Most headings and labels are clear and descriptive with the exception of the Adopt Your Signature dialog, the signature styles lack any visual description which may make it difficult to differentiate various styles. This fails WCAG 2.4.6 Headings and Labels (AA).

Error suggestions are provided for most fields that require them, but on the Assign to Someone Else dialog, when entering an invalid format in the "Email" field, an error message is displayed, but an error suggestion indicating the correct format is not provided. This fails WCAG 3.3.3 Error suggestion (AA).

If you find an issue that we have yet to identify, please contact us using one of the routes described in the ‘Reporting accessibility problems with this website’ section of this statement.

Disproportionate burden

At this time, we have not made any disproportionate burden claims.

Content that’s not within the scope of the accessibility regulations

This section covers issues that we do not need to fix right now. The law calls these exemptions.

Third-party content

Our websites contain third-party content. We do not have control over and are not responsible for the accessibility of this content, but we make best endeavours to work with the third-party to improve its accessibility. This may include:

  • links to non-UCL websites
  • content/functionality on our website
  • content hosted on other websites, such as social media sites.

To help accessibility compliance across the sector, University College London supports searchBOX, a centralised, independent directory of third-party accessibility information. 

searchBOX catalogues the contact information and accessibility statements of third-party suppliers, enables the sharing of community-generated accessibility statements, and allows users to map their supplier ecosystem. 

Users can access third-party accessibility statements using the free searchBOX Finder service. 

University College London encourages all our partners and suppliers to support this effort by ensuring that their accessibility information is included in the searchBOX directory. 

Our testing processes

We tested the application using a combination of manual and automated checks alongside reference to the existing conformance reports provided by DocuSign. If you find an issue we have not yet identified, you can report it to us. We’ll pass this information to the website owner who will review the issue, make sure it is included in our plan to fix issues and add it into the accessibility statement when it is next updated.

Preparation of this accessibility statement

This statement was prepared on 14 February 2023. It was last reviewed on 20 November 2024. This application was last tested in 15 May 2024. The test was carried out by DocuSign, with additional testing completed by UCL.

This statement was written using DocuSign’s own VPATs, which can be found at the following link: DocuSign Blog on making DocuSign Accessible.

DocuSign eSignature Sending Voluntary Product Accessibility Template (VPAT): DocuSign Sending VPAT.

DocuSign eSignature Signing Voluntary Product Accessibility Template (VPAT): DocuSign Signing VPAT.

What we’re doing to improve accessibility

UCL is working with DocuSign to address any issues found.