Accessibility

Ensuring that web applications follow accessibility best practices ensures that everyone can use your product, including those with motor, visual, or other impairments.

WebViewer 11.0 introduced robust accessibility features achieving WCAG 2.1 AA compliance for the UI which ensures the application meets globally recognized standards for accessibility. This compliance guarantees that individuals with disabilities can effectively perceive, navigate, and interact with the application.

The accessibility features in WebViewer enable seamless navigation through the user interface using keyboard navigation, screen readers, and other assistive tools. Most of these features are permanently enabled to improve the overall accessibility of the application. Additionally, by setting accessibleMode to true in your WebViewer constructor options, you can activate extra accessibility features.

1Webviewer(
2 {
3   initialDoc: hashFile,
4   path: "/lib",
5   initialDoc: "/samples/files/cheetahs.pdf",
6   accessibleMode: true, // Enable accessible mode
7 },
8 document.getElementById("viewer")
9).then((instance) => {
10 // ...
11});

Enabling accessible mode will cause two main changes to the user interface.

There will be a “Skip To” section that appears when the user begins tabbing through the page content

Selecting the 'Document' option in the 'Skip To' menu and pressing the Enter key moves the focus to the current page of the file. If a screen reader is active, users can navigate through the document's content using standard navigation keys.

Each PDF page will be focusable, with the file content extracted from the document and inserted into the DOM. For PDF files, the application activates the accessible reading order mode, which enables screen readers to navigate and read each piece of content—such as paragraphs or image descriptions—individually as users navigate using arrow keys. This mode ensures an optimized reading experience but may be disabled when certain actions are performed or specific features are enabled. For XOD files, the screen reader processes the content of each page as a whole, reading it out in its entirety. Users can navigate between pages to hear the content sequentially. Details about the accessible reading order mode and its behavior will be explained in the next section.

The Accessible Reading Order Mode is a feature designed specifically for tagged PDF files to enhance accessibility for screen readers. This mode works only for PDFs that are correctly tagged with semantic information about the document's structure.

Tags define the logical reading order and content hierarchy, including elements such as headings, paragraphs, lists, tables, and images. If tags are missing or improperly structured, the reading order may not align with the visual layout, potentially leading to accessibility challenges.

When Accessible Reading Order Mode is enabled, it builds and inserts the document structure into the DOM based on the file's tags, allowing screen readers to interpret and navigate the content effectively.

For untagged PDFs, the document structure will not be added to the DOM. In such cases, screen readers will treat the PDF similarly to XOD files, reading the content of each page as a whole. While users can navigate between pages, detailed navigation within a single page is not supported.

Accessible Reading Order Mode will automatically end when actions or modes that alter the document's structure are executed or enabled. These changes can disrupt the accessibility features provided by the mode.

The specific actions, modes, and features that terminate the Accessible Reading Order Mode are:

• Multiviewer and Compare Pages Modes
• Content Edit Mode
• Form Builder Mode
• Apply a Redaction
• Add a Portfolio
• Cropping pages
• MultipleViewerMerging
• ThumbnailMerging
• ThumbnailReordering
• Outline Editing
• Page manipulation

To enhance the performance of the Accessible Reading Order Mode, particularly when working with larger PDF files, you can use the setPreProcessingLevel API. This API allows you to specify the number of pages to pre-render in advance, improving navigation smoothness.

The setPreProcessingLevel API accepts a number indicating how many pages of the document should be pre-rendered. By pre-rendering these pages, the document structure for those pages is built and inserted into the DOM to ensure they are available for reading. If pages aren't pre-rendered, users could run into situations where they need to wait for pages to load if they navigate to a page before it is available.

• Higher Pre-Processing Level: Specifies that more pages will be pre-rendered in advance. This improves navigation smoothness for the pre-rendered pages but increases the initial document loading time, particularly for larger files.
• Lower Pre-Processing Level: Specifies fewer pages to pre-render, resulting in faster initial loading times. However, navigating quickly to pages beyond the pre-rendered range may introduce additional loading time.

1// Set the pre-processing level to pre-render the first 10 pages
2const AccessibleReadingOrderManager = instance.Core.documentViewer.getAccessibleReadingOrderManager()
3AccessibleReadingOrderManager.setPreProcessingLevel(10);

WebViewer also provides a reader mode which displays the text in a reflowable layout and the text size can be increased or decreased. Check out the reader mode guide to learn more.