Accessibility transaction

Hi Cindy,

Before you start to design the transaction, you need to prepare a tagged PDF and use position extraction to match Adobe Fields with OneSpan Sign fields, it's a mandatory way to add fields.

Unlike to design a non-ada PDF, you need to use specific Adobe Fields to match with particular fields - Adobe Signature represents signature field, Adobe Text Box represents input field, and Adobe Radio Button represents radio field.

Here's a guide for creating an ADA PDF.

I also have a blog introducing how to use sender UI to design an ADA package. (I've attached the PDF I used in the blog)

Duo

Duo,

for the sample ADA form you attached, for the signature form field, if I want to use API call to create ADA transaction, what signer information should I put? how does OneSpan know this is signature field or something else? 

thanks,

Cindy

Hi Cindy,

As below screenshot resembles,

(1)approval ID, approval Name, signature field ID, signature field Name better to be the same as the property name of Adobe Signature ("SIGNATURE1" in my example)

(2)for other fields, field ID and Name need to be the same as the corresponding property name of the Adobe Fields ("DATE1" and "NAME1")

I've also attached the completed JSON to create an ADA package with my sample PDF.

Duo

Duo,

do you have the sample tagged PDF used in this post? the reason is I want to get some tagged text as well. 

https://community.onespan.com/documentation/onespan-sign/guides/admin-guides/user/creating-accessible-pdf

thanks,

Cindy 

Hi Duo,

I saw your blog (https://www.onespan.com/blog/onespan-sign-release-1124-upload-accessible-document-sender-ui) and it says 11.24, does it mean our on-prem v11.25 already have the same feature as well? and only available in new sender UI not classic one?

thanks,

Cindy

Hi Duo,

Hope you are doing well! 

I still have question about the accessibility testing. I created non-accessibility transaction (ada=false) with the attached form. when I go through the signing process with screen reader, it seems everything can be read such as menu, button, document self and signature field etc without turn on "enable accessibility". 

I tested the following scenario:

1) ADA = false, non-tag form (attachment): without "enable accessibility", everything can be read include menu, document self and signature field etc

2) ADA = true, non-tag form (attachment): without "enable accessibility", everything can be read include menu, document self and signature field etc

3) ADA = true, non-tag form (attachment): with "enable accessibility", everything can be read include menu, document self except signature field as it re-format the way as screen reader can read

4) ADA = true, tagged form (the one you used in the blog): with "enable accessibility", everything can be read include menu, document self and signature field etc

To me, it seems scenario #1/#2 and #4 are same, why we need to use tagged form for accessibility ?

thanks,

Cindy

Hi Cindy,

I am doing well, thanks for asking!

It's documented in the "Creating an Accessible PDF" guide that:
The concept of a "tagged PDF" is central to OneSpan Sign's accessibility solution, since only tagged PDF elements are included in its WCAG HTML representation. Thus all elements intended for accessible content and signing must be tagged (including Signature Fields and those "automatic fields" whose content is triggered by signing).

Duo

Hi Duo,

from my scenario(non-tagged PDF with non-ADA transaction), the screen reader still can read for signing ceremony process such as buttons, document, and signature field inside of the document etc. then what's the difference between non-tagged PDF with non-ADA transaction vs tagged PDF with ADA transaction. 

As I tested, from sender UI,  you have to have tagged form to create ADA transaction. 

thanks,

Cindy

Hi Cindy,

Although I am not an expert in ADA area, but from the best of my understanding, even though some modern PDF viewers are able to recognize the text in a PDF, still it splits the word wrongly sometimes (see below screenshot), versus the ADA transaction where the PDF reader reads the text directly from the tags 

Duo

thanks Duo for the information. 

Hi Duo,

from the above posting, you sent me the sample for create ADA transaction via API, does SDK support the same thing? if so, could you please share some sample code? 

also for non-ADA PDF, in the JSON payload, we put "approvals" field as empty so OSS will extract the document, so in the case of ADA PDF, OSS is not able to extract by its own and requires the requestor to put the information in the "Approvals" field in the payload, correct?

Thanks,

Cindy

Hi Cindy,

Yes, OSS Java/.NET SDK also supports to create an ADA transaction, I've attached an example tagged PDF as well as the code.

If by "for non-ADA PDF, we put "approvals" field as empty", you meant an accept-only document, it's also possible to create such an ADA document, in the code, if you replace the .withSignature() function with the commented out code, you will see the changes:
//                        .withSignature(SignatureBuilder.acceptanceFor("[email protected]"))
 

Duo

Hi Duo,

thanks for the code and sample form. what my question is for non-ADA form, the form is using document extraction so when we send payload to OSS, the approvals field are empty as OSS can extract the form by itself. but for ADA form, it's only using position extraction so when we send the create package payload to OSS, we must identify the approvals with fields id associated with signer id, am I correct? 

if so, OSS only support ADA form which using position extraction, no other extraction such as document or text tag extraction, right?

thanks,

Cindy

Hi Cindy,

I see. Yes, for an ADA transaction, the only supported extraction method is position extraction, so you need to know the number of fields, their types, and the assigned signer.

Duo

got it. thanks.

Hi Duo,

one more question regarding ADA transaction, I use the same document to create the package, in the signing ceremony, with ADA on or off, the screen layout is different. do you know why? please see the attachment for the difference. 

Hi Cindy,

It's expected that the document layout in ADA mode is different from the regular signing ceremony since the ADA mode is designed for the visually impaired recipients. As per the "Creating an Accessible PDF" guide, only tagged PDF elements are included in its WCAG HTML representation, thus all elements intended for accessible content and signing must be tagged.

Duo

I see, I looked the sample I used for the attached screenshot, i.e signature box is properly tag, but just not showed in the original spot. anyway, thanks for help.

Cindy

Hi Duo,

another question, does OneSpan support text tag form for ADA transaction? if so, could you provide me the sample payload to create the package?

thanks,

Cindy

Hi Cindy,

Unfortunately no, in OSS, position extraction is the only method to place signatures and fields on an ADA document.

Duo

thanks Duo for quick response, so position extraction is similar with document extraction? the only difference is for position extraction, need to specify the field name in the "approve" element in the payload, while for document extraction, OneSpan can ready by its own? 

thanks,

Cindy

Hi Cindy,

Both document extraction and position extraction use PDF form field to locate the fields. However, position extraction only provides the location and the size of the field, your application still needs to know the exact number of fields, their field name and type. 

Duo

got it, thanks