WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Do fonts have to be embedded in aWCAG2.0conformingPDFdocument?

for

From: Andrew Kirkpatrick
Date: Apr 15, 2015 7:29PM

- character spacing 'off'
- e.g. boundaries (per space character) between words disappear, or appear where there are none
- characters move into each other / overlap each other
- justification 'off', fully justified text looks weird
- in cases where the fonts used are sub-standard, or not enough information can be figured out by a PDF viewer to do a decent simulation
- nothing is rendered for such text
- place holder characters are rendered for such text (e.g. bullet characters, or empty squares/rectangles, or … )

I agree that these are problems, but these affect all sighted users of the documents. I think that we would probably agree that a file that comes out like this (http://www.mhsonline9.rajasthan.gov.in/Documents/Vigayapti.pdf) is not readable to anyone without regard to disability (I haven't looked too closely to determine if this is in fact a font issue for this file), and there are undoubtedly less awful examples that some people could read with difficulty and others would find unreadable. I suspect that this gets quickly into the cognitive domain that the Cognitive accessibility Task Force is currently working on, but there isn't any success criteria that I would say that this fits within.

- select characters are included by some symbolic font (not uncommon for e.g. currency signs like the infamous Euro sign)
- important details are not rendered or rendered with a useless substitute presentation, might apply to currency sign, trademark sign, measurements units, sub/superscript characters (like for square or cubic meters), mathematical characters, characters representing check boxes or check marks, etc.

Characters that are replaced by a useless substitute presentation affect all users reading the page. This screenshot from a blog post I found shows parentheses being substituted with rectangles, making the formula inaccurate. This affects everyone.

- when attempting to print such documents
- printer may fail to output pages where fonts are missing in a PDF, or will use Courier which is difficult to read for just about everyone but much harder for let's say people with cognitive impairments

This seems like a repeat of the first set of issues, but printed instead of viewed on the screen.

While one could argue that a substantial portion of these are usability issues, they can be a much tougher obstacle for people with disabilities. In a way along the same lines as let's contrast: it's hard to read light grey text on white background for just about everyone, but WCAGs bothers anyway to require a minimal contrast for content to be considered visually accessible. I'd argue the same applies to fonts… (i.e. they must be available in their original form, which - for PDF - can only be achieved reliably by embedding them). Anyway - no reason to become nervous because of this aspect - PDF/UA has it covered nicely, and (in this regard as much as in lots of other regards) complements WCAG2 by filling the PDF specific gaps that stopped us from being as efficient as we could have been had authoritative and extensive PDF specific rules and guidelines been available earlier on.

I'm not nervous about this, but seek to help clarify the issue because this thread started with Duff raising the notion and discussing whether a WCAG SC addresses this. I stand by my earlier claim that a PDF document without embedded fonts can meet WCAG 2.0. It is also possible that many people will find issues with the readability of a PDF with replaced fonts, but I think that the results of such replacement would be inconsistent due to differences in font substitutions so it is incorrect to say that this is always a problem.

That said, embedding the fonts avoids the issue so it is definitely the best practice for authors.

AWK