WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Do fonts have to be embedded in a WCAG 2.0 conformingPDFdocument?

for

From: Chagnon | PubCom
Date: Apr 15, 2015 9:49AM

Commenting on Duff's response:

Duff: "The lack of embedded fonts can cause a range of issues varying from (merely) an unintended ugly appearance to total illegibility."

True, but if fonts are not embedded in the PDF, Acrobat is designed to substitute default fonts like Times New Roman (serif) and Arial (sans serif). Acrobat used to install with their proprietary default fonts called Adobe Sans and Adobe Sans Serif, but I don't know if that is still the case in the most recent versions of Acrobat.

But, those substituted fonts are scalable (resizable) so their legibility should be ok to meet WCAG. I've never seen a case where the substituted font is a bitmapped font rather than a vector/scalable font; of course, bitmapped fonts aren't resizable. You do miss the aesthetic aspects of the font when, for example, Times New Roman is substituted for a missing handwritten script font. Extremely different appearance, but that's not WCAG.

Duff: "Font embedding is also necessary for Unicode mapping of text, affecting adaptability and reuse, and allowing recovery of semantic properties for each character of the textual content."

Absolutely! And this will continue to become more important as both AT and other publishing technologies start to recognize the difference between, for example, quote mark-like glyphs. In non-Unicode fonts, there's only one symbol to represent open and closed quotes, inches, minutes, and GPS coordinates, so who knows how a screen reader will voice it. But Unicode has specific characters for them which can trigger the appropriate voicing (or interpretation by other technologies). Well, should trigger the appropriate voicing...we're not there yet!

Bottom line:
Use Unicode fonts. Ditch the old TrueType and PostScript fonts.
Check the box to embed them when making PDFs (subset is less than 100% of the characters are used).
And use embeddable fonts. Some fonts are protected, which prevents them from being embedded into PDFs.

--Bevi Chagnon

— — —
Bevi Chagnon | www.PubCom.com
Technologists, Consultants, Trainers, Designers, and Developers
for publishing & communication
— — —




-----Original Message-----
From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of Duff Johnson
Sent: Wednesday, April 15, 2015 9:39 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Do fonts have to be embedded in a WCAG 2.0 conforming PDF document?

OK, some background...

Embedded font programs allow software to correctly reproduce all glyphs without reference to external resources.

To answer Patrick's question: embedding ensures reliable presentation of the document's text because the viewer is not forced to substitute fonts that may not match the usage specified in the document.

The lack of embedded fonts can cause a range of issues varying from (merely) an unintended ugly appearance to total illegibility.

So font embedding clearly applies to Principle 1.

Font embedding is also necessary for Unicode mapping of text, affecting adaptability and reuse, and allowing recovery of semantic properties for each character of the textual content.

So font embedding clearly applies to Guideline 1.3.

>> What is your understanding of this point? Does WCAG 2.0 require font embedding in PDF documents, or not?
>
> It really depends on if when the font is not embedded a success criteria is not met.

But which SC? The issue seems to fit the high-order requirements (Principles and Guidelines) more than any specific SC.

> If you can show a case such as a failure of SC 1.4.4 Text Resize when fonts aren't embedded then I think there is a good case for it.

A viewer that substitutes fonts due to a lack of embedded fonts might still be able to resize whatever text it managed to display, but its functionality would be just as unpredictable as a viewer that was not trying to resize text.

> Otherwise it would be difficult to argue unless there is some other SC such as 1.3.1 which might apply to font attributes not being available such as underline, bold, etc. as there are few semantic tag equivalents to this communicate this information.

In PDF, underline is indicated (for accessibility purposes) by an attribute called TextDecorationType, which may be applied irrespective of font embedding.

Duff.