Hey, guys, what are we using for audio today?

MIRABAI: Receiving audio. Everything's currently indistinct now, though. If someone could talk directly into the mic, that would be helpful. 

>> I'm talking into one of the mics. I'm not sure if you can hear me clearly.

MIRABAI: You sound like you're underwater.

>> Oh, no. Okay. We'll work on it.

>> Testing the mic. Damian speaking on mic.

MIRABAI: Not bad.

>> It's Damian with an A. Thank you, Mirabai. Did I just break a fourth wall, by talking to the...

MIRABAI: No, very helpful, thanks!

>> Do we have video yet?

>> That I don't know.

>> So Mirabai... I asked Joly about the table mic. He turned it down, because it's gonna get some interference with the lav mic. So we'll turn it back up when we're ready to get going.

MIRABAI: Sounds good. Thanks.

>> Cool. We might want to bump up the font size on the captions.

MIRABAI: You know you can do that on your end, right?

>> Oh, yes.

>> The caption size -- we figured out how to bump up.

>> I just did it.

>> Yeah, perfect.

>> I'm about three minutes away.

>> Three minutes away. Cool.

>> We're nearly on time!

>> Mirabai, it's Shawn. Just wanted to let you know, because I don't think you can see it. But I'm representing and wearing my Steno Arcade shirt!

MIRABAI: I still don't have mine! Jealous.

>> What, seriously?

MIRABAI: Yeah, still waiting. Want it so bad.

>> It's a great shirt!

>> Can you all read the captions okay? 

>> Folks in the back, you can read captions okay?

>> I'll use my outside voice as well. Don't want to scream in the mic, though.

MIRABAI: I can hear you just fine.

>> Now you can read how many times I say the word "okay". Mirabai? I guess she's offsite.

>> Joly will give us a heads up on when he's got the streaming ready. So sit tight, everyone. We've got two or three more minutes before we have the video feed up. We'll let you know when we're ready to go. You can take things out. There's a bathroom. (inaudible). If you need an accessible bathroom, it's on that floor.

>> All right, everyone. Welcome to the New York City accessibility Meetup. Thank you all for coming tonight. I wanted to start by saying thank you also to Thoughtbot for generously hosting us in this beautiful space. Thank you, Thoughtbot. We are live streaming the event. So hello to the internet. And also I wanted to do a couple of practical notes. The bathrooms are right behind the kitchen here. They are gender neutral bathrooms. So feel welcome to use either bathroom. If you're more comfortable locking the door, there are locks on the door. And also thank you to SSB Bart for their ongoing sponsorship of the event. Oh, yes, and our two friends on either end of the room here, Mirabai. Who works with White Coat Captioning, is behind these awesome captions here. Thank you, Mirabai. And Joly is our amazing partner in crime, doing the video streaming on behalf of the Internet Society of New York. So with that, I'd like to introduce Damian Sian. He's gonna talk about building an accessible document workflow. Thank you.

(applause)

>> As Cameron mentioned, we're gonna be talking about building accessible document workflows. Specifically PDF document workflow. I'll give you a quick introduction for myself. I am currently serving as the senior web accessibility advisor at Princeton University. Newly minted, as of October 17th. Thank you. I do have my certification from IAAP, the International Association of Accessibility Professionals. And that would be the CPACC, the certified practitioner accessibility core concepts. Got that one right, right? Excellent. I think that's it. I do have a lot of experience in leading graphic teams, teams of graphic professionals. So within creative agencies. Particularly with a production studio. So I'll go over what that means. I'm gonna break this presentation into two sections. The front part will be process and workflow. So we'll deal with the mapping PDF accessibility to the process of the -- the creative process. And specifically with the creative roles and the team members within that process. We'll talk about how do we map WCAG standards to PDF. There is no PCAG. I don't have a PDF content accessibility guideline, unfortunately. So I'll give you a tool today that you'll be able to download after the presentation that does that mapping. Okay? We'll talk also about building responsible, accountable, consulted, informed -- a RACI -- for those different roles in the creative team. And then the second half will be practical examples. I have three tools to show you tonight. We're gonna review how to build an accessible color palette, we'll talk about an indesign plugin called Axio made to tag, and we'll talk about another indesign plugin called Formsmaker pro. And they solve some really big problems in accessibility for PDFs for a pretty low cost. So a lot of return on that. So someone challenged me here before I even started tonight and said PDF accessibility is an oxymoron. And this is an actual quote. So in the Accessing Higher Ground conference, there was a speaker -- and I was attending remotely -- and I asked the speaker is MathML, math markup language, supported in Acrobat? And that's what he said to me. PDFs are just pretty pictures. So we have some ground to cover. As an industry. About what we can and can't do in PDF. So let's talk about what we can't do. What are the problems with PDF? I'm not gonna -- I'm not here to -- I'm not a shill for Adobe or anything here. So the User Experience -- PDFs take users out of the web experience into an orphan page. True. User Experience is hampered by PDF in a lot of ways. You're in this great UI, this great UX, and then you're in a PDF. How do you get back? There's a lot of problems with that. Unresponsive. Yeah. PDFs are static. They cannot dynamically flow into viewports or present content and context to a user interaction. They look horrible on mobile. True. Very true. ARIA support. So if you think of ARIA as an accessibility markup language, none of it goes over to PDF. So we do a lot of kind of hacky work around PDF and accessibility. And I'm gonna show you so many of these tonight. So why am I here talking about PDF accessibility if we've got all these problems with it? So the next quote on my screen is: Very few love PDF, but we all need it, because PDF is electronic paper. And that's a quote by Jeff Johnson. It's a very good analogy. So a PDF is a render of the printed page, essentially. Okay? It is almost like a pretty picture of a printed page. And there are times when that's extremely advantageous to have. Portability. Everyone should hopefully know what the P in PDF stands for. It's portable document format. So that same thing that was a hindrance, the unresponsiveness, is actually a benefit as well. There are times when I need to have that document look exactly the same on mobile, on Chrome, on Firefox. Okay? The barrier to entry for someone to create a PDF is a lot lower than html. So Janice in accounting can make a PDF. We can use commercially available software to create PDFs. Microsoft Word, InDesign, Acrobat. I don't have to have a dev, a QA environment, an infrastructure, and teams of people to do release management for me in this. We can be quick and down and dirty. Regulatory requirements -- there are times when you are mandated to produce a document and give it to the public. You have to have an electronic representation of that document look exactly the same as the print piece. An annual report and proxy statement. SEC requirement. Has to look exactly the same. And there are also other formats where it's just a benefit to have that look and feel of... Excuse me... So on the train ride here, I was doing some research about good and bad... Oops, I'm so sorry. The good and bad of PDF, and I found this quote from Jacob Nielson. Thank you, Mr. Nielson. PDF files make usability approximately 300% worse, compared to html. So Adobe has a patent, apparently, to reach out and smack you in the face with a PDF, because the User Experience is so bad. I'll just go on to talk about some areas where they're needed. And in further research on that piece, what are the good places for PDF? White papers. I found this cool piece of research here, about how to conduct eye tracking studies from... Oh, wait, it's from the Nielson Group. Fancy that. So there are times when you need PDFs. And out of curiosity... Is their PDF accessible, do you think?

>> Yes.

>> Absolutely not.

>> Aw!

>> PDF is the enemy of accessibility. I'm sorry. There's nothing about it that was accessible. Two can play that game, Nielson. Nielson!!!! So WCAG. How does WCAG apply to the PDF? Like I said, there's no PCAG. They don't have a separate standard, I say to the working group, WCAG guy. I'm frequently shoehorned into these different success criteria. So PDFs can do things like animation and video, and they can do buttons for navigation and stuff like that, but it's really the outlier. And I personally don't recommend it. So we kind of have to go backward compatible with a lot of these success criteria and say... Here's a thing that was written for the web. Here's how we can apply it to the PDF. And there's a gap that exists then too. The WCAG was written for web developers. Web developers don't make PDFs. We have a different group of people that do that. There's a completely different set of people, set of talents, set of skills, strengths, weaknesses. And I'm gonna kind of explore that tonight. So let's talk about the tasks of PDF accessibility. I would recommend that you break them into two major categories, of visual impact and non-visual impact. And then you would front load those items to have a visual impact into your creative workflow. So before you would transfer a file for a client review, you would have checked those things that have a visual impact. And then those things that have a non-visual impact, if you can set a good relationship and expectation, you can manage the expectation, you can tell those reviewers that those non-visual accessibility aspects can be handled prior to release. So there should be no change, visually, in the file they get. And here at this point I'm gonna jump out to... Microsoft Excel. I use Excel for lack of a better format for this. And here I broke down the major tasks of accessibility in PDF into 14 unique steps. And then I gave -- and then in the next column, kind of like -- it would be better formatted as a user story, but I kind of wrote the natural language of -- what is that task? What does it do? Why am I doing it? So I always put document title at the first of all my tasks. There is some visual part of that, because the document title appears in the document window of a PDF. So you don't want the file name to occur there, for -- if you give it to a client. And I make a lot of mistakes in that. So one of the things I'm kind of famous for is taking an old document, using it for the new document, and I forget to go in and change the title and the metadata. So I put that at the top of my task list. You can see these first three tasks do have a visual impact. So obviously color is the sole means of communication, and color contrasts, and links. So links should be visually distinguishable from their surroundings and they should avoid things like click here. A stronger call to action in your links than read more, click here. Same for PDF, same for web. The next column, what I did -- I'll read the first one here. Document title. The page title will be read aloud by the non-sighted user's screen reader and visible to all sighted users in the document window, instead of the file name, which is a default condition. So all these tasks have that natural language thing. What you can start to do there is to build your own standard operating procedure or embed this into your contract language when you work with vendors as well. So if you're trying to describe to someone who's never done this work before -- I see that I have something to do. Why do I have to do that? And that is trying to give the user impact. And then the shoehorning of -- we have these WCAG requirements that are written for the web, and now they're being applied to the PDF. So I'm giving that call, to say -- here's the task. Here are the things that the WCAG requirements, the success criteria, which I always equate immediately to the word "requirement", what I have to do, to make the document conform -- in this case, document title is success criteria, 2.4.2, page title, level A... These are the success criteria. The W3C does have PDF techniques listed out. A lot of those techniques are about manually editing the Acrobat file, the PDF, after you export it from Word or InDesign, which I'm not a fan of. I like to remediate the Word or InDesign file. The next call is the automated task. So Adobe does ship with an automated checker, but it's very misleading to think that if you pass that checker, you have an accessible document. 20% to 25% of the things that are wrong are gonna be flagged in that automated checker.

>> What if you don't have the actual source? Because if you're browsing the web, you're not the content creator. You're the receiver of this. You don't have a choice. What do you do about that?

>> (inaudible)

>> Acrobat ships with tools. It will walk you through the steps of tagging all the content. You can get a tool like... (inaudible) PDF global access, which will walk you through the steps. A lot of strong tools for that as well. If you're doing a lot of documents or a document with a lot of pages. But always try... The moral of my story here is... And I would honestly say... Look into a vendor relationship as well with a company like BrailleWorks. That's a great company. They do about 9,000 documents a day. They have very affordable prices. I've worked with them. Extremely high quality work as well. So automated tests. I'm gonna go over what the automated tests for this first one -- just to give you an idea of the rest of this. So automated checks for document title. Checks whether there's a title in the document window in the metadata and if the title is displayed in the document window. So failure would be if the open options are not set to allow the document title to be up in that window or if you didn't put the title in the metadata, the file. That's what the automated check would do. So flag A is on, flag B is on. You have a title. It's in the document window. Success. But what if the title is gibberish or you've done what do I all the time and it's an old document title? You messed up? So the manual test -- verify the title is meaningful. And in that place, I also put a best practice. Use the H1 of the document as a title. Okay? And this document I'm gonna give you guys as a resource -- every step is listed out like that. So it has the step, when you should do it, how you're solving for accessibility and inclusive design, what the automated test will do, what it won't do, and then how you... The areas of deficit in the automated test -- how does the manual test solve for that? Make sense? Good. So this file as well will be available... So the deck will be available online and all the links out will be available online for you as well. Okay? So let's talk about the creative team that makes PDFs. And this is kind of like an archetype... In the way that I look at the workflow. You might have one person do all these things. Okay? I would hope they would do them at different times, at the very least. You might have two people. So RACI stands for responsible, accountable, consulted, informed. And the tasks of making an accessible PDF -- what I would consider the production person has the most responsibility. Okay? Management would be the most accountable. Design would be the most consulted. And the proofreading would be the most informed. And if you look at the spreadsheet that I've given you, each one of those tasks will say that -- so for metadata, the person responsible for that is the production, person accountable is the management, designer is informed, and the copy and proofreader task would be consulted. So I've done that for all of those pieces, and we'll take a closer look now, if that's confusing, into what that actually means. So a production artist -- now, you may or may not in your workflows and creative team have a production studio. If you don't have a production studio, you at least should have someone who fits this bill. The production artist is typically the most well versed in Adobe InDesign, Microsoft Office -- they are the most versed in that type of software. They deal with applying industry-specific requirements to PDF, so if you have a team that would take a PDF and send it to a magazine and convert it to PDF X1A, and the document you sent them, the document you got back, looked identical -- you asked what did they do -- that's the person that is most responsible for accessibility. A lot of the tasks that you do in PDF accessibility have no visual bearing on the file. You give me the file, it'll come back the same file size, hopefully, maybe a little bit bigger, but it will have no visual changes. Okay? The management team. So these are your project managers, traffic managers, account executives. In the kind of CYA model, they have the most A on the line. So they're most accountable. And they're the people that are making deals with your clients. They're the ones that are gonna present your work to somebody and say -- this is accessible. I have an attestation document from my production person that this is good to go. They're accountable for accessibility. I expect those people to have no technical knowledge in accessibility required. Design teams would be creative directors, art directors, graphic designers. So these are people who are connected to brand, essentially. They own the color palette. They would arbitrate any type of decision that would have to be made when visual consideration is on the line. Especially if there's any impact on the brand. And then copy and proofreading I put into one button, because I needed to. It fit my RACI. People who deal with words. Copy editors should be the people dealing with alt text. You shouldn't have a production person writing the alternative text. That's a wasted opportunity. They should also be writing the link texts. If they're gonna do calls to action. Read more is not descriptive. The copy editor is connected to the creative brief and the purpose of the brand and everything else. Then they should be the one writing that. And then proofreaders. We have alternative texts on images. Usually manually keyed in. That has to get proofread. And I have a tool that I can show you. With the Axio make a tag and if we have more time at the end I can show you the format to export the PDF from where you can read all the alternative text and plain text. Or you can train them to right click on the tag and look at the properties on the image, which is probably not gonna happen. Document titles keyed in incorrectly all the time by me. And other areas that go wrong in that. And then as one of my friends pointed out to me, color as a sole means of communication -- excellent thing for them to be looking at. And any kind of sensory characteristic within the text. If you're expecting the people who work on those non-visible attributes to catch that kind of stuff, you're completely offbase. So as a production artist, I would never, ever, ever read the content. Actually, I've trained myself over 15 years to not read content. I'm looking at line endings, wagging, orphans, widows, tons of typographic goal considerations that I'm making, hundreds of options -- reading your content is never gonna be one of those. Question?

>> Yeah. So how does, like, data entry play a role into this? Because PDFs do have, like, forms. Typically online forms -- I'm not sure how this process works --

>> I have the whole last section on forms. You don't have the agenda, so...

>> I just don't know how this works in this format that you're talking about, process-wise.

>> (inaudible) I wrote a bit on that -- the copy proofreader and copy editor. You have to put descriptive language onto each form field, so it would be helpful to have the copy writer kind of craft that. So if I pulled up a screen reader and have a list of all the form elements, I want them to be descriptive, standing alone. And the proofreading element, which I can show you as well, on how to have them proofread as plain text. All the descriptions on those can come out as plain text.

>> The keyboarding aspect --

>> Tab (inaudible)? Production person. They're the one setting up the structure pane. And they're the ones who are gonna do the QA on that.

>> Thank you.

>> No, please, thank you. You're asking good questions. Okay. So... The last piece of that puzzle in the process and operation-type workflow would be vendors. So if you're building a contract, an RFP, service agreement, statement of work, anything like that, and the vendor is producing a PDF for you, you have to obviously ask them to make it WCAG2.0AA compliant. Obviously. My suggestion to you is that you use that exact language. And in their warranty of conformance would be -- an attestation to that effect. They will produce a document to you in such a way... What do you accept as proof of that? Okay? I am comfortable... Did I touch my mic? I'm comfortable accepting the automated checker report, which has 29 automated checks, and then two manual checks. So you would right click and manually pass two. Color and reading order. I'm comfortable with that, if the vendor agrees to... When they manually pass those two manual checks... That they're passing all of those manual gates. Every single one of these. All right? So that would have to be built into that language. So you're building a contract. You're building a service agreement, statement of work, RFP, feel free to take the document that I've given you and deconstruct it and build it into your own process. And start putting people on the line. Okay? So if vendors out there can't -- if they say "I don't know what that means!" It's time to learn. So I'm gonna get into the practical examples. Any questions on the process workflow? All right. So this is... I guess a tool, a process, that I'm gonna describe to you. And I'll first describe the need for it. Working with color, you have to have proper contrast for headline text versus body text. And if you are in a brand, you have approved colors that you're allowed to use. That's usually produced in something called a brand style guide. So I went online and I looked at quickly... You know, a sufficient example of brand style guides. This is Pfizer's from 2009. Hopefully you guys won't sue me. It's on the internet. I picked it because it listed all the hex values very nicely for me. Oh, sweet. I'll just take those and I'll run this tool on that. So this would be all the colors as an internal designer that you would be allowed to use or an external vendor partner that you would be allowed to use. So we need to find the pairs of colors that are allowable within the success criteria of 1.4.3. So I have to have them all be contrast compliant. So I'll show you now a tool to do that. So the first thing I did was come in here and just nab out all of those hex values. Just copied it and pasted it to... A text file. Pasted in the hex value, comma, space. And wash, rinse, repeat. And then... I would bring it to this cool tool online. And this is, from what I can tell, a free tool. That's very nice. That the North Carolina State University has published, that will allow you to paste in all those nice hex values that you can just grab out of there. And then say -- I want level AA compliant contrast pairs. Not AAA. That would be -- like, 7 to 1 would be the lowest contrast ratio. Very hard to follow. Okay? Of so it does this nice little trick here, where it evaluates every single hex value against all the other hex values, and then you have all your passings. And all your failures. I don't know... We're not gonna deal with all the failures. So I want all the passes. Because now I have everything that's compliant and legal in my entire process. So from there, I go and... I'll make this a little bit bigger for you, so you can see it. So I copied and pasted them all into an Excel file. I divvied them out if they passed for large texts, which would be your headlines, versus the small text, which would be your body copy. But then you get some real... Nightmare juice, right? I don't know why you would want purple and green. That's not good. So I put a column in here. And I said... Is it pretty? Yay or nay? Keep or kill it? If it's gross like that, purple and green, I don't want it as part of my brand, even though it's compliant. It's the logo. Yeah. That's outside the scope of 1.4.3, so you can do whatever the hell you want.

>> (inaudible)

>> So let me show you what I did with that. That content. So if this was the color guide... So I have the brand style guide and I have the information about how to use the logo. What type to use. How do you do this? How do you do that? Here's all the colors you can use. The next page in there that I would suggest would be... Which page? Show me all the accessible color pairs at large text and all the accessible color pairs at small text. Have this available for all your internal designers, and have this available for all your vendor partners. So now you have your sandbox defined well, about what you can use as the designer. So you're setting up new styles. That's for both web and for PDF. Any questions on that? Why you would do this? Or what the value of this would be?

>> (inaudible)

>> Like... Less than half an hour. I go pretty quick with my copy and paste. But I would do this once. I mean, how often do your brand colors change? Not often. Yeah. If someone was a good developer, they could probably figure out what the people at North Carolina State University did, and then put a tool in there that would just have all the passes and give you a button that said do I like it or not? And then you can pump it right out. If you guys work out all the business requirements I gave you, next time I see you, I'll have a nice tool. It'll take no time at all. Just push a button! It would be really cool too if you could just have JavaScript that would evaluate your page. We'll talk. Right? So yeah. Recommend doing that. And that process, just so you know, so I went quickly through that. There's a document that I'll give you that steps out exactly how to do it. Painstakingly. Screenshots. Everything you need. All the links that you need. Exactly how I did it. I know I went quickly, but I have 45 minutes. So... That's for you all. All right. The next tool I'm gonna show you is a plugin called Axio Made to Tag. The company is called Axio. The tool is called Made to Tag. This is a company in Germany, and they produce a plugin to Adobe InDesign that sits within InDesign that walks you through all the tasks of accessibility. It also does some things that you can't do today in InDesign at all. You would have to do after you made the PDF. Okay? And also one of the coolest things that it does is it can tag complex tables and build a parent-child relationship with cell IDs, directly in InDesign. Which is something that's only available today using the touchup tool or using a tool like Common Look. And a touchup reading order tool would take hours, and Common Look you would have to run every time, to set the parent-child relationship. So this will give you the control and the freedom to have a repeatable accessible result. So there's a huge efficiency multiplier in this tool and a huge quality multiplier in this tool. So I'm gonna jump over to Adobe InDesign. So I'm gonna start up Made to Tag. My screen is a little bit smaller than I'm used to dealing with. As you can see on my screen, Made to Tag is inside of Adobe InDesign. So I don't have to jump out into another tool. Right now I have to go from InDesign to Acrobat, do all my testing, and come back and fix the problems I found. This will allow me to find those problems and do that work inside of InDesign. So I had my steps broken into 14 steps. They had theirs broken into 7, with some supporting features. First thing they do is they help you to take your paragraph styles and map them to export tags. That's something you can do manually in InDesign without this tool. This is walking through and prompting you to do it and giving you a tool that's visible in its own kind of secluded space of accessibility. The next thing you would do would be to help you build the logical reading order of a document. So it would help you to build your articles pane. And this neat feature here... Now, if anyone here is familiar with the PAC2 checker, where it has the screen reader preview for the Matterhorn protocol, it gives you this view. But again, you have to currently make the PDF and throw it over to this checker, run a check, open up this report, and then you can see it. Now I can see kind of a live preview of all of the structure of this document. And it's got the H1, the paragraph style, it's got all my semantic structure of the document, now exposed to me in InDesign, with this tool. So I can see that I have a list here, for example. It's well formed. It's a list within a list. I've got a nice sublist structure. And I can see that I have a table here and I can see that I have a violation. If you're able to see the screen... Anyone can tell what the violation is?

>> (inaudible)

>> I was looking for no table headers. Okay. It's basically gonna go over to TD, over in the structure. Yeah. So... In addition... That table has a lot of complexity to it. Which is where we're gonna spend the majority of the time reviewing what this tool can do. This piece will also expose all the alternative texts in a document for you and help you find the pieces and apply the alternative texts to them. For example, I'll go to my presentation deck. And say... There's two images in there. And here's the alternative text that's applied to them. In addition to that, it will also produce a document that shows you and exposes the alternative text in a document for you and lets you make an interactive PDF of that, so you can share it with your proofreaders. They can tell you that you keyed in the name of your company wrong, which I've... Another particular issue of mine. So you can put in the metadata, document title. Author. You can also set the language of the page and the language of the part directly with this tool. So those are two requirements for language that we take over from the website. Language of the page would be English. And I have one section of this that has German in it, because it's a German company. If a screen reader encountered their name and address, I want it to read in German 1996 Reform. It's very important. And then table structure. So... This table is pretty unique. It's a balance sheet that's on my screen. Balance sheets are broken into assets and liabilities, and then there are subcategories beneath, where there's a parent-child relationship that's required. So if I were to meet success criteria 1.3.1, I've given the full programmatic equivalent to visual presentation, I can visually see the difference between those elements. I need to give them programmatically as well. Normally in InDesign I'll take assets from 2011, say that's a table header, it passes the check and I'm out. That's pretty weak. InDesign won't even allow you currently to apply row headers. These are clearly row headers. That's all work you would have to do over in Acrobat, and every time you make the PDF, you have to do it over and over again. And if you were to do it correctly, to make the parent-child relationship, it would take you hours. Or you would have to invest in a tool like Common Look. So I'll show you how to build that complexity, the parent-child relationship in here, in maybe under a minute. Someone want to time me? Let's see. Okay. Go now. So I'm gonna activate these smart headers here. I'm under the gun now. So I'm gonna take these first two headers and I'm gonna say... That content applies to that header. That content applies to that header. That content applies to that header, all the way down. And I'll take that header and say -- one, two headers apply to it. Gonna take that header. Only those things apply to that and only these things apply to that. And you guys are row headers for that and you guys are row headers for that. One, two, three, four... Since I'm being timed, I'm not gonna talk now. Done. 45 seconds. Then that process and touchup reading order tool -- you'd be here 'til tomorrow morning, doing that. And then if I were to do this in Common Look -- let's say I could do it that fast, every time you make the PDF, you have to do it again and again and again. That's a chore. That's right. That's gonna hinder your efficiency and I would think your quality too. So the last step in this process would be to make a PDF. This will make a PDF UA compliant PDF. If you're familiar with how to do that, you're really just sending a piece of metadata, the XMP metadata placard that says PDF UA identifiers on. I can do that here in InDesign, by going down to the metadata placard and saying... This is a PDF UA compliant document. Or I could just use their tool, which has it embedded right in. I do not want to save this. This is my source file. I'm sorry. I forgot to... The PDF... It will render... Using the interactive PDF export settings... And this doesn't have the... So I'm gonna open up that PDF that I just created. I'm gonna show you yet another tool. This one's called Callas PDF Go to Html. What this is gonna do is to render that same structure view, but it has this cool interactive structure in here. You can see the table headers that we just applied, all the work we did. Watch when I hover over these pieces. You can see it says accounts receivable as a row header for 2012 and 2011 and it relates up to current assets, as opposed to... These other pieces, which relate up to different areas. That's achieved through creating cell IDs. You can do that in html as well. I don't think -- correct me if I'm wrong -- that there's a tool that does that in html. So ptthhbth. Right? PDF, huh? Huh? I told you. So pretty cool... If you want to order this software, the contact information is at the end of the document that I'll have online for free. I do have actually some fliers for that piece as well. Any questions on Axio Made to Tag? How cool it is? What it can do?

>> What's the price point?

>> 149 Euros. I just had a look.

>> It's going up. I'll give you a flier. It's not gonna break the bank. If you had to make actual compliant complex tables, I don't think there's a price they could charge high enough for that. And now, as promised, for you, sir, forms.

>> Oooh!

>> So PDF -- excuse me. Adobe InDesign is completely capable of making interactive forms. And to do them... I have my air quotes -- "accessibly". It's as accessible as you can get them in PDF format. We talked about all those things that are wrong with PDF, and there's a lot of them that are apparent here. Web forms are better than PDF forms. I'll say it. Web forms are better than PDF forms. I'll say it again. You're right. But... Most forms are paper. And they put them online. And there's a lot of places where you're not gonna get around that. State requirements, federal requirements. Business requirements. People like to grab a piece of paper, especially financial professionals. Gonna interview you. Oh, you're gonna buy a house. Start filling out the form. And there's always an online version of that. Yes, the online person has to be accessible and it's preferred that it's interactive as well. Now, when I was developing some training programs for people who are using InDesign to make those forms, the process was... It was ready to break and I'm glad accessibility broke it. They were making a static design. Creating the interactive elements in Acrobat, applying them, and when changes were needed, they would redo the static design in InDesign, make a PDF, and then all the interactive elements would come over and they would fuss with them. You add accessibility to that, and you're done. There's no way. You have to go and manually tag all those interactive elements and order them. It's completely unsustainable. So I can convince them to get out of that process and get into InDesign solely as your authoring tool -- make the interactive accessible PDF from InDesign to PDF. And they were down with that. Until we got to... These requirements, where they had to produce manual formatting on elements. On some of the text inputs. They call them comb. Wrong. No. Yeah. Sure. So you see these boxes underneath date of birth and social security number that open on the top? It looks like a comb? Comb. So when you type into the interactive element, the text fits into those little boxes. To do that today in Acrobat, it's a manual process. You have to say it's a comb of 3 or 4 or whatever. So my training broke. I was up a creek. I wasn't gonna conduct the training. I was gonna say -- don't use this tool. Ship it all to a vendor. I can't build a process for you that works. Interestingly enough, in my research, I found Formmaker Pro. It's not an accessibility tool. It's a form formatting tool for Adobe InDesign that has a really great use in the workflow. So what it allows you to do is take text input in InDesign and add formatting. I can choose the font, the color, the size, and a lot of different attributes. And that will carry over to the PDF. I can also do something pretty interesting here. I can put in custom JavaScript validation. That will also carry over. And I can format these combs. You see I have a bunch of Xs. Date of birth in the first two comb values, that's XX. And that's how you run this script. So the script lives in the script library. Like any other -- InDesign has tons of scripts. If you're not familiar with it... Like, to make this state of... This state combo box, I used... Something called Combo Mambo. I took a text file of all 50 states and dumped it over. JavaScript basically just grabs all that stuff in and throws it in with InDesign's API. It's pretty cool. Combo Mambo wasn't. I don't want to get too totally off with that. Formmaker... It's quite common within InDesign workflows to have a lot of scripts. Adobe can't figure out every single thing you're gonna do with their program. So people create these custom scripts. And this is what Formmaker Pro is. It's a custom script. It's gonna take all those values -- font size, color, weight, in this case, custom JavaScript, and it's gonna take in this comb formatting, and save it into the document metadata. And then bring it over to Acrobat, and I'm gonna extract that metadata down, and it's gonna live in the document. So that quick two-button thing, as opposed to manually formatting every single element. It saved the training that I did, and I can't say enough good things about it. So all you do, you double click and it says Formmaker data has been successfully stored. It takes all those cool attributes and puts it up into the metadata and it doesn't really change the file size dramatically. So when I export that PDF... I just use the regular exporting features and then I'm over here, and right now I have no formatting. So this is what it would look like if you don't... It doesn't know that this is a comb right there for the date of birth. So what I have to do is go and say... Please take down that metadata that's stored in this file and apply it to these form elements. And I just did it... Boom. As fast as I clicked the button. And now I've got some leftover formatting here, which is taken out really quickly by saying... Clear the form. And there you go. So now I can start typing... And this font -- I probably could have picked a cooler font for the demonstration. But it is 11 point Times New Roman. The new hotness. You know what I mean? And then I've got your standard combo box, font -- the custom JavaScript that I put on -- I don't write JavaScript. You might know somebody who writes awesome JavaScript. I don't. I found this on the forms. So this one is gonna say... Did you put in five numbers? One, two, three, four. No, you didn't. Okay. One, two, three, four, five. Yes, you did. And now the combs. So... One, two... Three, four... Five, six... Seven. Okay. All the comb values are now present in there. And then the email. Does it have an @ symbol? No, it does not. Okay. And now you've got it. So you've got the idea. So that's Formmaker Pro. Also reasonably priced. I think I wrote to the developer and he did put his prices in. $149 US for Form Magic, that doesn't have the JavaScript, and then $249 for the version that does have the JavaScript available. For JavaScript custom validations, you can do just about anything. And I'm only four minutes over my time. 49 minutes. I was supposed to take 45. So that cuts into your questions. So... That's the end of my presentation. Now questions. Thank you!

(applause)

>> You, sir?

>> Firstly, thank you very much. I have two sort of... Two questions. One is... I work for a city agency. We manage part of nyc.gov. That does tons and tons and tons of PDF forms. And two months ago, I made a how-to-do-accessible-PDF guide for our not so tech savvy content writers. Do you have any recommendations for explaining PDFs to people who by and large are not making the PDFs but are not exactly the most computer literate folks out there?

>> Yes. And I've built web-based trainings that kind of help bridge that gap. And I start at a level of describing what a tag is. Describing what a heading is. Describing what heading nesting is. Is important. So it's through training. And it was not a quick training. It was about an 8-hour training. And I didn't get full results, to be honest with you. Some people glom on and some people... They tune out as soon as you say tag. XML, HTML, not me. I'm out. But the people that I did have success with... It was breaking down concepts, the core concepts of accessibility, into structure and always using a screen reader as well. So pulling up a list of headings. Pulling up a list of links. And showing those navigation features kind of drove home... I think to that spreadsheet that I built, the column B, where you're writing in the natural language, and maybe have some examples of do and don't, good and bad, and then also breaking down that structure... There's some things that they just don't need to know. Where it's too much information. So... Finding those people and saying -- you're the person who writes the content. I need to you look at these five things and really nothing else. So is that a good answer? Did you have another question too? Is it two-part?

>> It's two separate questions. The other one is: We sometimes work with PDF forms that are bilingual or have significant content in another language. Usually Spanish or Chinese. And I noticed that you put part of your form in German, and I was just wondering if you could show me how you did that.

>> Are you using InDesign?

>> Sometimes. But sometimes I'm checking a form that someone else with InDesign made.

>> I can show you in InDesign. Is that okay, if I just show you? So if I were to make some text... Forms... And I want to find the palette... So you're putting me on the spot a little bit. There we go. There it is. So we can set the language in two areas. One is the language of the page, which would be set on the export, so Adobe InDesign CC 2017 has a different export feature, so when I go to make the interactive PDF now, it's gonna ask me what the language of the document is. So that could be English. Normally you create a base in English and then you translate into another language. Okay? And then so the language of the part -- you can identify here under the character palette. So pick an easy one, maybe. I don't know. But there's so many Germans. I don't know why there's, like, eight Germans. What he said... I don't know. Spanish. All right. So... I just told InDesign that that text frame was my language. And InDesign creates tags. It recognizes the text frame and then whatever paragraphs you put inside of it -- it should wrap that container, and then when a screen reader hits that, it will read it in a different accent and functionality in the language completely.

>> It's not so different from the way I do it already in Microsoft Word.

>> Oh, you can do that in Word? Of course I knew that. I was just seeing if you knew that. Yeah. I haven't really tested it from Word. Actually, I never tested this with a screen reader. I wouldn't know if it was doing it right or wrong. I don't speak other languages. So it would be useful to test that. I would be happy to... You know, if you want to work on that, I would be happy to do that with you. Are there other questions?

>> I guess a lot of this premise is that you're looking at it in a browser or on the web. (inaudible) on a particular device... Let's say... (inaudible)? Something like that? The PDF is on that device, or something, and they're supposed to read off of that?

>> So they... Let's talk about -- they who?

>> A user.

>> With an assistive technology? A screen reader?

>> Perhaps.

>> I have never tested a PDF being read aloud on VoiceOver, for example. I've tested them on JAWS. That's the only screen reader testing that I've ever done with PDF.

>> I've done some. (inaudible) the only PDF viewer that I know of (inaudible) the only PDF viewer that I know of for certain that actually allows you to access all of the different kinds of accessibility metadata and tagging in PDFs is just Adobe's, and only in Windows. So most keywords will give you some basic text information, but a lot of the tagging -- what it would take, for instance, most screen readers and most other PDF viewers will not be able to handle that, and I'm sincerely hoping that somebody will correct this and comment on YouTube or Twitter, because it would be awesome to find another user that does work with PDF, because right now the situation is pretty dire. If you want an accessible PDF, it means you have to use it in Windows.

>> My test was with Acrobat Professional in JAWS. Not a common tool for people to have, I suppose. I could be testing in Reader, at the very least. But in a desktop application. Not within a web viewer. This would be a situation where you have downloaded the PDF and you're reading it off the desktop.

>> I know people don't print manuals anymore and they distribute them as PDF files, apparently. And they're deemed accessible, but then if you put it on a device, like... You know, that's not Windows, only 1% or less is Windows, actually, on mobile devices, what does the person do?

>> I forgot one, which is kind of silly. Because I work at Google. This is running live. Chrome is actually in the process... I think they are just about done (inaudible) just came back from vacation, so (inaudible)... They just completely redid how they do their PDF handling within the Chrome browser. And so before it was just flat text that wasn't terribly helpful. And now it actually has semantic structure and screen readers can latch onto it. So there's that.

>> Okay. 

>> (inaudible)

>> So right now Chrome officially completely supported is with Chrome Vox in Chrome OS. However, Chrome has made a lot of improvements to how it works with other screen readers. So it works fairly well with VoiceOver on Mac OS. Fairly well and improving fairly rapidly with both NVDA and JAWS.

>> (inaudible) it would read table captions in the PDF, where no other reader would do that?

>> So you can actually open up the PDF in a browser.

>> Not the browser. The application. So if you download Reader. And use Reader. (inaudible)

>> Speaking of web... I've often seen requirements where a web application would export something to a format that would otherwise -- could otherwise be represented in html or otherwise is represented in html. I've seen a bunch of hacks around this. Taking a screenshot for an html page and saving it to PDF format, et cetera. So my question is about tools for exporting html to properly tagged PDFs. This is an open question. If you don't know anything about it.

>> (inaudible) I've experimented with the opposite. Taking PDF and trying to make it... So because I have the tool to make the cell ID tagging, I'm like -- oh, let me just give html to my developer from InDesign and backtrack out. That was not successful. So I've never tried it the other way, of doing html formatting -- so I mean, then if you have anything like... Any ARIA attributes, that wouldn't go over. I know that.

>> Hypothetically. I guess some of the semantics of html should map pretty closely to PDF format. But I did some research and I couldn't find anything. So this would also be something for anyone that's watching out on the internet... Or who picks this up afterwards, commenting on YouTube video... I think that would be useful.

>> Just one thing to note. I've seen a few JavaScript plugins to handle it now. If you generate the PDF from a web page. And all those do it the image way. So that will never be able to be made accessible properly. There are a few that I know that are like -- I think one is called PDF to html. It's like a back end thing that actually sits on your web server. That'll do it. But from a front-end side, you can't handle it. And the view is what they call (inaudible) the controller to really handle that. It's called PDF to html or something. I don't really remember off the top of my head.

>> This has a PDF to html here, but it's used to kind of preview -- what would your file look like in different... I don't know if you can export out from this.

>> In Common Look, they can sit... In the middleware...

>> (inaudible)

>> Proprietary, give them your money kind of deal.

>> Any other questions? Going once. Twice. Closed. Thank you, guys, very much.

(applause)

>> Well, we've concluded the speaking portion of the evening. Thank you, and thanks again to all of you. It's 8:10 now. I would like to go home fairly soon, and I have to be here until all of you are gone. So... Let's try to be out of here at, like, 8:30. I'll remind you. So 20 minutes. Hang out. Talk. Actually, Adrian is going home. Don't ask Adrian questions. Thanks again.