The PDF Techniques Accessibility Summit’s objective is to establish a broad-based understanding of how PDF files should be tagged for accessibilty. It’s an opportunity to focus on establishing a common set of examples of accessible PDF content, and identify best-practice when tagging difficult cases.Modernizing PDF Techniques for Accessibility
The PDF Techniques Accessibility Summit will identify best-practices in tagging various cases in PDF documents. Questions to be addressed will likely include: the legal ways to tag a nested list, the correct way to caption multiple images, the appropriate way to organize content within headings.Refried PDF
My hospital emailed me a medical records release form as a PDF. They told me to print it, fill it, sign it, scan it and return it to the medical records department, in that order. In 2018? To get the form via email (i.e., electronically), yet be asked to print it? Did the last 20 years just… not mean anything! So I thought I’d be clever. I’d fill it first, THEN print it. Or better yet, never print it, but sign it anyhow, and return it along with a note making the case for improving their workflow. The story continues…Slides and video recordings of PDF Days Europe 2018
You missed the PDF Days Europe 2018? Never mind! Here you can find the slides and video recordings of all 32 stunning sessions!Using PDF/UA in accessibility checklists
PDF/UA, like PDF itself, is internally complex, but used correctly, actually makes things easier.
In mid-June of this year a number of software vendors with products for creating, editing and consuming PDF files came together in Boston, Massachusetts for a couple of days. The goal was to test our products currently in development against each other’s sample PDF 2.0 files to ensure that we caught any issues before letting those products out into the wild for real users to work with.
For any normal product release we have tens of thousands of sample files collected over several years: those created ourselves as well as those sent in with customer queries or purchased as part of formal test suites. But this is different.
This is testing our code for the features in PDF 2.0; features that are so new that nobody is shipping tools to create files yet. So we’ve been making our own sample files. But if we make sample files to test our own code we can miss issues because the same assumptions get made in the sample and in the code. We need a way to break that bootstrap problem.
And that’s why Global Graphics, in conjunction with the PDF Association, organised and hosted the US interop in Boston in June, just as we had in Cambridge, UK six weeks earlier for the first PDF 2.0 interop event.
Between the two events there was a good turn-out of vendors of leading PDF tools, especially those companies who want to make sure that their customers are ready as the rest of the market starts to roll out support for PDF 2.0 over the next year.
For the US event we’d acted on feedback from the UK event and put JIRA in place as a full tracking system for everyone to file sample files, ask questions and report their results. That made it much easier for all of us to follow what was happening, even though quite a few of the US event ‘attendees’ were actually working remotely. That JIRA instance has now been taken off-line, but we’ve backed up everything from both events and we’re hoping that we’ll be able to transfer the data to a JIRA instance hosted by the PDF Association at some point in the future.
The feedback on both events was good, with most participants saying that the information they’d gained had met their expectations and averaging a score of 4.5 out of 5 for overall value.
As to my own products … let’s just say that if you score an interop on the number of niggly little issues that you find while doing the tests … the Boston event scored pretty high! But that’s the point. Each of those issues that we find and resolve before we ship is an issue that our customers never have to see or deal with. And that’s a very good thing!