PDF Accessibility: What’s in Store?

Post was first published on Media Access Australia’s AccessIQ

There’s been a lot of talk lately, in technology circles, about what’s in store for PDFs. For organisations that are looking for ways to ensure on-demand accessibility for high volumes of PDFs created at the enterprise IT infrastructure level—this is a particularly relevant question.

With that in mind, I wanted to address it here, and offer my own two cents on what I think is going to happen with PDFs—and, specifically, accessible PDFs.

The end of the PDF?

The debate comes down to this: is the PDF being replaced by HTML and XML formats? Many feel that it should be, arguing that HTML and XML simply offer a better user experience, and are easier to make accessible, with a tagged structure inherently compatible to screen reader technology for the blind. From my perspective, though, PDFs aren’t going anywhere—for several different reasons.

First of all, Adobe has invested a lot at the code level for creating better PDFs, including the PDF/UA format, a universally accessible PDF format meant to help PDFs more easily meet accessibility standards and requirements.

And companies, as well, have invested heavily in PDF technology, because most organisations still utilise PDFs—in fact, it’s still the de facto standard for communicating information in a format that’s viewable to most readers.

A trusted technology

Even for those companies who may be using HTML for some uses, there still exists a need for PDFs. Take a bank, for instance. Banks regularly offer their banking information in rich HTML on their online portals, for an informative, user-friendly experience. Most customers wouldn’t think of searching out a PDF in lieu of that experience—at least not for their everyday banking.

Most financial institutions have invested heavily in creating an IT architecture that allows massive amounts of data to be funneled through different types of processes and applications to be converted to both a print file—that goes to the printer and results in the paper statement some still receive via snail mail—and a PDF file, the de facto standard for online presentment.

But banks also have a legal obligation, as do other industries: they must meet regulatory compliance standards that often require the PDF format they output be the official record on file. So even if that bank is offering statement summary information through HTML, they still have an archive of PDF records.

And when individual clients need documentation, for instance, to prove creditworthiness for a mortgage or a loan, HTML won’t cut it—they need the official PDF documentation for those purposes as well.

Accessible answers

From an accessibility standpoint, HTML does have the advantage that covers all scenarios. Tag structure is inherent to HTML, so accessibility can be built in during design. PDFs, on the other hand, often need the tags added, since many are simply output as image-only PDFs.

But technology is  now available  that can  automate the accessibility of these PDFs, making communications created in high volumes at the enterprise IT level, like bank statements, medical notices, bills, etc. completely accessible on-demand, at the same time for all customers—with and without disabilities.

And that’s important. Having full, independent access to information, especially critical financial and health information and documentation, is something no one should have to wait for since technology is available to make it happen. Because even with the growing use of HTML, I don’t think PDFs are going anywhere.

If you have any questions, please leave them in the comment section below or contact me at skelly@actuate.com

Accessible PDF: Enterprise Vs. Desktop Accessibility Requirements

Document Accessibility ApplianceFirst published on G3ict.org.

We receive a lot of questions at Actuate about our PDF Accessibility Appliance, a solution designed to make PDF customer communications accessible to the blind and visually impaired community. Many of the customers who approach us want to know how our solution differs from others on the market and what types of documents are best suited for our solution. Actuate’s Accessibility Appliance is unlike other accessibility products as it is designed for PDFs created at the enterprise level. So what’s the difference between PDFs created at the desktop level versus the enterprise level? It’s a good question that I’m going to delve into here.

The Desktop Level

PDFs created at the desktop level are done so by a person, generally using popular programs such as Microsoft Office, Adobe Creative Suite, etc. That’s what defines this level of PDF creation: individual people create the individual document. An example could be as simple as a newsletter created for delivery or web distribution to all customers, or may be as complicated as the thousands of program documents generated each year by Medicare/Medicaid insurance providers and found on their websites. Because Medicare is a federal program, there is a lot of documentation involved that needs to be changed annually as the legislation itself changes – even though there may be hundreds of thousands of documents, though, they’re all still unique and need to be created one at a time by a combination of individuals.

The Enterprise Level

PDFs created at the enterprise level are generally personalized customer communications automatically generated by an application, typically within the IT department – each one is not individually created by a person. These types of documents include credit card and bank statements, telecommunications billing, tax notices, medical explanation of benefits, etc. What defines all of these is that there may be millions of personalized individual documents, but they’re all created from a single template. So while each document contains individual personal data, they all look very similar in structure, and it’s not a single person – or even a group of people – who inserts that data. Rather, it’s done automatically, using a document composition engine. A template is generally created one at a time by an individual or group of individuals, then the engine automatically pushes the data through that template to put out these documents at the scale and speed that’s required.

Accessibility Options

When it comes to considering accessibility for documents, PDFs created at the desktop level will generally need to be tagged manually. This is the traditional path to accessibility and currently there isn’t technology available that addresses automation of these ad hoc documents in scale and with reliability – meaning not needing manual re-touch of the tag structure. For those created at the enterprise level, though, automated solutions like the Actuate Document Accessibility Appliance exist that do just that – automating the remediation of high volumes of PDFs able to meet WCAG 2.0 Level AA and Section 508 standards without the need for manual tagging or tag re-touch. The Actuate Document Accessibility Appliance is designed for high-volumes of documents created by a document composition engine at the enterprise level and output as PDF. The Accessibility Appliance allows for the creation of highly intelligent templates, again at the enterprise level, building in the accessibility rules for tagging that will get incorporated into the PDF post creation, i.e. automated remediation. This can happen in batch or in real time on demand, making them accessible to visually impaired customers and the screen reader technology they use to access, navigate, and fully consume digital documents.

In the case for these high volume generated documents, manual tagging is all but impossible. There are often millions, hundreds of millions or more of individual documents to consider, so the only way to manage accessibility without an automated solution is through an exception process. This process would require visually impaired customers to self-identify as disabled and deal with delayed delivery times while their document is remediated manually. The exception process often doesn’t scale either due to the sheer volume, and forces companies to hire and train full time internal resources or hire expert vendors, often costing $5 to $35 per document page. The Actuate Document Accessibility Appliance helps get around that – allowing for all customers, with and without disabilities, to have access to fully accessible documents on demand, especially medical and financial communications equally at the same time.

If you still have any further questions, please leave them in the comments section below, or contact me at skelly@actuate.com .

Q&A at CSUN 2014: Learning More About the Actuate Document Accessibility Appliance

Reduce risk, save time, save moneyIn March, I had the pleasure of attending the Annual International Technology & Persons with Disabilities Conference, hosted by California State University, Northridge (CSUN). The high-profile annual conference, now approaching its 30th year, showcases technologies designed for people with disabilities, with attendees coming from all over. Many of those attendees represent organizations looking for accessibility solutions for high-volume, e-delivered PDF customer communications, which meant it was the perfect place to talk about the Actuate Document Accessibility Appliance.

I presented twice at the event (here you can find the slides of my presentations), and received several questions about Actuate’s PDF accessibility technology: what kind of documents it’s designed for, what kind of companies it suits best, and the best use cases for using it to create accessible high-volume documents. I wanted to use this blog post to share two of those questions, which together represent some of the common queries Actuate receives about its Document Accessibility Appliance.

Is Actuate’s software product available for smaller organizations and agencies or is it only suitable for large ones?

The short answer to this is yes – the Actuate Document Accessibility Appliance is available for smaller organizations and agencies. In fact, it was the high demand for the product from organizations of all sizes that inspired Actuate to offer it as an appliance in the first place. Now, no matter what type of organization you represent, Actuate is able to meet your needs, creating accessible high-volume customer communication PDFs (such as billing statements, notices, etc.), in batch or in real time on demand.  The appliance runs in a virtual environment and is pre-packaged with essentially everything you need to quickly and easily convert your print streams or PDFs into standards compliant Accessible PDFs.

For more information on exactly how the appliance works, watch this introductory video: Actuate Document Accessibility Appliance – Business Value.

Does the Actuate Document Accessibility Appliance work for creating PDF forms?

This question has another short answer – in this case, though, that answer is sometimes. The Document Accessibility Appliance isn’t meant for the creation of fillable forms with active user control fields.  The simple reason is that a fillable form is created one time and designed for that single form to be used many times, but again it’s created only once. You can distribute it to 10 different people or a million different people, and they may each enter different information in the fillable fields provided, but it’s still the same form every time. In this case, companies are better off using the traditional manual tagging and remediation efforts to create their accessible, fillable forms.

Actuate’s technology, on the other hand, is designed for high-volume documents produced at the enterprise level – again, bills, notices and statements, , that may have millions of iterations, with standard templates but unique personal data incorporated into each, like for example a bank statement or a health explanation of benefits. That’s the key differentiator and what Actuate’s accessibility technology was designed for.

However, a company may have a database full of static forms, which would be a good use case for the Accessibility Appliance.  If the forms are static, meaning the form fields have already been populated and the form has been output as a PDF, for example, and the objective is to remediate the entire database of static PDF forms to Accessible PDF – then absolutely, the Appliance is a great fit.  The key here is the form documents would have a similar structure but the once active user control fields were populated with unique data, the document was then output to a PDF and the form fields are no longer active.  Potentially resulting in a high volume of documents with similar structure where each also contains unique information.  Actuate’s Accessibility Appliance is a great solution for this scenario with the ability to automate the remediation process, delivering quickly and easily standards compliant Accessible PDFs.

If you have any other questions about the Actuate Document Accessibility Appliance, please feel free to ask in the Comments section or contact me on LinkedIn.

Europe Adopts Accessibility Standards for Public Sector Web Content

Post was first published on Media Access Australia’s AccessIQ.

In February, 2014, the global accessibility movement took a big step forward when the European Parliament approved an important directive on web accessibility.

The new directive defines accessibility targets for the websites of public sector organizations and private sector organizations delivering “public” services such as utilities, healthcare, transportation, telecommunications, and banking. Under the directive, affected organizations must implement accessible websites that comply with WCAG 2.0 Conformance Level AA.

According to the phase-in schedule, new website content, including not just web pages but all content on the site such as PDF documents, must be fully accessible to the WCAG standards within a year, existing content must be retrofitted for accessibility within three years, and live audio must be accessible within five years. It’s up to the EU’s twenty-eight Member States to follow through with appropriate legislation that will achieve these goals.

Twenty-one member states, including France, Spain, Germany, Netherlands, Italy, and the UK, already have web accessibility standards in place. Despite this apparent widespread adoption of accessibility standards, the EU estimates that only one third of the 761,600 public sector websites in Europe are currently accessible (hence the need for a directive).

Keep in mind that, in this context, the term “website” refers to all online content including PDF documents. PDF documents can typically be divided up into two broad categories:

  • Low volume
    “One-off” content such as ad hoc documents (e.g., brochures, collateral and other create once – use many type documents),
  • High volume
    Personalized e-delivered communications such as statements, notices, invoices, and other account and benefit information communicated in PDF on a regular basis.

When it comes to high-volume e-delivered communications, European organizations need to prepare now for potential legislation that would enforce this directive. With legislation, these agencies and businesses are likely to find themselves all in the same boat: challenged to find a way to address accessibility for the onerous PDF. 

While manual tagging and remediation of PDFs is the traditional path to accessibility, this process just doesn’t scale for many of the organizations that may become affected by this directive. Public sector is notorious for lots of notices and statements like health and tax type documents and those private sector companies delivering public services such as utilities, telecom, and banking will all have statements, bills, etc.

The real issue here is the sheer volume and number of these types of documents generated on an ongoing basis. For example, if a company has 100,000 customers and each document for that customer averages 3 pages, that’s 300,000 pages that would need to be delivered in accessible PDF every billing cycle – say monthly. Now factor in that manually tagging a single page PDF can take anywhere between 10 minutes and sometimes hours, depending on the level of complexity – and usually these types of PDF communications are laden with lots of tables which are the most complex to manually remediate. On the conservative side that’s 50,000 hours of labor – and that’s not just 50,000 hours, but its 50,000 hours every month!

The point here is that manually tagging the documents for accessibility is a laborious effort that is cost and time prohibitive. Typically organizations cannot find a service bureau to assist with such scale of manual document remediation services that has the resources to handle thousands, hundreds of thousands, millions or hundreds of millions of pages every month.

As consumers and businesses both are reliant on technology and the web as the de facto standard for doing businesses, these organizations may soon no longer have the luxury of simply making an “accommodation” for those who request an accessible format. This new directive is expected to spawn legislation that ultimately may have an impact on all websites that offer their customers access to their notices, statements, and bills online. This is something European governments and businesses need to begin proactively preparing and planning for.

I suspect that we may even begin to see committees and other groups emerging in Europe to draw people together in the industry to help solve web accessibility issues, similar to the Australian Web Industry Association (AWIA) and the Australian Government Information Management Office (AGIMO) which has integrated accessibility more closely with the Australian government.

In the United States, spawning from the 1998 (effective in 2001) introduction of Section 508 of the Rehabilitation Act which set accessibility standards and compliance for the US Federal Government for electronic and information technology, we now have a multitude of public organizations (banks, telcos, and insurance mostly) with large, dedicated internal accessibility practices along with most universities, state governments  inasmuch as the federal government agencies for whom the regulations directly affected. Web accessibility has become the new normal.

Meanwhile, and considering that the PDF format isn’t going to go away, and doing business relying on the web isn’t either, it seems these organizations have some research to do. My suggestion is to start researching now, seek out and test some of the enterprise-based technology solutions hitting the market today that automate both the generation of and the remediation of these very high-volume PDF communications.

CSUN: Presenting PDF Accessibility at the Annual International Technology and Persons with Disabilities Conference

“PDF/UA makes certain that the PDF format isn’t the source of accessibility problems.”

It’s a quote I use sometimes in my presentations on the PDF/UA format, sourced originally from a blog post by Matt May, Adobe’s Accessibility Evangelist. I saw May again at the Annual International Technology & Persons with Disabilities Conference, hosted by California State University, Northridge (CSUN). I’d originally quoted him during a different conference presentation back in January in Orlando, Florida, so imagine my surprise when the then stranger approached me afterwards and introduced himself!

It was just one of many surprises and unique experiences at the CSUN conference, hosted in San Diego, CA in March. The 29th annual event was dedicated to technologies for people with disabilities, and among the attendees were representatives of organizations looking to find accessibility solutions for high-volume, e-delivered PDF customer communications. With more and more companies offering those documents online, making them accessible to visually impaired and blind customers has become more important than ever – but they want to be able to offer these accessible documents in a way that’s convenient and not cost prohibitive too.

To inform them of their options and discuss some of the solutions for accessibility compliance around PDFs, I presented twice during CSUN. The first presentation – PDF/UA: What Is It? Why Is It Relevant– looked at the PDF/UA format. UA, in this case, stands for Universal Accessibility, and references a PDF file format based on international standards for PDF accessibility. These are technical standards, not best practices, which define how to represent PDF in a manner that allows the file to be accessible. Included are code-level requirements for developers to allow for compatibility across the document content, the reader that displays it (like Adobe Acrobat Reader) and the assistive technology such as screen reader JAWS often used by the blind and visually impaired to access the document. “That does not mean that a PDF/UA-compliant document will always be perfectly accessible – issues like poorly-built Word documents or other source material will, of course, carry their accessibility flaws no matter what format they’re converted into,” Matt May pointed out in his blog (another quote of his I sometimes use in my presentations), but it does help ensure the access to, navigation of and full usability of a PDF for the visually impaired.

The second of my presentations was called PDF Documents: Regulations, Risks, and Solutions for Compliancewhich I co-presented with Paul Schroeder and Darren Burton from the American Foundation for the Blind. It took a bigger picture view of PDF accessibility, lookingat the concerns large private companies and government agencies are facing when it comes to creating accessible, high-volume PDF communications. Specifically the lawsuits they’re finding themselves in the midst of, and the structured negotiations and settlements being put together behind the scenes – all of which are adding to their heightened awareness regarding web and web content accessibility issues. The session was packed with people – in fact, it ended up being standing room only – looking to find out what they could do about this new frontier of accessibility. Many didn’t even know that a solution now exists that can automate the conversion of high-volume non-accessible PDFs to fully accessible and standards-compliant PDF documents without the need for costly manual remediation, making the job much easier.

I hope the attendees at the presentations found it informative and useful. For me, as usual, CSUN was a hit, filled with great people and interesting learning experiences. Once again, I was excited to be part of it!

View the videos of my CSUN presentations.

PDF/UA Format and the Annual Assistive Technology Industry Association Conference

Back in January, I was honored to be able to present at the Assistive Technology Industry Association (ATIA) conference in Orlando. The conference has taken place annually since 1999 and focuses on assistive technology education. Geared primarily towards the user community, it showcases the range of assistive technologies currently available, with an extensive list of sessions, all designed to keep attendees informed on the latest and greatest.

For my own session – PDF/UA: What Is It? Why Is It Relevant? – I focused on the newest PDF file format PDF/UA – universally accessible. Developed to define how to represent PDFs in a manner that allows for accessibility, the PDF/UA format is based on international standards and is designed to be compatible with screen readers such as JAWS and other assistive technologies.

My presentation offered an overview of the PDF/UA format and looked at the challenges organizations face today in creating accessible online content, including high-volume digital PDF communications such as financial and health statements, bills, and notices. These documents pose a particular challenge for many organizations and can be difficult to manually tag for accessibility and most often are cost and time-prohibitive because of that. But finding a way to make those documents accessible has shot up to the top of companies’ priority lists because of regulations and legislation like Section 508 of the Rehabilitation Act and the Americans with Disabilities Act – as well as with the expensive lawsuits and settlement agreements that companies have found themselves faced with more and more. That means those organizations need to find a way to make those digital documents accessible, in keeping with the World Wide Web Consortium’s (WC3) list of universally spanning standards for web accessibility, stated in the Web Content Accessibility Guidelines (WCAG). While this is a standard, not a regulation, most accessibility requirements, standards and laws have been normalizing WCAG 2.0 at AA conformance levels.

Truly accessible documents contain proper tagging, markups and structures as defined by the PDF/UA standards, and are compatible with assistive technology, allowing everyone to access and navigate the document fully. They are barrier-free to people with or without disabilities and are WCAG 2.O, Level AA compliant.

My session at ATIA covered all of this and saw a range of attendees, including users of assistive technologies as well as representatives of organizations that want to better understand document accessibility and options for meeting compliance with these high-volume documents. Not only was the turnout great, but the questions I received were just as interesting. A lot revolved around specific PDF elements, or how the PDF/UA standard applied in certain document situations (for instance, in the case of multiple nested headers), while others questioned if the PDF/UA was a guideline they could follow for making their PDFs accessible. My session covered the explanation that the PDF/UA standards (ISO 14289-1) include code-level requirements for more geared for developers addressing compatibility across the document content, the reader that displays it (like Adobe Acrobat Reader) and  the assistive technologies, like screen readers used by the blind and visually impaired to access the document.  But the biggest questions related to how to address the challenges of manually creating an accessible document. Many of the attendees didn’t even know that there’s technology available now that allows for the automated creation of accessible PDFs, specifically, high-volume e-delivered customer communications.

Even though the sheer volume of these high-volume digital communications make them a particular challenge for companies, the PDF/UA document format provides a technical structure allowing for the automation of these documents with the right technology. That was good news for most of the attendees I saw at my presentation, who are looking for the right solutions to help them with their accessibility needs.

Click to view the presentation “PDF/UA: What Is It? Why Is It Relevant, from ATIA.

Accessibility and Health Insurers: What Section 508 and ADA Legislation Mean For Health, Medicaid and Medicare Insurance Organizations

More than ever, health insurance organizations – including Medicare and Medicaid programs – are tackling the issue of online accessibility, including accessible online PDFs. They have to: they face financial penalties and the risk of losing government contracts if they don’t.
Two separate concerns have created this emerging demand: 

1. Like federal government agencies, private health insurers are looking for ways to comply with Section 508 of the Rehabilitation Act. Since these private organizations have contracted with the federal government (Centers for Medicare and Medicaid Services) to offer the Medicare and Medicaid programs, access to the program must meet this federal regulation. The regulation requires they ensure access to and use of their websites and digital documentation to people with disabilities, including the blind or visually impaired who use screen reader software to visit the web and read their electronic documents. Non-compliance could lead to the loss of lucrative contracts for insurers.

2. The Americans with Disabilities Act (ADA) legislates accessibility in the United States, and currently this legislation doesn’t mention web and web content accessibility specifically, although that may be about to change. Since the 1990s, disabled plaintiffs have triumphed in many structured negotiations, agreements and lawsuits against large private organizations that did not make their website and web content accessible to them. The rulings have generally fallen under the ADA’s Title III which defines “places of public accommodations”. Judges have agreed in these lawsuits that websites and its content are indeed an extension of a brick and mortar business, a public accommodation, for those organizations otherwise required to comply with the ADA. That risk of litigation is likely to increase if a proposal by the Civil Rights Division of the Department of Justice (DOJ) goes through, asking for an amendment to Title III to update the definition of “places of public accommodation” to definitively include websites and online information. To avoid the potential threat of large settlements, health insurers need to begin implementing measures to make their digital information and communications accessible.

Ensuring compliance for both Section 508 and the ADA means not only creating accessible core content, but making sure that all online PDF documents are also accessible. That includes the thousands of informational PDF documents and collaterals typically associated with Medicare and Medicaid programs on an insurers’ websites, but also includes a more onerous category of PDFs; the e-delivered communications like statements and notices such as billing statements, EOBs (Explanation of Benefits) SBs (Summary of Benefits), etc. Why are these documents such an onerous challenge to make accessible? Traditionally, making PDFs accessible requires a manual tagging approach. Even when a document is created with accessibility in mind and converted to a tagged PDF, those tags still often need to be manually adjusted in order to give a screen reader user full navigation and usability of the document. This is a labor intensive process that can be time and cost prohibitive at high volumes. Since insurers are generating these statements and notices for thousands or even millions of members every month, the page counts can be in the millions, hundreds of millions or even billions, making a manual process simply not scalable.

That’s all changed now, though. New technology exists that can convert these high-volume e-delivered PDF communications on the fly, meeting the Web Content Accessibility Guideline standards (WCAG 2.0 Level AA) and making them accessible to visually impaired customers on demand. By negating the need for manual PDF remediation, this makes creating accessible statements and notices obtainable. Plus it’s more cost effective and far less time consuming, converting a single statement in milliseconds. Now the insurer’s visually impaired customers no longer have to wait for their accessible version, a traditional frustration for those customers who were given less time to make critical health and financial decisions based on information in the documents.

The issue of website and online document accessibility isn’t going to go away for health insurers. To keep contracts and avoid risks of penalties, fines, lawsuits, and brand damage – while ensuring comparable access and opportunity for their blind and visually impaired customers – they’ll need to comply. The right plan of action, with accessibility technology in place, can help them do so.

Are you a health, Medicare or Medicaid insurer? How could new PDF accessibility technology help you strategize your compliance plan moving forward? Offer your thoughts in the comments section below.

Interview with Media Access Australia: What is PDF/UA and Why it is Important

CSUNPresentationFirst published on Media Access Australia’s Access iQ.

I spoke with Tim Lohman from Media Access Australia’s Access iQ about document accessibility and the PDF/UA standard before my presentation at CSUN International Technology & Persons with Disabilities Conference this past week.

Check out our interview below:

Access iQ (AiQ): What is PDF/UA and why is it important?

Shannon Kelly (SK): PDF/UA is an ISO (International Standards Organisation) standard (14289-1) for the Portable Document Format (PDF) aimed at making PDFs universally accessible (UA). It is a technical standard at the code level giving requirements for how you implement code for PDF readers like Adobe Acrobat, PDF writers like Word, as well as assistive technologies like JAWS. What PDF/UA is not, is a set of best practices. What ends up happening a lot of times is that, if a content author outputs their content to the PDF/UA format; they think that it is automatically converted into an accessible document. That is not true. Matt May from Adobe did a blog on this last summer and he said that the PDF/UA format isn’t the source of accessibility problems, which was true.

AiQ: What were the challenges with accessible documents that led to PDF/UA’s creation?

SK: The biggest challenge was that there were no clear standards for the conversion of native source documents into accessible, tagged PDFs. People may have thought that by clicking a button in Microsoft Word or Adobe InDesign to convert to PDF with an automatic tagging process, that they were creating an accessible PDF. However, unless the native source document was created with accessibility in mind and the document, once converted to PDF, then had the tag structure retouched and manipulated by an editing tool such as Adobe Acrobat Professional, the result was generally a tagged, but poorly navigable or usable document to a blind or visually impaired person using an assistive device such as a screen reader.   Without a  set of technical requirements that address the content (such as from a Word document) being converted, the reader will access the content (such as Adobe Reader) and the compatibility with assistive technologies like screen readers, the result was typically very inconsistent PDF output of auto-tagged documents often with illogical semantics and mark-up. That really resulted in a lack of usability by the screen readers’ users. So what you had was the proliferation of poorly accessible or completely inaccessible PDFs on the web. The case with inaccessible and poorly accessible documents is that, not only do they not serve the community of the blind and visually impaired, but they also do not serve the needs of the general population in the way we have become accustom to accessing data via text search, copy and paste functions, etc.

AiQ: You said earlier that even with the PDF/UA standard that there are still accessibility issues. Are there techniques people can use to avoid these?

SK:  Absolutely. When creating a Word document, ensure that you design the document with accessibility in mind. As an example, the document author would utilise the Table function in Word to create a table, or using the List function to create a list, as opposed to using only tabs and character symbols to create an ad hoc table or list. You can also make sure to define the text using the style formatter for both headings and body, because a heading format in word will translate to a specific heading tag in the PDF/UA. A list properly using the List format in Word will also translate to the proper list tags in PDF/UA. For non-text elements, such as images, you should be certain to provide alternative text descriptions with those images in your Word document. Additionally, you’ll want to use a standard font that conforms to accessibility guidelines such as Arial, Times New Roman, Tahoma, Helvetica or Calibri and also be certain to populate the document properties, as well.

AiQ: Beyond being the right thing to do, are there other reasons businesses and government agencies should be actively producing accessible documents?

SK: Yes, because it is the right thing to do, and government agencies and businesses in many countries are required to conform to regulations, legislation, and accessibility standards for their web and web content including their PDF documents. Today these organisations are pushing the customers toward self-service via the web — governments, telecommunications, healthcare, utilities, insurance providers and banks, for example. That means that access to those kinds of services and e-delivered communications like bills, statements, notices, healthcare information, and banking and financial statements must be made accessible to everyone. There are guidelines, such as the Web Content Accessibility Guidelines (WCAG) 2.0, which provides a globally accepted and adopted set of guidelines for accessibility regarding web and web content. Those standards have been adopted now in 17 countries and they offer organisations very specific techniques for making their content — including all PDF documents — available in an accessible and usable fashion.

I’d also point out that, even with the increased use of HTML, the PDF standard is not going away. It will remain the vehicle for organisations to present their data online. The PDF format in some industries is the required archive format to preserve the original document of record. Additionally, most all major financial and insurance organisations have sophisticated enterprise technology that converts into PDF formats massive amounts of data from millions and millions of customers into their statements every month – the larger challenge with accessibility here is the sheer volume, repetition and scale of this PDFs. The PDF format is critical in moving toward universal accessibility.

AiQ: What barriers exist today in making documents more accessible?

SK: Formerly, the only way to make a document accessible was to design it with accessibility in mind, convert it to a PDF format and then open it in an application like Adobe Acrobat Pro and manually tweak those accessibility tags. So the challenge is that this a time-consuming process for an organisation’s one-to-many documents – things like annual reports, marketing collateral etc. But for businesses and government agencies, how can you do that for thousands, millions or tens of millions of documents – such as bills and statements — that you have to e-deliver in PDF form every month? We would argue that you need an automated enterprise-level technology solution like the Actuate PDF Accessibility Solution, which allows these organisations to easily produce accessible documents in high volumes which meet WCAG 2.0 level AA compliance. The advent of the PDF/UA format has enabled the development of this patented new technology that is truly a “game-changer” in the world of high volume, e-delivered customer communication PDFs.

Reflections on PDF Document Accessibility Events

What Matters for Our Communities Moving Forward

ShannonKellyPresentingNCConcerned by the possibility of litigation and inspired by emerging technology, interest in PDF accessibility has soared as companies look for new ways to make their online customer communications, statements and bills accessible to blind and reading impaired customers. This is a particular challenge for businesses using technology to convert enormous storehouses of data into print streams for traditional printed statements and into PDF for e-delivered statements, because moving to HTML often is not an option. To feed the interest in PDF and answer at least some of the questions that are out there, Actuate – a provider of patented high-volume PDF accessibility technology – has launched an ongoing series of events meant to keep the business community informed and to assist companies as they face the challenges of creating accessible and fully usable high-volume customer communications. It continues to be a great experience for me to be a part of these events, and there are many takeaways to share as we receive questions and feedback from business leaders from all over the US and Canada.

So far, the Document Accessibility educational events have included:

A webinar series co-hosted with one of our consulting partners, SSB Bart Group, which has helped more than 1,000 organizations with their accessibility initiatives. This webinar series covers all aspects of document accessibility and ran between September and October 2013.

A Document Accessibility Seminar series. Hosted so far in Toronto, Canada, and Charlotte, NC, these seminars are designed to answer some of the questions that exist around accessible PDFs, looking at industry guidelines and legislative requirements and how to best address them. Two more seminar sessions are planned in New York and Washington, D.C. in Spring and Summer 2014.

Hosting these events has put me in touch with many people from private and public sectors, at different stages of trying to introduce the concept of inclusionary practices when it comes to implementing accessible public-facing and e-delivered communications and documents within their organizations. Speaking to them has given me even more insight into the questions and challenges that exist in this realm and the information people are searching for. To help business leaders meet their information needs, I will continue answering questions and sharing feedback from the field on this blog.

The first group of blog posts responded to the inquiries I encountered during and after the webinar series. I was asked for more detail about low and high-volume documents and the differences between them when it comes to accessibility. That led to the post, Not All Documents are Created Equal, which outlines the difference between the two, starting from the way they are authored and continuing through to how they’re updated and the tools that are needed to make them accessible. Four Challenges of Making Credit Card Statements Accessible continues along the same theme, looking at the challenges companies face in making their high-volume customer communications accessible. Not all visually impaired customers want to self-identify as ‘disabled’, and they don’t want to have to wait long periods of time for their statements to be converted into accessible formats either. This has become a focal point of the challenge since most of those who use assistive technology (such as screen readers) rely on this technology and often prefer accessible electronic documents over other traditional formats such as Braille. An additional obstacle is manually tagging documents for accessibility which can be both time and cost-prohibitive, particularly for organizations such as financial institutions which serve millions of customers. These are just a few of the obstacles and challenges companies are facing today when trying to meet industry regulations, legislation, as well as the demands from their visually disabled customer base.

The feedback received from the seminar series so far has proven to be interesting since seminar participants also felt the need to write a couple of posts in response to some of the inquiries we received. After the Toronto seminar, Doug Koppenhofer, Actuate’s VP Global Sales and a guest on my blog, posted Embracing Accessible PDF Documents: Key Learnings from the Accessibility Seminar in Toronto. At this event, I spoke alongside Lou Fioritto – co-owner and Vice President of BrailleWorks and blind since birth – who demonstrated the difference between correctly and incorrectly tagged PDF files, and showcased some of the problems that have existed with poorly tagged PDFs in the past. Expected changes to legislation related to accessibility were also considered.

Finally, after the seminar in Charlotte, NC, Doug posted Full House at Charlotte Document Accessibility Seminar to discuss some of the findings that came up there, including some of the great questions and interesting points that emerged during the Q&A session. Questions addressed at the seminar covered areas such as editing accessible documents, what happens to accessibility if tagging is altered and how to address dynamic content that changes within a template, like a bank statement.

These aren’t the only events I will be attending – this continues to be an extremely important topic, most familiar to US federal government where legislation such as Section 508 of the Rehabilitation Act has been bringing about accessibility changes for over a decade. However, many large organizations are beginning to take accessible web and web content very seriously, particularly with all the recent lawsuits and settlements, and now with changes to legislation such as the imminent Title III amendment under the ADA, new questions are surfacing on how to utilize technology to meet the demands. Actuate’s experts are planning more events in the future to educate the business community and help address the challenges they are facing. I’ll post details here when those events are planned, as well as any news on changes to legislation and updates in the field of accessible PDFs.

To find out more about the Document Accessibility Seminar series, view our presentations from Toronto here.

Post first published on G3ict.org.

Update on AODA for Document Accessibility

Guest blogger contribution by Doug Koppenhofer. First published on ECM Trends from the Field. 

AODAComplianceWe’ve been asked to comment on a whirlwind of activity around AODA or the Accessibility for Ontarians with Disabilities Act. 

In our Fall Document Accessibility Seminar series, we learned that AODA has very specific timelines in place that mandate specific compliance for organizations with over 50 employees. One of the early deadlines just passed, January 1, 2014. By this time, organizations must be WCAG 2.0 Level A compliant and have an accessibility plan outlined and documented. AA compliance accrues to a future date.

This is having some specific impact on organizations which have not put a plan in place, and notably, one of the largest property & casualty insurers in North America recently sent out  a notice to all Ontarian customers informing them that:

“Due to technical limitations, starting December 8th 2013, most or possibly all documents you view online will no longer be available. Unfortunately, this is a necessary step as we improve the overall accessibility of our site.”

In the age of online customer service in which virtually all organizations not only have extensive website service channels, they actually use the website to reduce more expensive call center traffic. The impact in terms of brand damage and sheer cost we know is huge.

This is completely avoidable. The technology exists to quickly remediate websites, but even beyond that, there is now readily available technology to remediate high volume documents, including insurance documents, insurance cards, policies, bills, notices, claim letters, and the like.

Don’t let this happen! Email me if you would like to attend an Actuate webinar or seminar on document accessibility and find out what you can do!