Background
I'm working on a solution for displaying PDFs, that has very specific requirements. Basically we need to manage placement of editable fields on top of these user-uploaded documents, for purposes of electronic signing. We've decided what works best for our engineering needs is to render a canvas layer that displays the PDF image, along with a text layer for the corresponding text content from the document.
The text should be available for use by screen reader and other user interaction, e.g. highlighting. However, we don't want to have to worry about the text layer perfectly matching the image pixel for pixel, just nearly the same placement as the image, so we've made the text layer transparent. I suppose the text is hidden, but it's not. Using the aria-hidden
attribute would hide the text from screen reader use. Very simplified markup:
<div>
<!-- The PDF document "image" is rendered here via our JS processes. The image will almost always be some black-and-white form. -->
<canvas id="image-layer" />
<!-- The text content of the PDF document is rendered here via our JS processes, placing it nearly directly over the image layer, so as to line up with it as close as possible, but transparent in color. -->
<div id="text-layer" style="opacity: 0">
<p>various elements containing text here</p>
</div>
Question
This isn't technically WCAG compliant because of the incorrect text color contrast ratio to the background. But practically speaking, I believe it is compliant because the text is visible and available for use. I'm curious, what if anything can or should be done to make this text layer markup technically compliant?
The solution seems quite elegant because it’s simple, allows for semantic markup in the text and it being read out by screen readers by following the cursor.
And you don’t have to worry about contrast, if your Image of text provides enough contrast (4.5:1 for WCAG AA). The transparent text can be seen as the text alternative for the image.
But an image of text will fail Criterion 1.4.5 Images of Text (Level AA), if it’s not adjustable by the user.
And there are other requirements for adjustment of text contents, that an image will fail:
The transparent text would adapt, but is not visible. Additionally, it would no longer match the layout of the image.
To make document signing accessible, the document itself needs to be accessible. Good PDF readers fulfil the above criteria, there might be ready to use libraries out there, like PDF.js by Mozilla
I guess there are legal implications as well: Is the signature valid, if the user cannot have read the document?
There’s also an interesting discussion about accessibility of user generated content here: WCAG 2.1 AA Compliance and User-Generated Content - what do you do with content that you don't control?
Suggested solution
The app might mark a document as accessible or not, before the user can go about signing it.
If it’s not accessible, the text contents can be directly viewed (without overlaying the image) and signed.
The signature metadata then must clarify that the signing user only had access to the text contents.