PDF -- Review of PDF and InDesign files

[damiansian]

Notes on Direct File Interactive PDF Remediation Efforts

I can relay that for those not familiar with Adobe InDesign form creation that you have put in a great deal of work on this. In the space of PDF Accessibility, forms are the highest order of complexity. The solutions you’re authoring would be leagues above what most non-sighted users are accustomed to getting in interactive forms. PDFs already have a bad reputation in the non-sighted community. Interactive PDFs are normally just a lost cause (i.e., the worst of the worst). If you were to continue the work that you are currently doing, you’re close to a functional path for non-sighted users allowing them to achieve all the tasks a sighted user can.

If we’re looking to achieve full WCAG conformance, I have some options below to review with you that may bridge that gap. In my experience in making accessible forms at Prudential and Princeton, I have run into each and every unique challenge present in these Taxation documents. I have included my suggestions on how to tackle those challenges for your review and would love a chance to chat with you about making excessively accessible interactive PDFs for the state of New Jersey that put all other states interactive PDFs in this space to shame 😊

Comb formatting (WCAG 4.1.2)

First, I’ll introduce the concept of comb formatting to anyone reading this who may be today years old when they heard that term 😊 Comb formatting forces form field entry into boxes essentially. If you look at a form I worked on in my days at Prudential, the visual affordance is a little more explicit.

You can kind of see it looks like a comb with the little prong things facing up.
I see that you’re creating single text fields for things like Social Security fields and for dollar amounts up to tens of million. Kudos to you for that approach, it’s not something I would have thought to try. There are some challenges that I have observed that I’d like to share.

SSN

The comb values don’t line up to the existing red boxes. If someone prints this out, they’ll have overlapping which could be confusing. And as a solution for the Taxation team, I think this may be a bit of a blocker for adoption of using this approach which I think we can aim for if we give them something that is pixel-perfect and more efficient than their current approaches.

You can see here that the comb format for 10 characters doesn’t exactly line up.

Dollars

This works visually (which is awesome by the way), but for a screen reader user, they won’t hear the decimal values. For this reason, I think there is value to expressing the form inputs to a screen reader user as:

1. Millions (2 digits)
2. Hundred thousand (3 digits)
3. Thousands (3 digits)
4. Cents (2 digits)

Here is how I have approached the same challenge. Please note, I’m not saying my way is the only way, but I wanted to share with you my approach as may find a happy middle ground 😊.

Note

Feedback from a ND NJ resident, the name field is super confusing to me.

I created text fields for each block of form inputs and gave an accessible name (screen reader access) that describes how to fill that out. I use comb formatting to separate each text input into the appropriate number of boxes, so it matches the visual formatting precisely. I also used “X” for the fill-in on the checkboxes as that is what the current Taxation form is using.

Again, happy to chat and bounce ideas off one another to find the best approach.

Accessible names (SC 4.1.2)

First, an accessible name is what gets read to a screen reader user. Each form element has an accessible name that should describe how to fill in the form.
Your naming is spot on for the approach you went with for the most part. If you’re doing comb formatting, you must include the number of digits in the naming, so the user has an idea of the input characteristics.

Naming comb formatting example:

Tab order (WCAG SC 1.3.2)

The current tab order in a PDF exported from your InDesign file would read for a screen reader as:

1. Tab stop 1: Your social security number
2. Tab stop 2: Last name, First name, Initial

The correct tab order, in my opinion, would be the left column of form elements, and then the name/address section.

The bottom “fill-in” content (tab stops 9 – 12) read great though.

Possible solutions:

1. Adjust the form elements in Articles pane of InDesign to control the tab/tags ordering (recommended).
2. Adjust the order directly in Acrobat by going to Prepare form > Fields > and then manually controlling the tab position of each form field (not recommended).

Reading order (SC 1.3.2)

The manner in which the Taxation team created their InDesign file is prohibitive to creating a proper reading order. They used large blocks of paragraph text so we would have to use one of the two methods below:

1. Drop the form fields as anchored objects into those paragraphs similarly to how they added the red comb boxes.
2. Break up the text into separate text frames.

This is toilsome, not going to lie but… it leads to better accessibility outcomes.

Here is what that looks like:

Note

I use an object style on form elements to color them in while authoring and then just set to no fill when exporting. That’s why they’re yellow in the screen shot.

Notice each element has its own entry in the layers panel. And the switch that needs to be flipped in one’s mind is that each of those layer objects creates a tag in the PDF. If you can envision that in your mind, what you’ll see in my tag panel will make more sense:

The tags tree creates the reading order for the screen reader. They need to be able to hear the associated label in relation to the form input. There are times where the full context of a form element can only be created from reading the related text content. This may seem counterintuitive as you’re already providing an accessible name for the form input. There are times when the adjacent text is just too large to add as a label to a form element for one. And two, the relationships that can be seem, need to be communicated to someone listening to the document for full WCAG conformance.

[damiansian]

@amanifarooque / @tristanvanech / @mmazanec22 /

I didn't find Crystal's name in the "@" dropdown. My notes on the InDesign and PDF approaches are shown above. I think we should meet to review but I'm open to your thoughts and guidance.

[amanifarooque]

@damiansian Thank you so much for the really thorough review! I've set some time for 12PM ET on Monday -- let me know if that time works on your end!

[damiansian]

It's coming along...

[damiansian]

@tristanvanech and @mmazanec22

You mentioned other pages that are involved. Can you send me unlocked PDF files for those? Also, are they owned by the Treasury/Taxation group as well?

[tristanvanech]

this is the main one that nearly every filer will have: https://www.nj.gov/treasury/taxation/pdf/current/schedule-njhcc.pdf

does unlocked mean fillable? If so, it seems like I'm able to fill out the one at that link but please feel free to ask Treas in that email thread if you need it in a different format.

The next most common might be Form NJ-2450: https://www.nj.gov/treasury/taxation/pdf/current/2450.pdf

We then have a rider for people who have 5+ dependents which we created...Melanie can help you with that one

I think those are all the attachments, but I'm probably missing something

[damiansian]

Hey @tristanvanech

In this case, "unlocked" means without password protection. In order to tag the document, I need to be able to get to its root level. The docs online are all pw protected. When you get the full list, I'll make the request to the Treasury group to get unlocked docs.