Attending the Web Accessibility Day

Earth lighted up from withinOne Day in Maryland

Companies around the globe are looking to make their web content accessible for the visually impaired. But they want to do so in the most efficient, knowledge-based way they can, so that they don’t make mistakes and waste needless funds in the process. To do that, they need the right information.

With this in mind, the National Federation of the Blind’s Center of Excellence, along with the Maryland Technology Assistance Program, hosted a Web Accessibility Day in September. Held in Baltimore, Maryland, it was designed for both private and public organizations, with the goal of informing them on policy and technical innovations, and discussing the issues related to web accessibility today.

Actuate was invited to present at the training day, giving me the chance to experience the event from two perspectives: as an attendee, gleaning knowledge from the other presenters, and as a presenter myself, experiencing the reactions attendees had to Actuate’s own PDF accessibility technology. It ended up being a great day, and I wanted to share my experiences and insights from it here.

Panels and Policy Presenters

One of the first presentations of the day was “The Natural Outcome of Innovation and Inclusive Business,” by Eve Hill from the U.S. Department of Justice. Eve discussed what the Department of Justice has done and is continuing to do to influence accessible web environments. She wasn’t the only government representative at the event, either – in the afternoon’s policy-based sessions, representatives from the Department of Homeland Security and the Maryland State Board of Elections presented, as did Timothy Creagan from the U.S. Access Board, who offered an overview of the on Section 508 refresh.

Directly following Eve’s presentation, though, were two panels – one dedicated to “Enterprise Implementation of Accessibility” and another to “Education Implementation of Accessibility.” Both were informative, but the first was especially interesting, featuring among other panelists a representative from the retailer Target. Target faced its own NFB-led lawsuit back in 2006, but now they are a poster child of what companies can do to get web accessibility right. Today, they’re not only addressing accessibility in terms of their web content, and are blazing the trails on mobile technology – all while collaborating with the NFB all the way, Talk about making lemons into lemonade. Hopefully more companies can learn from their lead.

Talking Tech

While the morning sessions were underway, a select group of vendors were invited to set up tables at the back of the room, so that attendees could come over during breaks to find out more about the technology and resources available around accessible web content. Actuate was there, as was Knowbility, a non-profit group dedicated to improving technology access for people with disabilities; Ai Squared was showcasing their ZoomText magnification and screen reading software; SSB Bart, an accessibility consulting group, was available for questions; NetCentric Technologies was highlighting what’s new with their CommonLook product and the Bureau of Internet Accessibility (BOIA), which focuses on website testing for accessibility, was demonstrating their tool as well. Between sessions, attendees approached the tables, getting any information they needed on the resources available to them.

We had great interest from attendees there, and even more when I presented later on during the afternoon’s technical sessions, which also featured representatives from Deque Systems and Google. I was excited by the amount of response my presentation – “PDF Accessibility in an Enterprise Setting” – garnered, with great detailed questions from the audience centered around best practices for alt text. I was surprised to see how many people attended this session from the publishing industry and higher education – both seeking accessibility solutions for high volumes of documents and content. It’s clear that government and private companies alike are aware of the importance of accessibility – and are looking for solutions to help them along the way. And for the visually impaired community, that’s a great start.

Accessibility Meets Mobility: Review of M-Enabling Summit 2014

First published on G3ict.

I attended the third edition of the M-Enabling Summit on Accessible Mobile Technology for Seniors and Users of All Abilities, this year in Washington, D.C. Here is my quick review of the event highlights.

How important is mobile technology?

To answer that, you need to consider not only the mobile usage of your friends and colleagues – who, if they’re anything like mine, probably pull out their smart phones and tablets every chance they get – but also the usage of mobile technology around the world. That includes developing countries and rural areas, where the placement of cellular service towers and affordable mobile devices have given even remote and underdeveloped communities access to goods and services via the internet. This global access has opened up commerce for a market that now reaches all corners of the world.

Mobile technology has become incredibly important from both a social and commercial perspective – ensuring more widespread access to services, information and products. But its new prevalence also highlights the importance of making the technology accessible to everyone – including seniors and individuals with disabilities, particularly visual and hearing impairments.

It’s with that in mind that in June this year, I attended the 3rd annual M-Enabling Summit in Washington, DC(check out event proceedings).

Enabling Everyone
Focused on “accessible mobile technology for senior citizens and users of all abilities,” the M-Enabling Summit this year featured discussions on everything from social media and web search accessibility, to mobile accessibility as it relates to commerce. Accessibility on the mobile front is an area Actuate is interested in examining further, so I went hoping to learn more about trends in the field. I wasn’t the only one either: a who’s who of the accessibility thought leaders attended, coming from both the private and public arenas – including representatives from the big telcos and cable providers, and financial institutions and – the likes of AT&T, T-Mobile, Sprint, Verizon, Comcast, JP Morgan Chase, Wells Fargo and Scotia Bank; Technology leaders Adobe, Microsoft, Yahoo, and IBM were onboard, as were several federal government agencies and non-profit disability advocacy groups. For a conference with an estimated 500 attendees, it was certainly a highly concentrated and focused accessibility group!

So, why this focused accessibility attention on mobile technology? After all, a significant segment of potential mobile customers have disabilities, including those with low or no vision. In fact, according to the World Health Organizationapproximately 285 million people around the world are estimated to be visually impaired – of those,  90% live in developing countries, where mobile devices may be their only way of participating in online commerce. Approximately 82% are 50 or older, meaning seniors also have a vested interest. Those customers don’t want to have to rely on someone else looking over their shoulder, having access to and reading their personal information. They want solutions that enable them to get information independently. And they want to – and have the right to – participate in commerce and make payments on their phones and tablets the same as everyone else does.

One of the sessions I attended at the summit – called Making Mobile Payments Accessible – examined just that. The panelists estimated that within five years mobile payments are likely to become as prevalent as GPS mapping or taking photos with your phone. Building accessible but mobile commerce options, then, is more important than ever.

Summit Highlights 
The event didn’t disappoint. While the session on mobile payments was one of key interest to me, I also sat in on several others. Another was Integrating Accessible Mobile Solutions in the Workplace: Challenges and Opportunities for CIOs, which looked at how CIOs can integrate accessible mobile platforms into the workplace, to include and enhance the productivity of their employees with disabilities. What Corporations Need to Know About Mobile Accessibility Compliance: Latest Rules for the Implementation of the 21st Century Communications and Video Accessibility Act, meanwhile, examined new regulatory developments regarding the accessibility of mobile devices and services – and how those changes may affect corporations of all stripes.

It was an informative two days that broadened my knowledge of mobile accessibility, and that will hopefully help influence Actuate’s own accessibility efforts going forward. In fact, it may have been my first time attending the M-Enabling Summit, but it definitely won’t be my last. It’s an important, ever-changing field, and I can’t wait to see how it develops!

Accessibility on All Fronts: Creating Accessible Web Content

Accessibility for everyoneHow are companies today faring when it comes to creating accessible environments for their customers?

The answer is more complicated than you might think. Because if you visit a modern office building, or even take a look at corporate websites, accessibility has obviously become a key ingredient for most businesses today. Companies want all of their customers to be able to reach them, whether that means adding wheelchair ramps to their offices, or accessibility tags to their websites. Those that don’t make the efforts have quickly found that there are hefty legal repercussions and lawsuits waiting for them if they don’t comply.

But to truly be able to access services, information, etc., individuals with disabilities must have a comparable opportunity to go everywhere customers without disabilities can. And that means businesses need more than wheelchair ramps and accessible websites – they need accessible web content as well.

I wrote about exactly this issue in a recent article for Business Solutions magazine, entitled “Creating Fully Accessible Web Content: The Industrial Approach.” The article looked at the changing face of accessible content – from a time when companies required the visually impaired to identify themselves as disabled, and then wait for content to be sent to them in accessible paper formats like Braille, to now, when the visually impaired require and demand immediately  available online content, just like everybody else. To stay compliant – and to keep all of their customers happy – companies need to build new options into all of their online content, including PDF statements, account notices and bills.

For that to become the norm, though, companies need to embrace technology, specifically automation.  They need a technology that’s scalable to their customers’ needs—because building accessibility into these PDF documents manually is too cost and time intensive and simply cannot provide an equivalent or even comparable experience. That means introducing automation with intelligence to maintain standards compliant accessibility rules and formats, to generate these statements, bills and notices accessibly on-demand so that they and readable and usable by those using screen readers.

It’s only once that content becomes easily accessible and usable that companies start to come close to true accessibility – and actual regulatory compliance. But they’ll be one step closer to something else, too: customer loyalty. And that can be a hard thing to find in today’s competitive environment.

If you want to know more about creating accessible web content, read my original article published by Business Solutions Magazine.

Accessible PDFs: Questions, Thoughts and Ideas from a Social Network Exchange

First published on

Should accessible PDF documents be a part of a company’s web accessibility strategy? That’s the question that was posted recently in a LinkedIn web accessibility forum.

The question inspired a lengthy and exciting discussion among accessibility experts from a variety of sectors and roles. What resulted was an informative and multi-faceted conversation that brought up several questions, comments and solutions related to accessible PDFs.

To read the entire LinkedIn exchange, copy and paste this link into your browser:

For those who just want the quick highlights, I have consolidated a few of the more popular thread themes, questions and ideas that emerged.

PDF Document Accessibility
There was almost full consensus from accessibility experts on the fact that all online PDF documents should be made accessible. Within the LinkedIn discussion, a web accessibility consultant commented that since they’re likely available on a company’s public facing website or customer facing portals, PDFs should be part of a company’s overall web accessibility strategy. “It’s particularly important if that information isn’t available in another format that’s accessible,” a Section 508 accessibility and remediation specialist added. Others pointed out that some companies have gotten around creating accessible PDFs by making the same information available in an accessible HTML format instead.

Keep in mind that whatever the format, when approaching accessibility for what I call the ad-hoc or one-to-many type documents like marketing collateral, publications, informational documents, reports, etc., the approach typically is a manual one whether repairing, touching up or creating accessible PDFs. The key here is to author with accessibility in mind.

What about Archived PDFs?
I also saw a strand of comments regarding whether or not archived PDFs should be available in an accessible format. While many of the contributors in the discussion suggested that ideally they’d like to see historic PDFs made accessible, most saw the process of converting them as too time consuming and cost prohibitive, and in my opinion this is likely, because the traditional approach to making these documents accessible is a manual tagging and repair process that simply couldn’t be applied to such a large volume of archived PDFs.

One researcher in usability and accessibility pointed out that no one would ever look at those documents anyway, while a Section 508 accessibility and remediation specialist stated that converting them would depend on budget, timeliness and importance – otherwise, accessible archived documents could be made available upon request. My opinion here is multi-fold; firstly, whether or not someone would or could look at an archived document shouldn’t be the basis for the decision as to whether it is accessible or not. If the document is made available, it should be made available to everyone, including those with visual disabilities. Traditionally, there hasn’t been a solution that is timely or cost effective that would allow these archived documents to be addressed post-composition, but there is an automated solution on the market now that does just that and produces WCAG 2.0 Level AA compliant PDFs.

“Many companies are mandated – either by internal by-laws or external regulations – to store those historical PDF documents,” wrote my colleague from Actuate. For other companies, allowing customers to access historical documents (including statements or past invoices) may be a value-added service. “Whatever the reason for storing might be, if any time in the future that content needs to be accessed then it goes without saying that it should be accessible,” he added. “That doesn’t mean that organizations have to store the content in an accessible format for the lifespan of the document, but rather can employ a solution to automatically convert documents on-the-fly/on-demand.” This is very exciting since the solution mentioned here is a patented and fully deployed solution performing this very process for very large financial institutions today. It can and is being done!

What about PDF/A format for archived documents?
Many PDFs kept for historical purposes are stored in this format, a Section 508 assistant coordinator pointed out. PDF/A formats have a stricter structure that allows them to remain backward and forward compatible, he added. Could PDF/A formatting get in the way when it comes to accessibility? My colleague responds, “No, it didn’t “negate or hinder … capabilities to provide that content in an accessible format (meaning this format too would work for a solution that applies accessibility tagging or PDF remediation on demand) when the content is requested.” There are exceptions, of course – not every document can be made accessible post production, depending on how it’s been authored or formatted – but a large number can be, without the need to re-author them.

Accessible HTML Instead of PDFs?
A marketing communications consultant pointed out that HTML isn’t always appropriate. For example, it is not appropriate in the case of very long documents or for those that will be distributed mainly through print. A Section 508 assistant coordinator added that if it’s the PDF that’s going to be widely distributed, it should still be available in an accessible format.

I hear this HTML question posed to me frequently, and agree that in many cases HTML or XML is the best format when the content (code) is designed accessibly. HTML and XML typically pose less accessibility issues for assistive technologies like screen readers, particularly for web content. But what about the case of high-volume, electronically-delivered, customer communication documents, like bank statements, telco bills, medical notices, etc.? That is the question I pose and it is a leap for many to consider.

This content is usually presented as PDF and can quickly add up to millions of pages or even hundreds of millions of pages per month, per organization and is therefore in a different category of challenges, mostly due to sheer volume. The typical approach to making PDFs accessible is to design with accessibility in mind, convert to PDF, then check and touch up the PDF– which is the repair or remediation process – and it simply doesn’t fit or scale for statement type PDF documents. They’re also typically not available in HTML or XML, since PDFs are usually the format of choice and are often required for archival and regulatory compliance purposes.

Additionally, large organizations producing these types of communications have often invested heavily in their technology infrastructure with sophisticated software that transforms the data – like names, account numbers, marketing ads, etc. – into print files that get turned into paper communications and also into PDFs for online presentment. So providing accessible HTML/XML in this case may not be a solution. There is now a technology solution that works within the IT enterprises and allows for every PDF to be created completely accessible automatically (to WCAG 2.0 Level AA conformance), so now these companies can include all their e-delivered PDF communications as part of their overall web accessibility strategy.

That’s just a small sample of some of the discussions exchanged on LinkedIn around PDF accessibility as part of an oveall web accessibility strategy – along with a few of my opinions on the topics posed. Thank you to all who provided great insight into the accessibility issues with PDF. I hope we can continue to have more of these types of conversations on social media with lots of industry experts sharing their insights! Please connect with me on LinkedIn or via Twitter.

See more on PDF Accessibility:

» PDF accessibility using PDF/UA format: PDF/UA: What is it? Why is it relevant?

» PDF Association’s PDF/UA Competence Center

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

Accessible PDF: Enterprise Vs. Desktop Accessibility Requirements

Document Accessibility ApplianceFirst published on

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 .

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.