• Ensure Accessibility in Your Templates and Flows
  • Why accessibility matters
    • Compliance and regulation
    • Inclusive communication as a differentiator
  • Accessibility standards: WCAG and PDF/UA
  • Design‑time accessibility: building accessible templates
    • Practical tips to design templates for accessible documents
      • How to set the document title for your template
      • How to set alternative text for dynamically generated pictures
    • Using Microsoft Word’s Accessibility Checker
    • Validating PDF/UA compliance during preview
  • Runtime accessibility: converting and validating documents in flows
    • Generating accessible PDFs with the Convert document flow block
    • Validating the converted file
  • Driving conditional logic based on accessibility results
  • Summary: Accessible documents by design and by automation
  • Accessibility Features: License and Release Dates

Ensure Accessibility in Your Templates and Flows

Accessibility is key to producing compliant, inclusive documents. This page provides guidance on designing, validating, and enforcing accessibility across templates and flows to ensure your documents work for everyone.

Why accessibility matters

Accessibility is about ensuring that information can be perceived, understood, and used by everyone, including people with visual, auditory, motor, or cognitive disabilities. While accessibility is often associated with websites and apps, it is just as critical for digital documents such as invoices, contracts, quotations, letters, and reports.

There are two strong reasons why accessibility should be a first‑class concern in document automation:

Compliance and regulation

Accessibility is increasingly mandated by law. Examples include:

• European Accessibility Act (EAA): Requires accessible digital products and services across the EU.

• Americans with Disabilities Act (ADA): Prohibits discrimination and is frequently enforced in digital contexts.

• Nation and sector-specific regulations that reference accessibility standards for electronic communication.

Inclusive communication as a differentiator

For the people who rely on accessible documents, accessibility is not a “nice to have”. It is essential. Organizations that invest in inclusive communication reduce friction, increase trust, and demonstrate social responsibility.

Accessibility standards: WCAG and PDF/UA

Most accessibility requirements originate from WCAG (Web Content Accessibility Guidelines), which define how digital content should be perceivable, operable, understandable, and robust. While WCAG primarily targets web content, its principles apply equally to documents.

For PDFs specifically, the relevant standard is PDF/UA (PDF/Universal Accessibility):

• PDF/UA defines how a PDF must be structured so assistive technologies (such as screen readers) can correctly interpret content.

• It covers aspects such as tagging, reading order, document structure, alternative text, and metadata.

• A PDF that conforms to PDF/UA can be reliably consumed by users with disabilities.

In short, WCAG sets the principles while PDF/UA defines how accessible PDFs must be built.

Design‑time accessibility: building accessible templates

The most effective way to ensure accessibility is to address it at design-time when creating document templates. Building in accessibility at design time is significantly easier than remediation later in the process.

Practical tips to design templates for accessible documents

When creating templates, follow these best practices:

• Set the document title property: Always define a meaningful document title in the Word document properties. A missing title is one of the most common accessibility issues and prevents assistive technologies from correctly identifying the document. See How to set the document title for your template for more information.

• Use built-in heading styles: Apply Microsoft Word’s built-in heading styles (Heading 1, Heading 2, Heading 3, etc.) instead of manually changing font size or weight. This creates a semantic structure that screen readers rely on for navigation.

• Follow a logical heading hierarchy: Do not skip heading levels (for example, jumping from Heading 1 directly to Heading 3). Headings should reflect a clear, logical document outline.

• Ensure a logical reading order: Especially in multi-column layouts, sidebars, or complex page designs, make sure content is read in the correct sequence when accessed by a screen reader.

• Add alternative text to non-text content: Provide meaningful alternative text for images, charts, icons, and logos. Decorative images should be explicitly marked as decorative so they are ignored by assistive technologies. See How to set alternative text for dynamically generated pictures for more information.

• Avoid images of text: Do not embed important text inside images. Screen readers cannot interpret text that is rendered as part of an image.

• Use tables only when appropriate: Use tables strictly for tabular data, not for layout purposes. Always define header rows and, where needed, column headers so assistive technologies can correctly associate data cells.

• Keep tables simple: Avoid merged cells, nested tables, or overly complex table structures, as these can be difficult for screen readers to interpret correctly.

• Avoid conveying meaning by color alone: Do not rely solely on color to communicate meaning (for example, “items in red are overdue”). Always provide an additional textual or structural cue.

• Ensure sufficient color contrast: Make sure there is enough contrast between text and background colors to support users with low vision or color-blindness.

• Use readable fonts and font sizes: Choose clear, legible fonts and avoid very small text sizes. Ensure line spacing and paragraph spacing support comfortable reading.

• Use lists correctly: Use Microsoft Word’s built-in bullet and numbered list features instead of manually typing symbols or numbers. This ensures lists are correctly announced by screen readers.

• Avoid excessive use of text boxes and shapes: Text placed inside floating text boxes or shapes may disrupt reading order. Use them sparingly and only when necessary.

Using Microsoft Word’s Accessibility Checker

Microsoft Word includes a built‑in Accessibility Checker that helps identify common issues early. We strongly recommend using the accessibility checker on your Template Builder templates before pushing them to production.

Learn more about Accessibility checker on the Microsoft Support website.

Validating PDF/UA compliance during preview

To preview a template with sample data and validate its accessibility at design time, navigate to the Templates section in the Smart Flows Project Console and open the template you want to test.

1.

Select Preview in the template navigation. This opens the Preview document modal.

2.

Set Output format to Accessible PDF-document. This ensures the generated PDF is tagged and suitable for assistive technologies.

3.

Enable the option Check PDF/UA compliance. This instructs Smart Flows to validate the generated PDF against the PDF/UA standard during preview.

4.

Select Preview document. Smart Flows generates the PDF preview and simultaneously runs the PDF/UA compliance validation.

5.

Review the PDF/UA validation result. Alongside the document preview, a PDF/UA Validation Result window is displayed.

6.

The Overall status shows whether the document fully complies with PDF/UA. Issues are grouped by type and page, such as missing document title metadata, skipped heading levels, missing alternative text for graphics, or incorrect logical reading order.

7.

Iterate on the template design. Use the feedback to update your Microsoft Word template. For example, set the document title, fix heading structure, or add alt text to images. Repeat the preview and validation steps until the document passes the PDF/UA compliance check.

Runtime accessibility: converting and validating documents in flows

Even with well‑designed templates, accessibility should also be validated at runtime, when documents are generated and converted. Experlogix Smart Flows can automatically attempt to convert your generated documents to accessible PDFs and validate compliance with the PDF/UA standard during execution.

Generating accessible PDFs with the Convert document flow block

To generate an accessible PDF at runtime, configure your flow to convert generated documents to PDF/UAs by performing the steps below.

1.

Add a Convert document flow block to your Smart Flow.

2.

Configure the output format as PDF.

3.

Set the Compliance level to PDF/UA.

During conversion, Smart Flows will attempt to convert the generated document to a PDF/UA.

Validating the converted file

The Convert document flow block exposes two outputs that can be used for validation and control:

• Compliance test passed: A boolean (true/false) value indicating whether the converted PDF passed the PDF/UA compliance test.

• Compliance test result: An XML output containing detailed information about accessibility issues if the test failed. This includes what elements need remediation.

Using these two output parameters of the Convert document flow block you can verify that the PDF outputs your flows produce are compliant with the PDF/UA specification and, if not, what needs improvement.

Driving conditional logic based on accessibility results

One of the key strengths of Smart Flows is the ability to use runtime outputs to control flow behavior, without coding. You can use this strength to build conditionality in your flows based on the accessibility compliance test result.

Typical patterns include:

• If compliance test passed = true → Continue the flow (delivery, archiving, e‑signature, etc.).

• If compliance test passed = false → Route the document for remediation before delivery.

For example, you can:

• Use an Edit document flow block to allow a user to fix accessibility issues

• Notify a responsible user or team

• Prevent non‑accessible documents from being sent externally

This ensures that only accessible documents reach recipients.

Summary: Accessible documents by design and by automation

Accessibility is both a regulatory requirement and a core principle of inclusive communication. While accessibility discussions often focus on web content, digital documents remain a critical and frequently overlooked part of the end-to-end user experience. For the people who rely on accessible documents, getting this right is not optional; it makes the difference between access and exclusion.

With Experlogix Smart Flows, accessibility can be built into your document automation lifecycle rather than treated as an afterthought:

• Design time: by applying accessible document design best practices, setting correct metadata, such as document titles, using semantic structures, and validating templates with Microsoft Word’s Accessibility Checker.

• Preview and validation: by generating accessible PDFs and running PDF/UA compliance checks directly during template preview, with clear, actionable validation feedback.

• Runtime: by automatically validating PDF/UA compliance during document conversion and capturing structured compliance results.

• Flow logic: by using compliance outcomes to drive conditional branching, allowing only accessible documents to proceed or routing non-compliant documents for correction before delivery.

By embedding accessibility directly into templates, previews, and flows, Experlogix enables organizations to consistently produce inclusive, compliant, and future-proof digital documents, without custom code and without adding operational complexity.

Accessibility Features: License and Release Dates

Feature	Version	Release Date	Licensing
Template Builder - Set dynamic value for Convert to Image > Description in Mapping > Settings	4.26+	November 2025	Included in all licenses
PDF/UA validation for Template > Preview	4.26+	November 2026	Included in all licenses
Convert document flow block supporting PDF/UA compliance level	4.26+	November 2026	Included in all licenses