Accessibility
We often get asked if BuildVu produces output that is compliant with accessibility acts such as ADA, EAA, AODA, AMA, etc. A simple question, but the answer is not a simple “yes” or “no”. The acts themselves cover many things, primarily in the physical world, for example ensuring your building is accessible by someone in a wheelchair, or ensuring your phone service has an alternative for someone who is deaf.
When it comes to accessibility of content on the web, the acts themselves are not prescriptive in terms of what needs to be done to be compliant. The Americans with Disabilities Act (ADA) of 1990, for example, doesn’t mention the internet at all. Fortunately, other standards exist that can guide us in making content accessible. On the web, this means conforming to the Web Content Accessibility Guidelines (WCAG) 2.
Now that we know what our goal is, it’s important to also consider that we are converting from one format to another (in this case, from PDF to HTML). As with any translation from one format or language to another, trade-offs must be made if a direct equivalent for a particular feature does not exist. Plus, if the quality of the input (PDF) is poor or doesn’t make use of accessibility features then the quality of the output (HTML) will also be affected.
The fact we are dealing with PDF as the source format is an especially important point. The PDF file format started life as a format for printing before it became a format for displaying documents on screens. This means the file format itself is internally structured in a way that makes it really good at ensuring a document looks the same everywhere, but less good at storing the content in an accessible way. An example of this is that what your eye may perceive as a heading, a paragraph, or a table is actually stored internally as rows of text and shapes to be drawn at given coordinates.
The PDF file format has evolved to adopt new features that make it much better at accessibility (for example being able to tag the document structure), but not every document contains the extra information. Older documents in particular will not, and newer documents might have been created without it, limiting the accessibility of the document. Furthermore, PDF is a fixed layout format, which means some accessibility features such as increasing the font size or line height are not possible. Irrespective of the features, an author could also create a document with poor accessibility by using a difficult to read font or using colors with poor contrast, for example.
In terms of if the output that BuildVu produces is compliant with the accessibility acts, let’s break it down into two areas: the viewer itself, and the document’s content.
Accessibility of the viewer
The BuildVu 2025.04 release includes changes to help ensure the IDRViewer (specifically the ‘Complete’ UI) meets the requirements of the Web Content Accessibility Guidelines (WCAG) 2.0. This is the accepted standard when it comes to compliance with acts such as ADA, EAA, AMA, etc.
For example, the ‘Complete’ UI:
- Meets color contrast guidelines (WCAG AA)
- Is keyboard accessible
- Is compatible with assistive technologies such as screen readers
Accessibility of the content
The document content is accessible insofar as it uses real, selectable text which is accessible to screen readers. BuildVu doesn’t currently make use of document tagging (of headings, paragraphs, etc) if it is provided. We will be investigating if we can make better use of this.
We cannot guarantee the accessibility of converted documents as this relies on the source PDF documents meeting accessibility standards (we cannot turn an inaccessible PDF into accessible HTML).
We can say that if a PDF document is well-formed and meets accessibility standards, then the converted HTML would also be compatible with assistive technologies such as screen readers.