Administrative Assistant/Cons

DocuSign Accessibility Statement *

Links:

DocuSign Voluntary Product Accessibility Template (VPAT) for eSignature Signing DocuSign Voluntary Product Accessibility Template (VPAT) for eSignature Sending DocuSign Accessibility Statement

The purpose of this document is to provide visibility on the current state of DocuSign’s allegiance with, and adherence to, government and international requirements for product users of all abilities ( U.S. Government's Section 508 and WCAG 2.1 Level AA standards and guidelines).

DocuSign Accessibility Statement 1

Summary of Current Accessibility Compliance 2

Conformance status 2

Feedback 2

Measures to support accessibility 3

Compatibility with browsers and assistive technology 3 Assessment approach 3

Signing 4

Signing with Optimal Accessibility 4

Using Screen Reader Mode 4

Using Mobile-Friendly (Responsive) Mode 4

Accessibility Expectations for Signing 5

Accessibility of Signed Document PDFs 6

Limitations and alternatives 7

Sending 9

Sending for Optimal Accessibility During Signing 9 Branding/Color Customization 9

Microsoft Word Documents 9

PDF/UA Documents and Document Preparation 10

Configuring PDF fields for DocuSign Tag Conversion 11 Optimizing Signature Options for Mobile Devices and Assistive Technology 12 Downloading Sent Document PDFs 13

Limitations and alternatives 14

Appendix: DocuSign Document Fields 17

DocuSign Accessibility Statement 2

Summary of Current Accessibility Compliance

Accessibility is part of our core mission. Our mission is to simplify and accelerate the way organizations and individuals come to agreement. We are committed to building trust and making the world more agree-able for our employees, customers and the communities in which we live and work. We understand that our products enable people with disabilities to do things in a manner that can make an incredible difference in their lives at very critical moments such as securing a new job or buying a home. Our team is dedicated to adhering to WCAG 2.1 AA guidelines from project conception to final product. We are working to make sure that anyone, regardless of disability or assistive technology, can use DocuSign and have a world-class experience.

DocuSign’s eSignature Signing Experience conforms to and continually tests for Government Section 508 and WCAG 2.1 Level AA compliance. These products are accessible to our clients’ customers by supporting:

● Common screen readers (See the supported screen readers for each browser on the Compatibility with browsers and assistive technology section below)

● High-contrast settings for low vision users

● Keyboard-only input

Return to top

Conformance status

The Web Content Accessibility Guidelines (WCAG) defines requirements for designers and developers to improve accessibility for people with disabilities. It defines three levels of conformance: Level A, Level AA, and Level AAA. DocuSign eSignature Signing is partially conformant with WCAG 2.1 level AA. The DocuSign eSignature Sending is partially conformant with WCAG 2.0 level AA. Partially conformant means that some parts of the content do not fully conform to the accessibility standards. DocuSign has taken steps to ensure that the areas that do not conform to WCAG standards are minor, and there is no hindrance to users with disabilities from completing all major tasks. The DocuSign eSignature Signing VPAT is posted online for review, as is the DocuSign eSignature Sending VPAT. Return to top

Feedback

We welcome your feedback on the accessibility of DocuSign eSignature and the DocuSign eSignature Sending Experience. Please let us know if you would like to discuss accessibility issues, or if you have questions or comments:

DocuSign Accessibility Statement 3

● E-mail: *************@********.***

We try to respond to feedback within 5 business days. Return to top

Measures to support accessibility

DocuSign takes the following measures to ensure accessibility of DocuSign eSignature:

● Include accessibility throughout our internal policies.

● Provide continual accessibility training for our staff.

● Assign clear accessibility targets and responsibilities.

● Employ accessibility quality assurance methods.

● Periodic retesting of DocuSign products and digital properties.

● Appoint accessibility champions throughout the organization.

● Implement an accessibility plan for long-term continuance. Return to top

Compatibility with browsers and assistive technology While DocuSign eSignature Signing and DocuSign eSignature Sending Experience are designed to work with most popular screen readers and browsers with minor differences, we recommend using the following assistive technologies for an optimal experience:

● NVDA and Chrome

● NVDA and FireFox

● VoiceOver (Apple’s native screen reader) and Mac Safari Return to top

Assessment approach

DocuSign assessed the accessibility of DocuSign eSignature by the following approach:

● External evaluation by The Paciello Group (TPGi) Return to top

DocuSign Accessibility Statement 4

Signing

Signing with Optimal Accessibility

DocuSign leverages different assistive technologies to ensure that all users are able to sign our documents. We support the use of screen readers, that allows visually impaired users to follow the necessary guidelines to sign an envelope; keyboard-only usage to ensure that any action can be executed using only this device; and the enablement of high contrast mode in all Operating Systems which allows colorblind users to have a better experience while signing a document.

Using Screen Reader Mode

Signers using screen readers must enable the Screen Reader mode for a document to be read to them. When enabled, this feature translates the document to be signed into a consumable format for screen reader technology. To enable screen reader mode, the user must navigate in the signing session with the Tab key to the “Press enter or use the screen reader to access your document” link. Clicking this link will enable the Screen Reader to start reading the document: Notice the link on the top left section of the screen. This is the hidden link that will allow the screen reader to read the document. The user will then be able to hear the screen reader read the entire document along with the DocuSign Fields or they will be able to navigate through the content using the screen reader. Using Mobile-Friendly (Responsive) Mode

The Mobile-Friendly (Responsive) Signing mode has not yet been assessed for accessibility by our third-party vendor, and therefore cannot be considered WCAG 2.1 compliant. DocuSign will include Responsive Signing as part of our next accessibility assessment and will be included in DocuSign Accessibility Statement 5

our 2022 VPAT. Customers should test and verify the Responsive DocuSign eSignature for their documents for accessibility.

If enabled on a given envelope, DocuSign Responsive Signing will convert your documents to HTML form for better rendering on mobile devices on your behalf. As a recipient, they are presented with a toggle to switch between the Responsive Signing HTML and normal rendering of the documents.

If you are using DocuSign to convert your documents for Responsive Signing, the generated output HTML is provided as-is, and assistive technologies, such as screen readers, will interpret the document HTML presented to the browser.

If you would like to control the HTML generated for document rendering and assistive technologies, you can use the DocuSign API to provide the HTML representations of the document. To learn more about this, check out the How to Create a Signable HTML Document. Additional resources on sending Responsive Signing envelope or disabling the feature are available on our support page.

Notice the switch at the top left side of the screen. Screen reader users can navigate into the document immediately. Accessibility Expectations for Signing

Web Content Accessibility Guidelines (WCAG) 2.1 covers a wide range of recommendations for making Web content more accessible. Following these guidelines will make content accessible to a wider range of people with disabilities, including blindness/low vision, color blindness, and limited movement.

1. As a low vision/blind user, I would expect DocuSign eSignature to: a) enter screen reader mode

b) rely on keyboard access

c) have form Fields that provide explicit labels and titles DocuSign Accessibility Statement 6

d) have other structural markup such as list and heading elements to be read correctly

e) inform of missing or erroneous input Field content and focus to be shifted to the first erroneous Field upon selecting the Finish button f) support the browser zoom function or screen magnification software (expected by low vision users)

2. As a color blind user, I would expect DocuSign eSignature to: a) honor high contrast mode setting of the Operating System with the exception of white on a black background

b) not override user selected contrast and color selections c) not use color alone to convey information or indicate an action d) not permit a user to adjust color or contrast settings. If Senders can leverage Branding controls to manage color, then the selected colors should have a contrast ratio of at least 4.5:1.

3. As a limited mobility user, I would expect DocuSign eSignature to: a) provide full keyboard support by avoiding the use of device dependent event handlers

b) not require the user to have fine motor control in order to operate any features c) allow all functions to be executed on a keyboard d) get equivalent signing options such as uploading a signature or selecting styles of signatures/initials available by default

Return to top

Accessibility of Signed Document PDFs

DocuSign provides all customers the ability to download an accessible tagged PDF version of the signed envelope. Once you are done signing, you can open the completed document by activating the View Document link in the confirmation email you will receive after signing. Then navigate to the download menu and choose the “Separate PDFs” option. Open the downloaded PDF in Adobe Reader while using the NVDA screen reader. We do not advise attempting to read the PDF in the browser’s PDF view since different browsers have different behaviors when reading PDFs.

DocuSign Accessibility Statement 7

Open the Download menu and select Separate PDFs option. Return to top

Limitations and alternatives

Despite our best efforts to ensure accessibility of DocuSign eSignature, there may be some limitations. Below is a description of known limitations noted on the VPAT, and potential solutions. Please contact us if you observe an issue not listed below. Known limitations/workarounds for DocuSign eSignature: 1. In responsive view of the site, two informative images do not have alternative text

(e.g., “Open in a new tab”). When the page is zoomed and the Actions menu moves to the left side of the screen, there are two links in the menu that have an icon next to them. The icons indicate these links will open in a new window. The icon is not announced but the name of the links (“Download Separate PDFs”, “Download Combined PDF”) make it clear that a new window/application will open when the user activates them. This issue has been addressed and fixed.

2. On two pages, one heading element has been left empty without content (the SMS and Phone Authentication pages). To ensure the security of these pages, they are generated in a manner that sometimes results in an empty heading element. Since the other headings have the proper information and heading level, this is a minor issue and will not impact users who rely on assistive technology. 3. In the comments functionality, a visible list of items is not identified as a list within the underlying code. If users have comments enabled, when they are reviewed they are not implemented in a list structure. However, when comments are added, this list structure is there. DocuSign is currently in the process of addressing this issue. 4. When the mobile-friendly toggle button is activated, the focus is not managed and is placed before the button itself. Therefore adding an additional repeated tab stop for keyboard users to navigate. The guideline prefers that focus return to the exact sport that activated a dialog once it is closed. Instead focus is moved to a spot adjacent to the activation point to allow hidden text to be announced properly. Only for customers who are using responsive Signing feature, the way the toggle button is implemented requires focus to move to this location to ensure focus is not lost on the page. This DocuSign Accessibility Statement 8

should have no impact on keyboard-only users except they may need to hit the Tab key one more time.

5. On the SMS Authentication page there are elements nested in others in a way that is not permitted by the specification. This issue has been addressed and fixed. 6. 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. Users who are using the responsive feature have the option to turn off responsive signing. A callout appears that provides them more information. Since it is a callout, there are no dialog roles associated with this component. This does not have any effect on screen reader users’ ability to perceive and understand the purpose of the callout. The callout functions as expected for all types of users.

7. While 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. The Phone and SMS authentication pages are in the process of being rebuilt so they can accommodate the smaller sizes required by WCAG 2.1.

8. 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 issue has been addressed and fixed.

Return to top

DocuSign Accessibility Statement 9

Sending

DocuSign has tested the sending experience to ensure it meets WCAG 2.0 AA compliance. Accessibility has been assessed when a user clicks on the link that they receive in email, while they perform the signing process, and after they have completed the signing process. The sections below describe how accessibility is achieved, and how signers get the most accessible experience possible in DocuSign.

Sending for Optimal Accessibility During Signing

Key Point: It is the responsibility of the document creator to make sure the document is compliant before uploading it into the DocuSign platform. DocuSign’s ability to provide a screen reader friendly, accessible document is dependent on the sender providing an accessible document for the signing process. It is the responsibility of the document creator to make sure it is compliant. If the document was perceivable prior to being uploaded to DocuSign, then it will be readable by signers after the DocuSign fields are applied to the document. The completed document will also be as compliant as the source document. Branding/Color Customization

Some customers may choose to use the branding options that allow you to change certain colors of text and backgrounds in DocuSign. Please ensure that these color changes provide enough contrast as required by WCAG 2.1 AA guidelines for focus outlines, links, text, and all relevant content. It is the customer’s responsibility to make these color changes compliant since it is out of our control if customer make these changes, and customers can change them to compliant colors at any time.

Return to top

Microsoft Word Documents

Creating a document using Microsoft Word is one of the best ways to create a document when using DocuSign. Microsoft Word allows you to create content using tools that optimize documents in a way that is easily understood by assistive technology such as screen readers. It also has a built-in Accessibility Checker that verifies documents are compliant and suggests solutions in the areas that it is not.

After you complete a document, you can run the Accessibility Checker by selecting the Review tab and then clicking on the ‘Check Accessibility’ button. DocuSign recommends using the latest version of Word. If you are using an earlier version, you can use the ‘Check for Issues’ DocuSign Accessibility Statement 10

button followed by the ‘Check for Accessibility’ link. Word checks for issues it finds and provide suggestions on how to fix them. When the results appear, you can click on the items in the results tree. More information will display to allow you to understand why the issue was flagged and how to fix it. Not all of the suggestions are necessary. For example, not all tables require table headers so you can skip unnecessary suggestions if they do not apply to your document.

It is important to use Word properly to structure your documents when you create them. For example, use headings styles when creating headings and use list styles when creating lists. This allows assistive technology to understand the structure of the document. If you create documents with headings that appear as headings but are not using Word heading styles, the structure of the document may not be communicated properly to users who rely on assistive technology.

There are some structures in Word that do not translate well to assistive technology when importing them into DocuSign. These structures also have issues when read by assistive technology in Word documents. For example, a text box may not appear in the proper order when imported into DocuSign since it can be nested inside of text. The automated import process has to make a best guess as to when it should be read, either before or after the surrounding text. If this occurs after importing the document, use DocuSign fields to make sure the text/content is announced in the proper location, such as the Text field. Return to top

PDF/UA Documents and Document Preparation

PDF/UA documents must meet the ISO standard for universal accessibility when uploaded by the sender. PDF documents need to be tagged and properly tested under WCAG 2.0 AA guidelines to meet these requirements. There are numerous software applications that allow senders to ensure that the PDF they upload is properly set as accessible (PDF/UA). It is recommended to use more than one of the following software applications to verify the accessibility compliance of the document.

● Microsoft Word. A Word document should be saved in Office 2010 (or higher) as a PDF then select the radio button "Best for electronic distribution and accessibility (uses Microsoft online service)." This ensures the PDF is PDF/UA tagged.

● Adobe Acrobat Pro helps to check PDF accessibility and that the tags are added to the PDF. If the PDF is not tagged, this software offers an ‘Autotag document’ feature that selects tags for the user. Acrobat Pro also has an Accessibility Checker tool that will help to ensure the document is accessible. The user should not use the Reading Order feature that this software offers as it is only useful for internal reading with the native Acrobat reader. Note: checking PDF accessibility with Acrobat does not mean the document is PDF/UA compliant.

DocuSign Accessibility Statement 11

● CommonLook has developed a plug-in for Adobe Acrobat that allows its users to edit the PDF tags in the tree structure better than with Adobe Acrobat alone. This provides a clearer view of the reading order. The same company provides a service to make PDFs accessible.

● Axes4 is another company that provides the service to make individual PDFs documents accessible.

Senders do not need to do any additional steps after an accessible document is uploaded to DocuSign, but they should ensure all DocuSign fields have tooltips/labels for screen readers to understand their purpose. However, including a Note field or a tooltip to the DocuSign fields can help signers understand the document they are signing.

● Note field: Instructions on filling in forms are available to screen reader users through the use of the Note field.

● Customizable tooltips: Should be used by senders for form field labeling and identification.

These are not required to make a document accessible but will help the user to navigate the document effectively.

It is also recommended that the sender test how the document reads with a screen reader by using the Recipient Preview feature. This should be done after adding the DocuSign fields to the document. It verifies that they are properly placed as well as showing how they are read using assistive technology.

Configuring PDF fields for DocuSign Tag Conversion If you create your PDF with form fields, you can set it up in a way that allows DocuSign to import the form fields with the proper accessibility information. DocuSign looks at the PDF form field DocuSign Accessibility Statement 12

name to determine what type of DocuSign field to place in the envelope that will be signed. The name of the PDF form field should conform to the naming convention we have created so our system understands what type of field it is. Then, when tagging the document, if you choose to use the Assign To or Keep Data option when importing, then DocuSign will convert these PDF form fields to DocuSign fields.

To give the proper field names to these fields to ensure they are converted to the correct DocuSign field, follow the naming conventions located here: PDF Form Field Transformation Table.

For more information on Sending PDFs with existing form fields, please visit here: Send a PDF with Form Fields.

Note: It is important to mention that the field name is not announced by screen readers, rather the field tooltip is the PDF form field property that will be announced by screen readers. Tooltip properties can be changed or edited when you are tagging the document fields in DocuSign. All tooltips in a document should be unique, as all form fields should have unique names in a form. Return to top

Optimizing Signature Options for Mobile Devices and Assistive Technology To make sure that users who rely on a screen reader can easily sign documents, customers should configure the account in two steps. First, make sure to have at least one signature adoption method as an alternative to drawing a signature. Second, avoid setting the drawing option as the default option for creating signatures. Select the Start on Adopt option for both Mobile Signature Adoption Mode and Signature Adoption Mode. DocuSign Accessibility Statement 13

Screen reader users need to swipe to navigate on the page, so drawing will not allow them to navigate properly. DocuSign ensures screen reader users can sign by allowing them to select a signature from pre-made sets of signatures, use a previously used signature, or upload a signature image of their own. To allow other options besides the drawing option, follow the instructions here: Signature Adoption Configuration. Return to top

Downloading Sent Document PDFs

DocuSign provides all customers the ability to download an accessible tagged PDF version of the signed envelope. Once you are done signing, go to the Manage page and locate the envelope. Click on the envelope name in the list. On the Envelope Details page, navigate to the download icon and the first three boxes should be checked and the Combined documents checkbox should be unchecked. Activate the Download button and open the document file in Adobe Reader. We recommend using NVDA screen reader for an optimal experience. We do not advise attempting to read the PDF in the browser’s PDF view since different browsers have different behaviors when reading PDFs.

DocuSign Accessibility Statement 14

Return to top

Limitations and alternatives

Despite our best efforts to ensure accessibility of the DocuSign sending experience, there may be some limitations. Below is a description of known limitations noted on the VPAT, and potential solutions. Please contact us if you observe an issue not listed below. Known limitations for DocuSign sending experience: 1. Font icons (such as the status icons in the Manage Inbox) lack proper alternative text: This issue has been addressed and fixed.

2. Some decorative font icons (such as the key icon in the Document details page) are not hidden from assistive technologies: On most of the decorative icons that appear throughout the product, DocuSign hides the font icon so screen readers do not attempt to guess what to say when they encounter a symbol. During testing it was discovered that only VoiceOver registers these types of icons. Also, VoiceOver does not actually announce these icons; it presents them in the VoiceOver display as a question mark so it is not announced at all to screen reader users. This is a minor issue since the font icon, being decorative, is not necessary to understand the content of the page. 3. The heading structure is not logical on some pages: Some headings were marked out of order, for example, a level 5 heading followed a level 3 heading. This issue has been addressed and fixed.

4. Some text is incorrectly marked up as a structural heading: Some instances of text used heading HTML instead of normal text HTML. This issue has been addressed and fixed.

5. One of the date fields does not correctly expose errors to assistive technologies: The date field in the filter menu on the Manage page was not announcing the ‘Invalid DocuSign Accessibility Statement 15

date’ error tied to the date field when the error would appear visually. This issue has been addressed and fixed.

6. The calendar widget on the Manage section is not keyboard operable. However, alternatively, the date can be directly entered into the date field: When users encounter the date field on the Manage page, they can either enter a date with the keyboard, or select a date from the calendar widget that appears. DocuSign has provided an accessible means for screen reader users and keyboard-only users to enter this date via the keyboard, so there is nothing blocking users from entering the date and completing the form. However, the optional use of the calendar is not optimized for users who rely on the keyboard.

7. The checkboxes on the Template Sharing dialog are missing labels: A number of checkboxes appear in this dialog that allow users to select multiple items. This issue has been addressed and fixed.

8. Dynamic filter results are not announced to screen reader users: In some input fields, such as search fields, as the user types, suggestions appear. These suggestions are not announced by the screen reader as the user types. The can, however, navigate into the suggestion list and select a suggestion, so the suggestions are still available to the all users.

9. Some calendar widgets are not using appropriate roles: The calendar should have ARIA roles of “grid” and “gridcell” in order for assistive technology to interact with the widget properly. To bypass this issue, all users have the ability to enter the date directly in the date fields without interacting with the calendar widget. Return to top

The DocuSign eSignature Sending experience has had an extensive independent assessment from The Paciello Group and is now WCAG 2.0 AA compliant. The Scope of the DocuSign eSignature Sending experience is the following: 1. Send from template. A user with disabilities will be able to do the following: a. Navigate with a keyboard to the NEW button in the Home/Manage Page b. Open the options, which will be read by the screen reader and select the one to

‘Use a Template’.

c. The template modal or the advanced edit page (depending on the level of detail the template creator provided) will open and the user will be able to navigate all the sections using the tab button or any shortcuts allowed by the screen reader to complete the relevant information. All headers should be properly placed for easy navigation.

d. The user will be able to use the Preview feature to listen to how the document is read by the screen reader in the same way that the envelope signer will before they send out the template.

DocuSign Accessibility Statement 16

2. Manage envelopes/templates. A user with disabilities will be able to do the following: a. Navigate with a keyboard to the header to reach the Manage/Template section. b. Once in either section, the user will be able to go through all the filters and/or folders to find the desired envelope/template.

c. Read both pages with a right and left panels now ARIA regions which are labeled for easy navigation.

d. The users will be able to jump from the folder/filter left panel to the envelope/template table section to perform any desired action. 3. Send new envelope / Template Creation. A user with disabilities will be able to do the following:

a. For the template or envelope creation, the user will be able to navigate using a keyboard to the NEW button to select “Send an envelope” or “Create a template”. b. Once in the prepare page, the user will need to import a PDF that already has form fields included in it (the Add Fields page has Keyboard accessibility with helpful shortcuts, but does not support ad hoc tagging). c. Once the user reaches the Add Fields page, they will be able to import the Form Fields from the document and automatically transform them into DocuSign Fields.

d. DocuSign doesn’t read the uploaded document in the Add Fields page, but it does read it in the Preview, so the user will be able to read the entire document with the imported form Fields as the signer while using DocuSign eSignature. 4. Reports: DocuSign has made

Contact this candidate