A “Structural” check will test the document for empty tags, broken links, and other issues. It also tests tables, links, tables of contents, and other tags to ensure that they have been assembled correctly, including their required nested tags.

For example, the Structural check will verify that Table tags contain Table Row tags and that those tags then contain Table Data and/or Header cells. 

An “Accessibility” check will test the document against one or more established accessibility standards: WCAG 2.0AA, WCAG 2.1AA, WCAG 2.2AA, HHS, and PDF/UA. These standards ensure that the content is readable and usable by everyone.

We typically encourage our clients to check against at least one structural standard and one accessibility standard. While this is ideal to ensure the document meets best practices and requirements, many documents only technically need to meet one standard.

The logical question then becomes, “Well, which standard should I choose?”

This is not always a cut-and-dry answer, but we can provide some general guidance. It sometimes depends on the industry, organization, client, or even the company’s opinion.

Structural Standards

Currently, there is one structural standard available for PDFs. ISO 32000-1, which was released in 2008, provides PDF-specific guidelines for document accessibility.

This will eventually change, as ISO 32000-2, more commonly known as “PDF 2.0,” will be adopted over time. While PDF 2.0 has been published, many implementations have yet to adopt its features.

Consequently, it wouldn’t be sensible to test against this newly published standard since PDF readers and assistive technology do not yet support many of the changes included. For now, the choice of structural standard is straightforward – regardless of your industry, organization, or objectives, use ISO 32000-1 for structural standard verification.

Accessibility Standards

The most common accessibility standards, used by the majority of our clients, are the WCAG-based standards. WCAG, or the Web Content Accessibility Guidelines, is the most widely adopted and easiest to satisfy within this group.

It has undergone multiple revisions and serves as an updated version of the well-recognized standard, Section 508. Depending on the organization, some groups still utilize WCAG 2.0, while others have transitioned to the more current versions, 2.1 and 2.2.

Since the differences between the versions are minimal, your remediation process won’t vary significantly based on which one you choose. We always encourage our clients to consult the newest version available to them. WCAG 2.2 is our primary recommendation for clients, as it is not only the most recent version but also the most widely accessible and user-friendly.

The HHS standard is written and used by the U.S. Department of Health and Human Services. Because of this, nearly all healthcare professionals use it. We recommend it for anyone in the healthcare industry or working on documents related to health and medicine.

Lastly, PDF/UA, the conversational name for ISO 14289, is considered the “gold standard” for PDF accessibility. This is because it is the only PDF-specific accessibility standard. WCAG, for example, applies to web content but includes PDF-specific components.

PDF/UA, on the other hand, explores the potential within PDF documents and focuses specifically on making that content accessible. We encourage using the PDF/UA standard for those who want their PDF accessibility to exceed WCAG’s requirements; however, the reality is that WCAG is an acceptable goal for the vast majority of document remediators.

In summary, in some cases, deciding which accessibility standard to test against is an organization-wide decision.

Outside of specific industries, such as healthcare companies using HHS, a group will need to have the important conversation about which standard to use. If we are asked for a blanket decision, we usually recommend WCAG 2.2, as it is the most up-to-date WCAG standard.

Using WCAG standards offers the other major benefit of only needing to learn and implement one specification for both web and document content.

The post Which PDF Accessibility Standard Should I Check My Document Against? first appeared on Allyant.

Additionally, we frequently find ourselves recommending changes to an organization’s workflow to better utilize the software at their disposal.

For example, if a client has access to both CL PDF and CL Office, it’s not uncommon to say something like, “This is actually much easier in our other platform,” or “Let’s explore using the other tool to handle situations like this.”

Our priority is accuracy and efficiency, so giving our clients these powerful tools and educating them on when to use them will always be a priority.

As a quick overview, it’s important to note that our software fits into specific niches, and different use cases can benefit from each tool.

CommonLook Office

CommonLook Office is a relatively simple plug-in to both Microsoft Word and PowerPoint that allows a client to walk through a checking and fixing process to ensure that the PDF output from that file is accessible with no additional manual remediation required.

It is simple to learn, powerful in specific document circumstances, and exclusively specialized in Microsoft Word and PowerPoint.

CommonLook PDF

CommonLook PDF is the most powerful PDF remediation tool available. It is a plugin to Adobe Acrobat and can work on any PDF, regardless of what program produced the document.

This is the logical choice for authors who work out of InDesign, Publisher, or other PDF producers, and the remediators who only have access to the PDF. Additionally, once mastered, the plugin is incredibly efficient.

Inputs and Outputs

Both CommonLook PDF and CommonLook Office allow users to generate accessible PDFs and compliance reports that are coupled with the documents. There are, however, additional outputs to consider.

CommonLook PDF is rather straightforward. You use it on an existing PDF, and the output is an accessible PDF. If your main goal is to create accessible PDF documents, that is the best and most efficient option.

CommonLook Office utilizes a Word or PowerPoint document input and outputs an accessible PDF. While PDFs are the most notable output, users will keep the Word or PowerPoint files they have been working on.

This means that the work done within CommonLook Office will forever change the source file when possible, resulting in an updated version that can be used to create additional accessible PDFs.

We frequently think of this “new and improved” Word or PowerPoint file as a template that was now built with accessibility in mind. In short, using CommonLook Office will output the accessible PDF but also a template that can be updated and changed for the next time an up-to-date, accessible PDF needs to be generated.

It’s worth noting that CommonLook Office also creates a temporarily useful XML file. CommonLook Office uses this file to create the accessible PDF,  but once the PDF is created, that is no longer needed, so the XML is of no true consequence long-term.

Use-Case Examples

As you attempt to determine how and where CommonLook PDF and CommonLook Office fit into your workflow, we want to provide a few real-world scenarios. While these are some of the more common situations, this short list is not all-encompassing.

If a PDF document already exists and needs to be made accessible, CommonLook PDF is going to be your best bet. In short, if you have a PDF document, the most efficient way to make that document accessible is going to be to remediate it using CommonLook PDF.

If a Word or PowerPoint file needs to generate an accessible PDF, the easiest way to do that is going to be with CommonLook Office. This allows for the fixing of the source document, and enables easy editing and updating for the future, but also outputs the accessible PDF that we’re looking for.

Sometimes, users who are more comfortable in CommonLook Office than CommonLook PDF will attempt to export PDF documents back into Word in the hopes of then being able to use CommonLook Office in the Word file.

While this might seem like a simple solution, the challenge tends to arise from the exporting process. This conversion frequently changes fonts, layout, and other visual components of the document.

This is not a workflow we recommend, as this means that the document will need to be remade or significantly edited, resulting in more work and making the process less efficient.

Understanding CommonLook PDF and CommonLook Office and strategically knowing when to use them can drastically change your accessible document creation process and ensure that you’re doing so efficiently.

The post When and Why: CommonLook PDF & CommonLook Office first appeared on Allyant.

• We want someone using AT to get the same information as someone who is not using AT.
• Quick examples: describing images and avoiding things only understood visually.

Design with Accessibility in Mind:

• Do what you can and follow best practices in the authoring tool to avoid eventual issues.
  • You can use text styles in most authoring tools, provide alt text to simple graphics, and more.
  • Do not use tables for layout purposes.
  • Some/most situations will need OCR for searchable text manipulation.
  • Can visual content be presented in another way?

Simple example:

• Complicated tables should be written as three individual tables instead of one.

Advanced example:

• Graph as a table.

Two common examples:

Flow charts:

• Tag as images with alt text.
• Tag using heading-level organization.
• Even a list is possible.
• Ask, “Does this make sense and share the same content?” If yes, then you are fine.

Maps:

• Alt text to the entire thing in some scenarios is okay: “United States major highways.”
• Specific info using headings and Figures with Alt text is another great option.

Making Graphic-Heavy Content Accessible

In a world where more and more information is shared electronically and visually, a common question we answer is regarding the accessibility of visual content.

How can we ensure that our documents are accessible to the masses when the information, context, and, in some cases, the text itself, is a visual experience?

Some of the most common examples include flowcharts, maps, and infographics. How can we make this visual content complaint and ensure that the information reaches all intended audiences?

Before we dig into the specifics, it’s important to understand our goals with remediating content and how these goals relate to visual content.

In short, we want people who use assistive technologies to have access to the same information available to someone who is not using these tools.

While the user experience will differ in many cases, the goal is to share information accurately. A few quick examples are adding textual descriptions to images to ensure that someone understands the graphic even if they are not looking at it or avoiding things that are only conveyed visually, such as using colors to indicate something.

Ultimately, this boils down to something we practice and preach as much as possible—design your documents with accessibility in mind. Specifically, do what you can to follow best practices in the authoring tool you are using.

For example, some well-intentioned authors use tables in their files to present text in columns or specific shapes. We should never use tables for layout purposes because they convey inaccurate relationships to readers and can be confusing!

If that author had designed with accessibility in mind, they would have used a built-in column functionality and, therefore, not had to correct the issue in the PDF manually.

Before we explore tangible examples of handling visual elements, it’s worth noting that in some situations, OCR, or Optical Character Recognition, will need to be performed to tag some visual content properly.

For example, if a bar graph happens to be assembled as one big graphic, a remediator may need to run OCR to be able to properly select and tag the numbers or letters from the chart itself. In some cases, OCR is the first step to making visual content accessible as it widens the scope of accessible tagging possibilities.

Is a Graphic the Best Option?

In exploring how to make visual content accessible, a potentially powerful question is, “Can this content be presented in another way?” Considering our goal is to ensure that the reader is given the same information as someone physically looking at the content, it is within our power to make a decision that changes the tag structure and preserves the content.

Imagine this—an author creates a bar graph showing four different bars, each illustrating quantities of a unique item.

While the author undoubtedly made that content visual through the use of the bar chart, would the same information not also be understood through a table? Perhaps it’s four columns, each with the name of the unique item and the corresponding quantity.

This is a critical remediation decision—it drastically changes someone’s perception of the document, sharing a table rather than a bar graph, but, most importantly, it shares the same data in a more digestible and inclusive way.

While that example is exciting, let’s imagine a much simpler one. Rather than having one massive, complicated table with shared column headers and intricate visual organization of three categories, consider making three individual tables. This would share the same content but do so in a more inclusive way that is easier for all audiences to understand and navigate.

With that in mind, we can focus on some common challenges: flowcharts, maps, and infographics.

Flowcharts, Maps, & Infographics

Flowcharts are a frequent way for groups to show organization or structure. They can be a bit daunting for remediators because they seem to progress in multiple directions through multiple different paths. With that in mind, they offer an opportunity for some creative remediation!

Sometimes, we use heading levels to indicate where in the flowchart we are. A Heading 2, or H2, for the top of the chart, and H3, H4, and H5 for the descending levels!

Sometimes, a list is an appropriate option. Perhaps a flowchart has three main “paths.” Each could be tagged as a list, guiding the reader down each path and showing a relationship through list items. The last and sometimes “clunkiest” option is to use figure tags and assign textual descriptions to different content, helping the reading along contextually.

As you can tell, there is flexibility in how we address flowcharts as long as we accurately and accessibly share the information.

Maps are another challenge for remediators. What must the reader know about the map, and how will it be used? Is someone going to use it to actually navigate to a specific location on the map? Or is someone just expected to understand the general idea of the content?

For example, if the map is just used for general information, a remediator could assign Alternate text that reads “Map of United States highways” or whatever the author was trying to convey.

However, if the reader was expected to use the map for navigation, that alternate text would be insufficient to achieve that goal. In situations like this, a remediator can be much more specific as to the contents of the map by using headings for text on the map accompanied by smaller figure tags with alt text for specific sections.

Lastly, infographics are becoming a common but visual method of sharing information while keeping a reader’s attention. While some of these are wildly creative and fun, accessible tagging of infographics is actually more straightforward than the other examples. In short, consider the reading order of the content and place portions of the content into groups for easy organization and progression.

For example, if you are remediating Allyant’s “8 Steps to PDF Accessibility” infographic (see below), consider tagging the content from left to right, organized by each step. Each could have a heading and a paragraph tag, for example.

While every infographic is unique, grouping and reading order are the two main components of ensuring the content is tagged accurately and accessible.

“8 Steps to PDF Accessibility” infographic text: “1., Tags: Ensure that the document has tags, the tags are correct for the content, and that they are in a logical order as compared to the visual layout of the PDF. 2., Metadata: Verify and fix the Metadata. 3., Color: Confirm that color (format, font, etc. is not the only way info is being conveyed and there’s sufficient contrast between the content on the page and any background colors. 4., Alt Text: Provide alternative text to links and images that convey important information; artifact decorative images. 5., Lists: Double-check that lists are correctly structured according to standards. 6., Tables: Confirm that data tables and Tables of Contents tags are correctly structured according to standards. 7., Other Tagging: Address any other tagging issues that may exist. 8., PDF Validator: Use a reliable checker that tests against recognized standards such as WCAG 2.0, HHS or PDF/UA. CommonLook, Copyright 2019.”

While the authoring world continues to make fun, unique, and visual documents, the accessibility world must continue to prioritize comprehensibility and equal access. When faced with visual content, we hope the remediator feels empowered to use some techniques to make the content accessible rather than discouraged by the challenge.

The post How to Make Visual Content Accessible in PDFs first appeared on Allyant.

• The Structural check tests against the PDF creation standard, ISO 32000. While ISO 32000 mentions accessibility functionality in PDF, it is broader.
• The Structural check confirms if the PDF is built correctly, verifying links, forms, graphics, and PDF encoding. (This is not the same thing as character encoding, although that’s a thing, too.)
• The Accessibility standards approach the broader concept of what’s allowed in a PDF and tighten that up for accessibility.
• Because it’s so widely used, we often refer to WCAG (Web Content Accessibility Guidelines) 2.1 regarding accessibility standards.
• WCAG 2.0 is ISO standard 40500. The ISO standard has not been updated, and there is no new ISO standard for WCAG 2.1.
• It is important to note that WCAG is for the web, not PDFs.
• Sometimes, WCAG wants you to do something to your webpage that isn’t supported in PDF.
• The PDF specifications will occasionally require you to do things differently because it is not web technology (like links in PDFs needing Alt text/Contents). Contents are a properties field for Link Annotations. It is a formal name for a descriptor that the standard calls for. (Alt text, Actual text, Expansion Text, Contents, Tool tips, and Language – are some similar properties.
• The PDF/UA spec—ISO 14289—is the accessibility standard specific to PDFs. It takes what is allowed in a PDF and regulates it for accessibility.

Running a standard check may be the most essential step for document accessibility. For this reason, we spend a great deal of time and energy remediating a document to comply with and pass the standards.

Structural Check vs. Accessibility Check

There are two major types of standards, and we recommend testing all documents against structural and accessibility standards to guarantee usability and overall compliance.

In short, a structural check tests issues with the actual assembly of a document. In contrast, an accessibility check verifies that the PDF is accessible to all audiences.

For example, in the case of an image or graphic, a structural check confirms that fonts are encoded correctly and mapped to Unicode. Likewise, an accessibility check ensures that the text is tagged correctly.

Both are extremely important. The structural check verifies the correct content encoding, and the accessibility check verifies proper tagging so that assistive technologies can handle it accurately.

ISO 32000

To get a bit more specific, the structural standard checks against ISO 32000, the official guide to making a PDF. ISO 32000 addresses some accessibility functionality, but its primary purpose is to ensure correct PDF construction. It offers guidelines for software developers and relates to document components like the construction of links, forms, graphics, and the literal encoding of the PDF.

To be structurally valid, PDFs must be compliant against the structural standard ISO-32000-1 (version 1) or ISO 32000-2 (version 2).

Accessibility Standards

Accessibility standards are a bit more specific. First, you’ll notice that I said standards—plural. There are many of them! Some relate to specific industries, and some are updated versions of previous accessibility standards.

The US Department of Health and Human Services developed the HHS standard for healthcare organizations.

The original Section 508 standard was updated to incorporate, by reference, WCAG 2.0. WCAG 2.0 has since been updated to WCAG 2.1, and even more recently, WCAG 2.2. So, while we recommend that clients check against ISO-32000, accessibility standard selection is based on multiple variables, such as your organization’s needs.

Compared to structural standards, accessibility standards take a broader approach to what’s allowed in a PDF and make it more specific.

WCAG

While both of our standard types consider accessibility, the accessibility standards are all about access. We recommend referring to the most up-to-date version of your chosen accessibility standard. Generally speaking, WCAG is the most widely used.

WCAG, or the Web Content Accessibility Guidelines, are technically for web content. While initially intended for web content, it also works fairly well for PDF, which is why it is widely used.

PDF/UA

PDF/UA (the “UA” stands for Universal Accessibility), another accessibility standard frequently referred to as the gold standard for PDF accessibility, is ISO 14289. This accessibility standard is specific to PDF. It takes the general idea of what is allowed in a PDF and focuses on accessibility.

Again, our general recommendation is to check documents against both structural and accessibility standards. That can look slightly different, depending on what accessibility standard you want to meet, but the goals are the same.

Complying with both standard types helps confirm that your PDFs are built appropriately and are accessible to all audiences.

The post Differences and Similarities in Structural & Accessibility Standards in Digital Documents first appeared on Allyant.

To add to the list of contextual vocab, standards are primarily written by the International Organization for Standardization, which is known as ISO. PDF/UA is a PDF-specific standard that contains the requirements to ensure content is usable and readable.

This standard is considered the “gold standard” for PDF document accessibility and its importance lies in offering equal access and the prioritization of sharing content with everyone.

What is the difference between PDF and PDF/UA?

A common question we receive is, what are the differences in various PDF standards? Should I test my document against standard ABC? Or perhaps standard XYZ? While these answers are not always cut and dry, there are, in general, two types of standards: structural and accessibility.

The structural standard is essentially the rulebook for how to make a PDF. More specifically, the core structural PDF standard is ISO 32000, and it is broad and open-ended. It showcases the possibilities of the PDF file type, ensuring that components like lists and graphics are encoded correctly but doesn’t prioritize their accessibility.

The accessibility standard is more specific and narrows the possibilities of PDF documents to ensure that assistive technologies can adequately share the information. This standard involves verifying document tagging and is a bit more proactive and accessibility centered. For example, if you do everything that is possible in a PDF, it likely will not be accessible, so this accessibility standard, PDF/UA, reigns in those possibilities and guides accessibility-minded document creation.

In summary, many people refer to ISO 32000, the structural standard for PDF documents, simply as “PDF.” PDF/UA, the “gold standard” for document accessibility, tests different parts of the PDF, showcasing the benefits of testing against both a structural and accessibility standard to ensure compliance.

PDF/UA or ISO 14289?

Another recurring question is regarding the naming of PDF/UA. As we mentioned earlier, standards are written by the International Organization for Standardization (ISO). As a result, each standard that is released is given a conversational or more casual name but also bears an ISO code. In the case of PDF/UA, this code is 14289. So, in short, ISO 14289 is the formal name of PDF/UA, which is the more common name used for the accessibility standard.

The future of PDF/UA

As we close out this clarification of a few common questions about standards, it’s worth mentioning that this landscape is about to change. As PDF documents have evolved, the accessibility community has evolved to meet the standards. As new capabilities are added to PDF files, our efforts to use them with accessibility in mind also change.

Recently, an update to PDF/UA was released. Using all of the terminology we have explored previously in this article, this standard is formally numbered as ISO 14289-2 and more casually referred to as PDF/UA-2.

PDF/UA-2 is included in another PDF specification known as Well-Tagged PDF, or WTPDF.

In short, this contains all the accessibility requirements from PDF/UA-2 but also includes newer requirements, such as checkpoints about reuse, text extraction, derivation to or from HTML, and more.

For now, the more common option is PDF/UA, but as technology and PDF capabilities advance, it’s only right that our accessibility standards do, too.

The post What is PDF/UA and Why is it Important? first appeared on Allyant.

These concerns are normal. Nobody wants to make the wrong choice, waste valuable time, or risk doing something wrong. My goal is to share the details of the different standard types, provide some of the most significant distinctions between them, advise what standards you should be using, and showcase the Allyant recommendation for guaranteeing standards compliance.

Before we delve into the individual standards, let’s look at the two types of electronic document standards.

Electronic Document Standards

Structural standards offer guidelines for creating a PDF and checking some of its more structure-related requirements. For example, if a document has a graphical element, such as a FormXObject, a structural standard will flag it if it is not in a Figure tag.

Accessibility standards address the requirements for a document to function appropriately with assistive technology and provide access to the content. For example, if that FormXObject is in a Figure tag, an accessibility standard will flag it if it is not given Alternative (or Actual) text.

Both structural and accessibility standards serve specialized purposes and are crucial to overall compliance.

ISO-32000

ISO-32000-1 (version 1) is a structural standard. While a more recently released structural standard (ISO 32000-2 – version 2) exists, ISO-32000-1 is the one most processors and assistive technologies support.

This is the most commonly used structural standard until the technology catches up and supports the newer standard.

If you use Allyant’s CommonLook PDF to remediate (fix) your PDFs, you will find that ISO-32000-1 is the only available structural standard.

For more context, the latest ISO 32000-2 release was introduced in December 2020. PDF/UA-2 has been published as of early 2024. It is our expectation that in the near future, support for ISO-3200-2 and PDF/UA-2 will be more readily available.

It’s also important to note that Allyant has two people who actively participate in these standards-writing activities. So, we have our finger on the pulse, and when the standards are supported, Allyant will support them as well!

Section 508

Accessibility standards, however, offer more options. Section 508, originally from the American Rehabilitation Act, was enacted to eliminate barriers between audiences and information technology.

While a staple of electronic accessibility for many years, this law was revised in 2017 to reference WCAG 2.0 (or the Web Content Accessibility Guidelines) — a set of guidelines to ensure accessibility. WCAG 2.0 has since been updated to WCAG 2.1, and more recently 2.2.

Within the general Web Content Accessibility Guidelines (both 2.0, 2.1 and 2.2), there are A (single-A), AA (double-A), and AAA (triple-A) Success Criteria that address different levels of compliance within the standard.

As you proceed from A to AAA, the levels grow more involved, meaning that AAA-compliant documents are more accessible than A-compliant documents.

Web Content Accessibility Guidelines (WCAG)

In 1997, the World Wide Web Consortium (W3C)’s Web Accessibility Initiative (WAI) created international standards for the Internet in an effort to improve online experiences for people with disabilities.

Though these Web Content Accessibility Guidelines (WCAG) were originally written specifically for web content, they can apply to PDF as well, with some slight adjustments.

But, due to limitations in current technology, some websites cannot reach AAA compliance. As such, the AA level is most commonly used, regardless of which version of WCAG is being used.

In addition, PDF/UA (the PDF standard for Universal Accessibility) and HHS (for The US Department of Health and Human Services) are other accessibility standards that, while less common, are frequently used.

So why are there so many options? How do I know where to start or what to use?

Do we need all these accessibility standards?

While compliance can sometimes feel like a moving target, standards serve as a detailed, uniform and consistent set of guidelines that help document creators guide their decisions. Even with a shared goal of document compliance, there are differences in requirements and best practices between these accessibility standards we’ve mentioned.

For example, it’s important to note that WCAG was developed for web content, so while the standard does apply well to PDF, it wasn’t its intended use. To put it plainly, not every checkpoint in WCAG will apply to PDF, and some even need to be “massaged” to be more PDF-related.

For example, HTML doesn’t have Lbl (label) tags in lists. As a result, WCAG technically doesn’t require Lbl tags in their lists, but the PDF/UA standard does. Also, decorative images are handled differently on a web page than in a PDF.

These are just a couple of examples of adjustments we make to make this web-based standard more relevant to PDF documents.

PDF/UA is PDF-specific and is considered the gold standard for accessibility in the PDF world.

HHS Guidelines

Some other notable standard differences can impact document creation. For example, historically HHS did not allow empty header cells in data tables, while WCAG and PDF/UA did. This led to slightly different table layouts based on the standard. HHS had specific requirements for file-naming conventions and required Bookmarks in nine pages or longer documents.

These requirements were unique to HHS — another indication that standard choice matters, and that standards change over time.

One of my favorite differences that has since been changed is that HHS used to have a set of six acceptable fonts that authors could use. This was very limiting in terms of document creation, but it is another example of different standards having notably different and unique requirements.

Given that standards are highly unique and sometimes a bit nit-picky, how do we decide which one to use?

Which accessibility standard to choose?

Unfortunately, that decision is either yours or a product of your surroundings. What I mean by this — is that WCAG 2.1AA is a commonly used accessibility standard, but it’s not right for everyone. In fact, the industry of the applicable document can play a huge role in choosing a standard.

For example, suppose you are a healthcare company. In that case, you might need to use HHS as your accessibility standard because your information falls under, or is most related to, the Department of Health and Human Services.

Some documents depend on the client.

If I am a marketing firm creating advertising materials for two clients, one might require PDF/UA for their website, and another might require WCAG.

Sometimes this choice is made at an organizational level, setting a precedent to take the guesswork out of future document creation and remediation.

Finally, since WCAG 2.1AA is so commonly used, many clients choose this option by default, but again, this might change once WCAG 2.2 becomes more widely adopted.

A Recommendation

Lastly, I want to leave you with a simple recommendation.

The only way to guarantee compliance is to ensure that your document is compliant against structural and accessibility standards. So, we at Allyant encourage all users to select one of each when running a document verification.

For some, this looks like ISO-32000-1 and one of the WCAG options, but for others, it could be ISO-32000-1 and PDF/UA.

There isn’t a single correct combination, but testing against both types of standards ensures that nothing falls through the cracks.

When running your verification, it is critical to address and correct all failures and manually verify all warnings and checkpoints that require user verification. Only then can you guarantee compliance and ensure your content is accessible to all audiences.

The post Most Important PDF Accessibility Standards first appeared on Allyant.

And, when it comes to PDF tagging, there are “containment,” or nesting rules, around what tags are allowed – or even required – to be nested inside other tags.

That said, this may or may not be a concept you must pay much attention to in your day-to-day PDF remediation work, depending on the content of your documents.

For example, if your documents are relatively simple, the only nesting you may have in your tags is the Document tag containing all other tags in the PDF. The Document tag is required to be the first, and only, child of the Tags root. All of the other tags in a document should be nested inside that Document tag.

Of course, you’ll need to be aware of some additional nesting rules in more complex documents with Tables of Contents, footnotes, lists, or tables. However, with some guidance, recognizing proper PDF tag nesting and correctly implementing this nesting can become second nature within your PDF remediation workflow.

What is tag nesting and how does it impact PDF accessibility?

PDF tags are the behind-the-scenes containers that determine, among other things, how a PDF document is read by assistive technology. 

If tags are inaccurate or in an incorrect order, the reading experience could be, at best, confusing and, at worse, completely impossible! 

Sometimes, the order and organization of these tags is up to the remediator to decide. For example, do you want this to be read before or after that? However, other times, the structure of the tags is written according to the PDF accessibility standard, and not following those rules precisely will result in an incompliant document.

When it comes to nesting tags, if you have an image in a list item, for example, you would need to ensure your Figure tag is properly nested inside the List’s substructure. This nesting, then, provides critical context to the reader. The nesting of the Figure tag inside the list’s substructure indicates that the graphic is literally inside, or part of, that list, rather than it falling before the list, after the list, or breaking it.

Another component of nesting is a tag’s placement value. A tag’s placement value determines if a tag can, or even should, have additional tags within it or if it must be nested inside of other “structural” tags. A placement value can be changed in some scenarios, but in broad terms, it’s important to know that this value determines a tag’s nesting requirements.

Why is tag nesting important for PDF accessibility?

Once we understand tag nesting, the intention behind it becomes more relevant. In short, some tags have very specific tag structures that must include nesting to be accessible.

For example, if you have a list in your document, you must ensure it is properly tagged as a List.

List tags are required to have LI, or List Item, tags nested within them. There would need to be one LI tag for each item in the list. If your list is 15 items long, the list tag would require fifteen nested LIs.

Furthermore, these LI tags are required to have substructures that offer even more organization to the tags tree. They come in the form of body (LBody) tags and, in most cases, label (Lbl) tags.

The Lbl and LBody tags tell a critical story to the reader, helping explain how the list is compiled, the order of the items in the list, and the numbering mechanism for that particular list.

Additionally, if we want to dig even deeper, some lists have lists within them! We call these lists “nested lists,” and the tag structure is the same in terms of specificity and structural requirements. Other examples of tags requiring nested tags are Tables and Tables of Contents.

Sometimes, nesting is used as an organizational tool. We call tags used for these purposes ”Grouping” tags, and examples include Document, Part, Sect, and Art tags. As previously mentioned, some of these, such as a Document tag, are required. The Document tag contains the entirety of the Tag tree nested within it. Others, such as an Art tag, could be optional in some cases or only used in specific circumstances.

A great application of an Art tag would be grouping a newspaper article that starts on page one but continues onto page nine together. This way, the reader can navigate through the entire article, regardless of its placement in the physical view of that newspaper.

Of course, Grouping tags, such as the Art tag, have their own containment rules.

The Art tag, for example, is not allowed to contain text directly. So, nested inside the Art tag for the newspaper article, you would find heading tags, paragraph tags, and so on, as appropriate to the content.

As you can see, use cases for Grouping tags can vary, but nesting is a critical component of using them correctly.

How to do nesting in PDFs?

How you nest a tag within another depends on your remediation software’s functionality, specific keystrokes, or commands. Typically, this involves inserting and placing tags within a new tag. 

This process’s ease depends on the software, but knowing what should and shouldn’t be nested is the first step to achieving the desired efficiency and accuracy.

Even with an understanding of nesting, common mistakes still arise. 

Unnecessary nesting is one of the main culprits. Some tagging tools may, for example, nest multiple Sect tags inside each other, and while it may not affect the accessibility of the document or how it is read, it is an easy thing to fix when remediating a file. 

Additionally, tags should never be nested directly inside another tag of the same type. For example, a P tag should never have another P within it. These are easy to recognize as you work through the recommended workflow of CommonLook PDF remediation.

Some scenarios have different nesting requirements based on context. For example, a Caption tag can serve two purposes: as a Figure caption or a Table caption. 

A Figure caption should not be nested inside a Figure tag, as the content of the Caption tag will not be read. However, a Caption tag associated with a Table should be nested within the Table tag to ensure it is read with the appropriate content.

These situations may seem wildly specific, and they are, but with intentional practice and repetition, a remediator will recognize these nesting situations effortlessly as they work through a document. 

Feel free to utilize the online resources in our Knowledge Base as you become more comfortable with tagging practices. This comprehensive database contains articles on the vast majority of tagging and nesting structures, which can be very helpful.

The post What is Nesting in PDF Accessibility and Why is it Important? first appeared on Allyant.

However, PDFs can fall short if not properly created, making them inaccessible. As authors remediate or make the files accessible, there are some common mistakes that even the newest remediators can be on the lookout for and quickly master.

Reading Order

In a PDF file, the reading order is the most critical component related to how the content is shared. 

What if the conclusion of the document is read before the introduction? What if a story’s plot twist is uncovered before meeting the characters? 

Content can change dramatically based on the order in which it is shared, and the reading order is determined by the order of the tags in the Tags tree. It is this order that assistive technologies (AT), such as screen readers, navigate through to read the content. 

This interface is hidden behind the scenes and is up to remediators to verify. Sometimes, a file comes through logically and in the correct order straight from generation, but that is increasingly unlikely and typically requires manual correction. 

To check for accuracy, a remediator should navigate, tag-by-tag, through the tree and ensure that the order in which the tags are assembled is the intended order in which the content should be read. 

Remediation difficulty can vary based on the level of correction needed, but overall, verifying reading order is a critical step to establishing a compliant and truly accessible document.

Correct Heading Usage

Another one of the main offenders of inaccessible documents is incorrect, inconsistent, or nonexistent heading usage. Headings help readers navigate the document, stay organized, and give someone a clear outline of the document’s structure.

Without headings, or perhaps even more confusingly, with incorrect headings, a reader may wonder where in a document they are, have trouble finding the specific content they are interested in, and be unable to make sense of the flow and organization of the document.

A basic and helpful tip for assigning proper headings is to think of an outline of the document. The document title should be tagged as a Heading 1 (H1 in PDF). The subsections of the document should be tagged as Heading 2s (H2), and the subsections of the H2s should be tagged as Heading 3s (H3). The same section and sub-section organization should be used throughout the entire document.

Another way of thinking of this is that headings are a leveling system, not a numbering system. For example, you might have several H2 tags before you have your first H3 tag.

Using headings properly is a crucial step in creating accessible documents.

Tagging the Correct Content

Our role as remediators is to tag the content on the page so that a reader using assistive technology can access the same content as a sighted reader, for example. 

Another component of this is that the tags must be accurate based on the document content. Another piece of this puzzle is that some content can be untagged and, therefore, removed from what assistive technology reads. 

Examples of this are page numbers, decorative page borders, or any running header or footer that repeats on every page. If someone is reading a 300-page novel, they don’t need to be read – by assistive technology – the page number at the bottom of every page – it can be unnecessary and even disruptive, depending on when the numbers are read. 

As a result, remediators must take appropriate steps to untag content like this. 

Untagging, also known as artifacting, this unnecessary content is an important skill to master to give AT users the best possible experience with a PDF.

Alternative Text

Alternative text (Alt text) is a textual description of an image shared with AT users when that content is read. Not only having Alt text but, even more importantly, having accurate Alt text for all tagged graphics is a requirement under all accessibility standards and a common shortcoming for newer remediators. 

If a graphic is contextually important, but assistive technology cannot share that information, a user is missing out on valuable content, and the file is therefore inaccessible. 

A related issue is that some Alt text is horribly wrong. Some authoring tools actually auto-populate the Alternate text field, which is typically incorrect and poses other issues. 

To avoid this common remediation mistake, verify that every Figure tag is given accurate and detailed Alt text. 

Of course, you may wonder, “How detailed?” A helpful rule is to make the Alt text as concise as possible while remaining as thorough as possible so as not to drop any needed information.

Interactive Elements

Putting interactive content into PDF files is extremely common. Links and forms are a few of the most common examples, which, if not handled properly, can be confusing and frustrating for readers using assistive technology.

In short, AT uses descriptions such as Alt text, tooltips, or an annotation’s Contents to tell the reader exactly what happens if they select a specific link or how to fill a form field best.

It might be an external link that could open a webpage. It might be an internal link, which could bring them to another point in that same document. It could trigger something outside of the PDF itself, such as opening a pre-addressed email to someone.

The worst-case scenario is that the link happens to be broken, and selecting it doesn’t do what it was expected to do.

Regarding a fillable form, this text could tell a reader what the question is asking or how to answer a question.

Having these links and forms in PDFs is a great, efficient way to let readers perform certain tasks. Still, if these interactive elements lack the appropriate accessibility requirements, the entirety of the document is incompliant.

Table Usage & Formatting

Tables can be an incredible way of displaying information while showing relationships between specific data sets. Scientific reports, for example, rely on data tables to articulate data-supported concepts. However, if tables are not used properly, they can leave readers confused and lost in a document. 

One of the most common table-related issues is authors using tables for presentation purposes. The main offender is an author who does not know how to design columns in their document, so to workaround this shortcoming, they put the content into a hidden table with two or more columns. Visually, this looks acceptable, but the tagging of the document will expose Table tags, leaving a reader using AT confused as to what data is trying to be shared. 

In short, authors should refrain from using a table structure to format content. 

We refer to these improper uses as presentation tables and they will require involved manual remediation to fix. Tables can, of course, also account for other issues, such as cells spanning incorrect heights and widths, but to ensure a document is accessible, be sure only to use data tables to convey a data-driven relationship. 

If the use of a data table is correct, meaning the data does convey a relationship and a table is an appropriate way of sharing it, other specifications must be met. For example, cells that categorize and relate to entire columns or rows must be appropriately marked as header cells. 

This is one of the many potential issues that must be addressed when dealing with properly identified and structured tables.

Metadata

Accurate metadata is critical to a PDF’s ability to be accessed and gives valuable context as a reader navigates to and through it. A PDF’s title, for example, tells the reader what file they are opening and ensures that they will not be surprised when the file they open and begin reading is not what they expected. 

Additionally, there is a setting within a document’s properties that ensures that the document’s title, rather than the file name, is read by assistive technology. 

This is increasingly important, as some file names are highly coded sets of numbers and letters rather than a concise naming convention that reflects the document’s content. 

A document’s language is also set in the metadata. If a document is written in one language but set to read in another, the document will be inaccessible. 

Author, subject, keywords, and an indication that the file has been tested for accessibility are metadata properties that offer essential information to readers and should not be ignored. 

While not all of those fields are required under each accessibility standard, all offer helpful information to audiences and should be properly verified in the context of accessibility.

The post 7 Common PDF Accessibility and Remediation Mistakes first appeared on Allyant.

While various testers will boast claims of efficiency and ease of use, the reality is that there are specific mechanisms built into some of the more capable testers that you will want to make sure you’re utilizing. 

Regardless of which tester you use, it’s worth ensuring that they support some of these game-changing capabilities.

Specific Standard Choice

When checking the accessibility of PDFs, one of the most common shortcomings of some checkers is having general or more vague testing criteria. The challenge here is that not only do laws require accessibility against highly specific, individual standards, but remediators must be able to verify that they are checking against them.

For example, most of the healthcare industry in the United States strives for compliance with HHS, a standard based on the Web Content Accessibility Guidelines, created specifically for the US Department of Health and Human Services. If your standard checker does not give you the explicit option to test against HHS, it is unlikely to verify some of the HHS-specific checkpoints you will need.

In short, when choosing an accessibility tester, ensure that it allows you to test against individual, up-to-date standards rather than just triggering a more general “accessibility check.”

Manual Verification Checkpoints

There are plenty of accessibility requirements that a machine, or a computer in this case, has the ability to test. These are verifications such as “is this happening?” or “is that not happening?” These are considered automatic checks, and most checkers will easily identify issues with these checkpoints as their triggers are pretty straightforward. 

What happens, however, when the checkpoints require something that a machine cannot verify? 

For example, Figure tags require Alternate text under every standard. Automatic verification can be done by nearly any checker that asks, “does this Figure tag have Alt text?” and the remediator will be quickly met with a “Passed” or “Failed” result. 

But what about the accuracy of that Alt text? 

If the image is of a palm tree and the Alt text says “jar of applesauce,” would this trigger a “Failed” result? 

Sadly, in most cases, it would not. 

If you are using a checker that does not account for the need and importance of manual verification, your inaccurate Alt text could slip through the cracks and result in a non-compliant PDF. 

In short, when choosing an accessibility tester, ensure that it requires manual verification of checkpoints that it (i.e., a machine) cannot adequately check on its own.

Metadata & Document Properties

Metadata and document properties such as title, language, and file name are critical to the compliance of a PDF document. The reality is that they aren’t “flashy,” so some PDF checkers don’t give them the attention they not only deserve but also require! 

The great news about metadata is that it can be adjusted at nearly any point in the document creation process. The source file can be given credentials that carry over through the PDF generation and remediation, or a remediator can adjust metadata in the final PDF form. 

This flexibility is excellent, but when choosing an accessibility tester, ensure it verifies the presence and accuracy of the document’s metadata and supporting document properties.

Accessible Report Generation

Lastly, the ability of PDF accessibility checkers to generate a compliance report should always be a top consideration when exploring options. Document design and the resulting remediation of that PDF document takes time, knowledge, and manual effort.

A compliance report is a critical output to keep track of any and all accessibility checkpoints that the document was tested against, and the report serves as a metric for a document’s accessibility.

Today, it is not uncommon for clients to require a compliance report with a created document to ensure that the file they receive meets the necessary thresholds of compliance and that the authors and remediators have the knowledge to deliver such a product.

Beyond that, in more straightforward terms, a compliance report supports the claim that a document is legally acceptable. Beyond generating a report, some checkers’ reports are accessible themselves, showing a devotion to creating accessible content.

To protect your content and the effort put toward making that content compliant, a checker’s ability to generate an accessible report should be another top consideration as you select your testing tool.

CommonLook PDF Validator is an excellent PDF accessibility checker that lets the user check against specific accessibility standards, provides manual verification checkpoints. In addition, it provides a certification report that lets the user know what accessibiity standards was the PDF tested against.

You can download CommonLook PDF Validator for free on this page.

The post Top 4 Things to Look for in a PDF Accessibility Checker first appeared on Allyant.

PDF – Portable Document Format – is one of the most prevalent digital document formats, and it is used by individuals and organizations all over the world. There are a number of reasons behind that, primarily because PDF documents can be viewed, accessed or even modified on any device, regardless of the environment in which they were originally created.

But, not all PDFs are created equal. A PDF document not created with digital accessibility in mind may not be accessible if everyone cannot easily open, access, read, and navigate the document. And, when we say everyone, we include people with disabilities like vision, hearing, mobility, and cognitive impairment.

To solve the digital document inaccessibility problem, a set of universally accepted guidelines pave the way for compliance.

What is WCAG?

WCAG, or Web Content Accessibility Guidelines, is a set of guidelines developed by W3C in cooperation with individuals and organizations worldwide.

The World Wide Web Consortium (W3C) is an international community where the public, member organizations, and full-time staff collaborate to develop web standards. It’s the main international standards organization for the web.

WCAG outlines how to make digital content more accessible to people with disabilities. Anything you access on the internet regularly falls under the purview of web content, such as images, videos, sounds, text, or even color or markup that defines structure and presentation.

Who is WCAG intended for?

WCAG and its related resources and information are primarily intended for web content developers (website designers and engineers, page authors, etc.), web accessibility evaluation tool developers, web authoring tool developers, and anyone else who wants or needs a standard for web accessibility.

If a digital asset, like a website, app, or document, meets WCAG guidelines, it generally means it is accessible.

Does WCAG apply to PDF documents?

Yes, WCAG applies to PDF documents to ensure they are accessible to people with disabilities.

WCAG 2.0, 2.1, and 2.2 are technical standards with 12-13 guidelines that are organized under four main principles referred to as POUR:

• Perceivable
• Operable
• Understandable
• Robust

Each guideline has testable success criteria at three levels: A, AA and AAA. A is the lowest level of compliance, and AAA is the highest. You should comply with AA at a minimum.

To learn more about the principles and guidelines of web accessibility, check out this resource by W3C.

The latest standard of WCAG is WCAG 2.2, which was released in October 2023. Note that it wasn’t intended to replace WCAG 2.0 or 2.1. If a webpage or, by extension, a PDF, passes at the WCAG 2.2 AA level, it will also pass 2.1 AA and 2.0 AA.

You can read more about WCAG 2.1 and PDF Accessibility in this article.

What if your PDF doesn’t comply with WCAG guidelines?

If your PDF doesn’t comply with WCAG guidelines, it probably fails accessibility. This puts your organization at risk of being targeted in an accessibility-related lawsuit.

For this reason alone, it’s critical to verify your PDFs’ accessibility.

The good news is that you can do that easily by using our free PDF accessibility checker – CommonLook PDF Validator.

PDF Validator provides users with a certification report for each tested document. 

The post Does WCAG Apply to PDFs? first appeared on Allyant.