E-mail List Archives
Thread: Do fonts have to be embedded in a WCAG 2.0 conforming PDF document?
Number of posts in this thread: 23 (In chronological order)
From: Duff Johnson
Date: Tue, Apr 14 2015 11:01PM
Subject: Do fonts have to be embedded in a WCAG 2.0 conforming PDF document?
No previous message | Next message →
All,
Someone told me today that it's possible to conform to WCAG 2.0 without embedding fonts in PDF documents.
There are no âofficial' WCAG 2.0 PDF Techniques specific to this subject (I just checked).
What is your understanding of this point? Does WCAG 2.0 require font embedding in PDF documents, or not?
Thanks,
Duff.
From: Patrick H. Lauke
Date: Wed, Apr 15 2015 1:46AM
Subject: Re: Do fonts have to be embedded in a WCAG 2.0 conforming PDF document?
← Previous message | Next message →
On 15/04/2015 07:01, Duff Johnson wrote:
> All,
>
> Someone told me today that it's possible to conform to WCAG 2.0 without embedding fonts in PDF documents.
>
> There are no âofficial' WCAG 2.0 PDF Techniques specific to this subject (I just checked).
>
> What is your understanding of this point? Does WCAG 2.0 require font embedding in PDF documents, or not?
A quick note that WCAG 2.0 does not *require* any specific
technology/technique to be used. So even if there was a specific
technique that said "Embed fonts in PDFs" that would not mean that WCAG
2.0 requires it, as techniques are only informative, not normative.
In a wider sense, what success criterion do you think is related to
whether or not fonts are embedded? I.e. if fonts are not embedded, what
SC do you think is failing? If that failure can be turned into a
pass/success if fonts *are* enabled, then that is justification enough
for embedding the fonts.
P
--
Patrick H. Lauke
www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke
From: Duff Johnson
Date: Wed, Apr 15 2015 4:46AM
Subject: Re: Do fonts have to be embedded in a WCAG 2.0 conforming PDF document?
← Previous message | Next message →
Hi Patrick,
>> Someone told me today that it's possible to conform to WCAG 2.0 without embedding fonts in PDF documents.
>>
>> There are no âofficial' WCAG 2.0 PDF Techniques specific to this subject (I just checked).
>>
>> What is your understanding of this point? Does WCAG 2.0 require font embedding in PDF documents, or not?
>
> A quick note that WCAG 2.0 does not *require* any specific technology/technique to be used. So even if there was a specific technique that said "Embed fonts in PDFs" that would not mean that WCAG 2.0 requires it, as techniques are only informative, not normative.
Understood. I included that statement as information pertaining to my question, not to imply that Techniques are normative.
> In a wider sense, what success criterion do you think is related to whether or not fonts are embedded?
At this point I'm preferring to focus on learning what others think of the question rather than offering my own answer.
> I.e. if fonts are not embedded, what SC do you think is failing? If that failure can be turned into a pass/success if fonts *are* enabled, then that is justification enough for embedding the fonts.
So⦠what do you think? Which SC applies, if any?
Duff.
From: Patrick H. Lauke
Date: Wed, Apr 15 2015 6:03AM
Subject: Re: Do fonts have to be embedded in a WCAG 2.0 conforming PDF document?
← Previous message | Next message →
On 15/04/2015 12:46, Duff Johnson wrote:
>> I.e. if fonts are not embedded, what SC do you think is failing? If that failure can be turned into a pass/success if fonts *are* enabled, then that is justification enough for embedding the fonts.
>
> So⦠what do you think? Which SC applies, if any?
Well, what is the problem that can arise when fonts aren't embedded?
P
From: Jonathan Avila
Date: Wed, Apr 15 2015 6:41AM
Subject: Re: Do fonts have to be embedded in a WCAG 2.0 conforming PDF document?
← Previous message | Next message →
> Well, what is the problem that can arise when fonts aren't embedded?
The idea as I understand it is that glyphs can be rendered differently such as enlarged when the font is embedded properly. While many people think non-scanned PDFs are not images they are actually rendered glyphs. I don't know all of the details and I know PDF/UA goes more into this topic -- but it would be good to hear from a PDF Guru as to whether not embedded fonts could impact SC 1.4.4. I'm sure someone could also put together some test files to compare how enlargement and reflow works in these different situations.
In addition, embedding the fonts allows you to change or fix things in the document with the original font. For example, say there is a typo and you need to correct it.
Jonathan
--
Jonathan Avila
Chief Accessibility Officer
SSB BART Group
= EMAIL ADDRESS REMOVED =
703-637-8957 (o)
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Patrick H. Lauke
Sent: Wednesday, April 15, 2015 8:04 AM
To: = EMAIL ADDRESS REMOVED =
Subject: Re: [WebAIM] Do fonts have to be embedded in a WCAG 2.0 conforming PDF document?
On 15/04/2015 12:46, Duff Johnson wrote:
>> I.e. if fonts are not embedded, what SC do you think is failing? If that failure can be turned into a pass/success if fonts *are* enabled, then that is justification enough for embedding the fonts.
>
> So⦠what do you think? Which SC applies, if any?
Well, what is the problem that can arise when fonts aren't embedded?
P
From: Jonathan Avila
Date: Wed, Apr 15 2015 6:44AM
Subject: Re: Do fonts have to be embedded in a WCAG 2.0 conforming PDFdocument?
← Previous message | Next message →
> 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. 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. 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.
Jonathan
--
Jonathan Avila
Chief Accessibility Officer
SSB BART Group
= EMAIL ADDRESS REMOVED =
703-637-8957 (o)
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Duff Johnson
Sent: Wednesday, April 15, 2015 1:02 AM
To: WebAIM Discussion List
Subject: [WebAIM] Do fonts have to be embedded in a WCAG 2.0 conforming PDF document?
All,
Someone told me today that it's possible to conform to WCAG 2.0 without embedding fonts in PDF documents.
There are no âofficial' WCAG 2.0 PDF Techniques specific to this subject (I just checked).
What is your understanding of this point? Does WCAG 2.0 require font embedding in PDF documents, or not?
Thanks,
Duff.
From: Duff Johnson
Date: Wed, Apr 15 2015 7:38AM
Subject: Re: Do fonts have to be embedded in a WCAG 2.0 conforming PDFdocument?
← Previous message | Next message →
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.
From: Jonathan Avila
Date: Wed, Apr 15 2015 7:48AM
Subject: Re: Do fonts have to be embedded in a WCAG 2.0 conformingPDFdocument?
← Previous message | Next message →
> The lack of embedded fonts can cause a range of issues varying from (merely) an unintended ugly appearance to total illegibility.
Regarding WCAG -- how is the experience specifically for people with disabilities impacted over the experience of people without disabilities. It seems that this is an overall usability issue for all people -- but WCAG is focused on situations where comparable or equivalent access is not provided to people with disabilities.
Jonathan
--
Jonathan Avila
Chief Accessibility Officer
SSB BART Group
= EMAIL ADDRESS REMOVED =
703-637-8957 (o)
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS 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.
From: Chagnon | PubCom
Date: Wed, Apr 15 2015 9:49AM
Subject: Re: Do fonts have to be embedded in a WCAG 2.0 conformingPDFdocument?
← Previous message | Next message →
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 ADDRESS 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.
From: Duff Johnson
Date: Wed, Apr 15 2015 10:11AM
Subject: Re: Do fonts have to be embedded in a WCAG 2.0 conforming PDFdocument?
← Previous message | Next message →
>
>> The lack of embedded fonts can cause a range of issues varying from (merely) an unintended ugly appearance to total illegibility.
>
> Regarding WCAG -- how is the experience specifically for people with disabilities impacted over the experience of people without disabilities.
Examples...
- Some users may depend on characteristics such as word-spacing, line-spacing, text alignment, etc to understand the document. As one example, imagine a screen magnifier user dealing with text in which the breaks between words aren't clear, or where characters overlap. A conventional user might have the problem to a limited extent, but the user running the magnifier is much more likely to be very seriously affected.
- AT software that replaces or manipulates fonts (for example to accommodate those with dyslexia) will not be able to function predictably (if at all).
> It seems that this is an overall usability issue for all people
It is certainly that, but it also disproportionally affects users with disabilities.
> -- but WCAG is focused on situations where comparable or equivalent access is not provided to people with disabilities.
Agreed, and I believe font embedding is such as case.
â¦but which SC?
Duff.
From: Moore,Michael (DARS)
Date: Wed, Apr 15 2015 11:14AM
Subject: Re: Do fonts have to be embedded in a WCAG 2.0 conformingPDFdocument?
← Previous message | Next message →
From a functionality standpoint we have found that embedding fonts, particularly in PDF forms is problematic. This issue is that the PDF reader software will embed the fonts over and over again when a form is saved. Thus if a form is passed through a process where several people complete different sections, save the form and pass it to the next person the file size quickly becomes too large to fit through an email system. This has been particularly problematic for forms developed through LiveCycle Designer. We have been able to develop forms that have worked reliably for people using a wide range of assistive technologies on Windows systems. Still waiting for Adobe and Apple to work out their differences though. I don't know of a form technology other than HTML that is working correctly on MAC OS or IOS.
Mike Moore
Accessibility Coordinator,
Texas Department of Assistive and Rehabilitative Services
(512) 424-4159 (Office)
(512) 574-0091 (Cell)
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Duff Johnson
Sent: Wednesday, April 15, 2015 11:11 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Do fonts have to be embedded in a WCAG 2.0 conforming PDF document?
>
>> The lack of embedded fonts can cause a range of issues varying from (merely) an unintended ugly appearance to total illegibility.
>
> Regarding WCAG -- how is the experience specifically for people with disabilities impacted over the experience of people without disabilities.
Examples...
- Some users may depend on characteristics such as word-spacing, line-spacing, text alignment, etc to understand the document. As one example, imagine a screen magnifier user dealing with text in which the breaks between words aren't clear, or where characters overlap. A conventional user might have the problem to a limited extent, but the user running the magnifier is much more likely to be very seriously affected.
- AT software that replaces or manipulates fonts (for example to accommodate those with dyslexia) will not be able to function predictably (if at all).
> It seems that this is an overall usability issue for all people
It is certainly that, but it also disproportionally affects users with disabilities.
> -- but WCAG is focused on situations where comparable or equivalent access is not provided to people with disabilities.
Agreed, and I believe font embedding is such as case.
â¦but which SC?
Duff.
From: Andrew Kirkpatrick
Date: Wed, Apr 15 2015 1:06PM
Subject: Re: Do fonts have to be embedded in a WCAG 2.0 conformingPDFdocument?
← Previous message | Next message →
Catching up on this thread...
Can you have a WCAG 2.0-conforming PDF document without embedded fonts? Yes.
Will all users be able to read the text in that document? No, not always.
When you don't embed a font in a PDF document the textual information still exists within the document and is used to populate the accessibility structure for the document. If you don't embed the font then Adobe Acrobat Reader (and earlier versions of Reader) will map the text information to a Latin-1 font. If you are starting with a font that uses the same characters as a Latin-1 font then Reader will do its best to match the font by name or by appearance with a font that the user has available on their system.
The situation is very much like in HTML when an author references a font that they have on their system but that other end-users may not. Browsers can make their best guess, and that may work out in many cases but not all.
Is having a font that is different from the author's original intent an accessibility issue? I don't think so.
> - Some users may depend on characteristics such as word-spacing, line-spacing, text alignment, etc to understand the document. As one example, imagine a screen magnifier user dealing with text in which the breaks between words aren't clear, or where characters overlap. A conventional user might have the problem to a limited extent, but the user running the magnifier is much more likely to be very seriously affected.
But this is no different an issue than if an author chose one of the fonts that the PDF reader used as the replacement when creating the document to begin with, so I disagree that this is an accessibility issue.
> - AT software that replaces or manipulates fonts (for example to accommodate those with dyslexia) will not be able to function predictably (if at all).
I don't understand why this would be a problem. If the AT discards the font that is referenced and replaces it with a different font that is available, how does a negative result present?
>> It seems that this is an overall usability issue for all people
> It is certainly that, but it also disproportionally affects users with disabilities.
I'm not sure how that is an accurate statement yet. As far as I can tell it isn't having a disproportionate effect.
> â¦but which SC?
Barring additional new information I'd say "none".
AWK
From: Olaf Drümmer
Date: Wed, Apr 15 2015 1:46PM
Subject: Re: Do fonts have to be embedded in a WCAG 2.0 conformingPDFdocument?
← Previous message | Next message →
Not embedding a font could lead to a situation where visually presenting a PDF depends on certain resources to be available (and visual presentation would fail to be useful if such resource is missing). Due to the way PDF works, the situation is not the same as in HTML-land, where a user agent for visual presentation is prepared to at least support all the scripts that the user of the user agent will understand (and lots of HTML pages do not reference a specific font file or specific font resource anyway, though this is currently changing, albeit typically with reasonable fallbacks in place).
We Westerners do not necessarily run into issues with non-embedded fonts in PDF because tools do an excellent job in providing a fallback - though limited to what Andrew introduced as "Latin-1" (a set of characters used in 'Western' regions, i.e. most of Western Europe and the Americas). Take Cyrillic or Greek scripts, and you are looking at a completely different story, not to mention scripts in Thailand, India, China, Japan, Korea, or Arabic and Hebrew scriptsâ¦
Along the same lines a PDF file claiming to be accessible must also always ensure that each and every piece of text can be interpreted on the background of Unicode.
Both - embedded fonts and complete mapping to Unicode - are two absolute requirements to enable accessibility. That's why they are required in the PDF/UA standard. Based on its tendency to be technology agnostic, WCAG2 seems to miss the boat in this regard when it comes to PDF.
Olaf
On 15 Apr 2015, at 21:06, Andrew Kirkpatrick < = EMAIL ADDRESS REMOVED = > wrote:
> Catching up on this thread...
>
> Can you have a WCAG 2.0-conforming PDF document without embedded fonts? Yes.
>
> Will all users be able to read the text in that document? No, not always.
>
> When you don't embed a font in a PDF document the textual information still exists within the document and is used to populate the accessibility structure for the document. If you don't embed the font then Adobe Acrobat Reader (and earlier versions of Reader) will map the text information to a Latin-1 font. If you are starting with a font that uses the same characters as a Latin-1 font then Reader will do its best to match the font by name or by appearance with a font that the user has available on their system.
>
> The situation is very much like in HTML when an author references a font that they have on their system but that other end-users may not. Browsers can make their best guess, and that may work out in many cases but not all.
>
> Is having a font that is different from the author's original intent an accessibility issue? I don't think so.
>
>> - Some users may depend on characteristics such as word-spacing, line-spacing, text alignment, etc to understand the document. As one example, imagine a screen magnifier user dealing with text in which the breaks between words aren't clear, or where characters overlap. A conventional user might have the problem to a limited extent, but the user running the magnifier is much more likely to be very seriously affected.
>
> But this is no different an issue than if an author chose one of the fonts that the PDF reader used as the replacement when creating the document to begin with, so I disagree that this is an accessibility issue.
>
>> - AT software that replaces or manipulates fonts (for example to accommodate those with dyslexia) will not be able to function predictably (if at all).
>
> I don't understand why this would be a problem. If the AT discards the font that is referenced and replaces it with a different font that is available, how does a negative result present?
>
>>> It seems that this is an overall usability issue for all people
>
>> It is certainly that, but it also disproportionally affects users with disabilities.
>
> I'm not sure how that is an accurate statement yet. As far as I can tell it isn't having a disproportionate effect.
>
>> â¦but which SC?
>
> Barring additional new information I'd say "none".
>
> AWK
> > > >
From: Andrew Kirkpatrick
Date: Wed, Apr 15 2015 2:48PM
Subject: Re: Do fonts have to be embedded in a WCAG 2.0conformingPDFdocument?
← Previous message | Next message →
Olaf,
Would you say that a PDF that is all in French, uses adobe's internal font (which is not available externally - adobe clean), and does all of the things that are needed to expose accessible information except doesn't embed the font is going to cause issues for any users? If so, what?
Andrew Kirkpatrick
> On Apr 15, 2015, at 3:46 PM, Olaf Drümmer < = EMAIL ADDRESS REMOVED = > wrote:
>
> Not embedding a font could lead to a situation where visually presenting a PDF depends on certain resources to be available (and visual presentation would fail to be useful if such resource is missing). Due to the way PDF works, the situation is not the same as in HTML-land, where a user agent for visual presentation is prepared to at least support all the scripts that the user of the user agent will understand (and lots of HTML pages do not reference a specific font file or specific font resource anyway, though this is currently changing, albeit typically with reasonable fallbacks in place).
>
> We Westerners do not necessarily run into issues with non-embedded fonts in PDF because tools do an excellent job in providing a fallback - though limited to what Andrew introduced as "Latin-1" (a set of characters used in 'Western' regions, i.e. most of Western Europe and the Americas). Take Cyrillic or Greek scripts, and you are looking at a completely different story, not to mention scripts in Thailand, India, China, Japan, Korea, or Arabic and Hebrew scriptsâ¦
>
> Along the same lines a PDF file claiming to be accessible must also always ensure that each and every piece of text can be interpreted on the background of Unicode.
>
>
> Both - embedded fonts and complete mapping to Unicode - are two absolute requirements to enable accessibility. That's why they are required in the PDF/UA standard. Based on its tendency to be technology agnostic, WCAG2 seems to miss the boat in this regard when it comes to PDF.
>
>
> Olaf
>
>
>
>> On 15 Apr 2015, at 21:06, Andrew Kirkpatrick < = EMAIL ADDRESS REMOVED = > wrote:
>>
>> Catching up on this thread...
>>
>> Can you have a WCAG 2.0-conforming PDF document without embedded fonts? Yes.
>>
>> Will all users be able to read the text in that document? No, not always.
>>
>> When you don't embed a font in a PDF document the textual information still exists within the document and is used to populate the accessibility structure for the document. If you don't embed the font then Adobe Acrobat Reader (and earlier versions of Reader) will map the text information to a Latin-1 font. If you are starting with a font that uses the same characters as a Latin-1 font then Reader will do its best to match the font by name or by appearance with a font that the user has available on their system.
>>
>> The situation is very much like in HTML when an author references a font that they have on their system but that other end-users may not. Browsers can make their best guess, and that may work out in many cases but not all.
>>
>> Is having a font that is different from the author's original intent an accessibility issue? I don't think so.
>>
>>> - Some users may depend on characteristics such as word-spacing, line-spacing, text alignment, etc to understand the document. As one example, imagine a screen magnifier user dealing with text in which the breaks between words aren't clear, or where characters overlap. A conventional user might have the problem to a limited extent, but the user running the magnifier is much more likely to be very seriously affected.
>>
>> But this is no different an issue than if an author chose one of the fonts that the PDF reader used as the replacement when creating the document to begin with, so I disagree that this is an accessibility issue.
>>
>>> - AT software that replaces or manipulates fonts (for example to accommodate those with dyslexia) will not be able to function predictably (if at all).
>>
>> I don't understand why this would be a problem. If the AT discards the font that is referenced and replaces it with a different font that is available, how does a negative result present?
>>
>>>> It seems that this is an overall usability issue for all people
>>
>>> It is certainly that, but it also disproportionally affects users with disabilities.
>>
>> I'm not sure how that is an accurate statement yet. As far as I can tell it isn't having a disproportionate effect.
>>
>>> â¦but which SC?
>>
>> Barring additional new information I'd say "none".
>>
>> AWK
>> >> >> >> >
> > > >
From: Olaf Drümmer
Date: Wed, Apr 15 2015 3:06PM
Subject: Re: Do fonts have to be embedded in a WCAG 2.0conformingPDFdocument?
← Previous message | Next message →
Andrew,
On 15 Apr 2015, at 22:48, Andrew Kirkpatrick < = EMAIL ADDRESS REMOVED = > wrote:
> Would you say that a PDF that is all in French, uses adobe's internal font (which is not available externally - adobe clean), and does all of the things that are needed to expose accessible information except doesn't embed the font is going to cause issues for any users? If so, what?
last time I checked France was still in the Western world - I was already stating that users are less likely to encounter problems looking at a PDF without fonts embedded if all the text is e.g. French.
Just to make that side clear: visual presentation is a very relevant option also from an accessibility point of view - most users with disabilities have a disability that is not sight related.
So what is it I am missing in your question?
Olaf
PS: As an aside, I would prefer to not have this discussion tied to a specific viewer implementation (be that Adobe's implementation or FoxIt's or Apple's or Nitro's or someone else's - all of which do support rendering of "Latin 1" text even if fonts are not embedded; strictly speaking, only Helvetica/Times/Courier/Symbol/ZapfDingbats are required to be present to the viewer application; this does imply that at least formally the same does not apply to all the other fonts once could use for Latin 1; it's for a reason that font embedding is considered best practice regardless where/in which industry you are. As a logical consequence using Adobe applications for example it has become next to impossible for the average user to create PDFs where fonts are not embedded). Also, I do not see how a PDF can use a font that is not available externally?
From: Andrew Kirkpatrick
Date: Wed, Apr 15 2015 3:17PM
Subject: Re: Do fonts have to be embedded in a WCAG2.0conformingPDFdocument?
← Previous message | Next message →
Yes, France is still in the western world! :) that's part of the point of my scenario.
Given that - what accessibility issues would you expect in that scenario?
Andrew Kirkpatrick
> On Apr 15, 2015, at 5:06 PM, Olaf Drümmer < = EMAIL ADDRESS REMOVED = > wrote:
>
> Andrew,
>
>> On 15 Apr 2015, at 22:48, Andrew Kirkpatrick < = EMAIL ADDRESS REMOVED = > wrote:
>>
>> Would you say that a PDF that is all in French, uses adobe's internal font (which is not available externally - adobe clean), and does all of the things that are needed to expose accessible information except doesn't embed the font is going to cause issues for any users? If so, what?
>
>
> last time I checked France was still in the Western world - I was already stating that users are less likely to encounter problems looking at a PDF without fonts embedded if all the text is e.g. French.
>
> Just to make that side clear: visual presentation is a very relevant option also from an accessibility point of view - most users with disabilities have a disability that is not sight related.
>
>
> So what is it I am missing in your question?
>
>
> Olaf
>
>
> PS: As an aside, I would prefer to not have this discussion tied to a specific viewer implementation (be that Adobe's implementation or FoxIt's or Apple's or Nitro's or someone else's - all of which do support rendering of "Latin 1" text even if fonts are not embedded; strictly speaking, only Helvetica/Times/Courier/Symbol/ZapfDingbats are required to be present to the viewer application; this does imply that at least formally the same does not apply to all the other fonts once could use for Latin 1; it's for a reason that font embedding is considered best practice regardless where/in which industry you are. As a logical consequence using Adobe applications for example it has become next to impossible for the average user to create PDFs where fonts are not embedded). Also, I do not see how a PDF can use a font that is not available externally?
> > > >
From: Olaf Drümmer
Date: Wed, Apr 15 2015 4:45PM
Subject: Re: Do fonts have to be embedded in a WCAG2.0conformingPDFdocument?
← Previous message | Next message →
OK, looking at the Western world / Roman languages (and putting accessibility considerations for people using other scripts to the side for a moment):
Problems one could encounter when looking at visually presented PDFs for which some of all of the fonts are not embedded:
- 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 ⦠)
- 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.
- 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
I am probably forgetting a few aspects hereâ¦
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.
Olaf
PS: BTW - I get reminded of font embedding issues each month when I receive my credit card statement. The character spacing is completely off in the PDF viewer I use. For a word like "hotel" the 'o' and the 't' would move into each other, and the word just becomes difficult to decipher. And it's happening because the font is not embedded and also is not a standard font like Helvetica or Arial that could easily be simulated/substituted by a similar font.
On 15 Apr 2015, at 23:17, Andrew Kirkpatrick < = EMAIL ADDRESS REMOVED = > wrote:
> Yes, France is still in the western world! :) that's part of the point of my scenario.
>
> Given that - what accessibility issues would you expect in that scenario?
From: Andrew Kirkpatrick
Date: Wed, Apr 15 2015 7:29PM
Subject: Re: Do fonts have to be embedded in aWCAG2.0conformingPDFdocument?
← Previous message | Next message →
- 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
From: Olaf Drümmer
Date: Thu, Apr 16 2015 2:55AM
Subject: Re: Do fonts have to be embedded in aWCAG2.0conformingPDFdocument?
← Previous message | Next message →
Hi Andrew,
On 16 Apr 2015, at 03:29, Andrew Kirkpatrick < = EMAIL ADDRESS REMOVED = > wrote:
> 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
this file is a different story because it is broken - the way characters are encoded is completely wrong, as it uses a font with an undefined encoding. In this case nobody can read the information.
We need to distinguish between 'just wrong' and 'font not embedded/decreased likelihood of decent rendering'.
Olaf
From: Olaf Drümmer
Date: Thu, Apr 16 2015 2:58AM
Subject: Re: Do fonts have to be embedded in aWCAG2.0conformingPDFdocument?
← Previous message | Next message →
On 16 Apr 2015, at 03:29, Andrew Kirkpatrick < = EMAIL ADDRESS REMOVED = > wrote:
> 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
[...]
>
> That said, embedding the fonts avoids the issue so it is definitely the best practice for authors.
I do believe it might be a good idea if WCAG came up with provisions around availability of essential resources. The way to ensure availability of essential resources in PDF , when it comes to fonts, is to embed them. Things will be different for different technologies / file formats etc.
Or is there a provision in WCAG stating anything around 'essential resources'?
Olaf
From: Andrew Kirkpatrick
Date: Thu, Apr 16 2015 6:52AM
Subject: Re: Do fonts have to be embedded inaWCAG2.0conformingPDFdocument?
← Previous message | Next message →
I do believe it might be a good idea if WCAG came up with provisions around availability of essential resources. The way to ensure availability of essential resources in PDF , when it comes to fonts, is to embed them. Things will be different for different technologies / file formats etc.
Or is there a provision in WCAG stating anything around 'essential resources'?
This is something to consider for the future. I'll make a note in the WCAG wiki where we are collecting ideas.
AWK
From: L Snider
Date: Thu, Apr 16 2015 7:53AM
Subject: Re: Do fonts have to be embedded in a WCAG 2.0 conforming PDF document?
← Previous message | Next message →
I just wanted to provide my 2 cents as an archivist. I preserve, and
provide long term access to, digital documents. We hope we can provide
access 5 years from now, but we also hope we can do it 50-100 years from
now (I can only look 5 years down the line, and even 10 is a stretch).
I would encourage all of you to embed your fonts, because otherwise the
documents may become unreadable for patrons or researchers who will use
them in the future...and you will be loved, and not disliked, by the
archivist who will be archiving your documents!
Think long term when you are producing your PDFs, because otherwise they
may be lost to history (think about how much things have changed in 10
years, can you even imagine 10 years from now? I have to...)
Cheers
Lisa
Lisa Snider
Archivist
On Thu, Apr 16, 2015 at 7:52 AM, Andrew Kirkpatrick < = EMAIL ADDRESS REMOVED = >
wrote:
> I do believe it might be a good idea if WCAG came up with provisions
> around availability of essential resources. The way to ensure availability
> of essential resources in PDF , when it comes to fonts, is to embed them.
> Things will be different for different technologies / file formats etc.
>
> Or is there a provision in WCAG stating anything around 'essential
> resources'?
>
> This is something to consider for the future. I'll make a note in the
> WCAG wiki where we are collecting ideas.
>
> AWK
> > > > >
From: _mallory
Date: Thu, Apr 16 2015 12:03PM
Subject: Re: Do fonts have to be embedded in a WCAG 2.0 conforming PDF document?
← Previous message | No next message
On Wed, Apr 15, 2015 at 12:41:00PM +0000, Jonathan Avila wrote:
> > Well, what is the problem that can arise when fonts aren't embedded?
>
> The idea as I understand it is that glyphs can be rendered differently such as enlarged when the font is embedded properly. While many people think non-scanned PDFs are not images they are actually rendered glyphs. I don't know all of the details and I know PDF/UA goes more into this topic -- but it would be good to hear from a PDF Guru as to whether not embedded fonts could impact SC 1.4.4. I'm sure someone could also put together some test files to compare how enlargement and reflow works in these different situations.
My husband had to programmatically pick certain text out of PDFs with
no structure. There were no embedded fonts, just glyphs, but each glyph
was referred to in octal code which pointed to a table of characters in
the set used in the PDF.
So something about the glyph should remain the same whether the letters
are enlarged or changed colour or whatever... but I have no idea if
anything other than a postScript-reading program would be able to access
that data.
_mallory