While I was teaching… Nose to the Page (1)

Posted on

I recently had a remarkable teaching experience.

I was teaching on typographic accommodations that support visual readers with low vision. I had explained how there are more than 20  common ways to get low vision and these can attack about 15 systems in the eye and brain. This means that low vision does not manifest in a uniform way. That is one among many reasons why individual choice of typographic setting is so important for visual readers with low vision.

I had gotten to the point where I show style sheets that had worked for real people in my experience. I told the anecdote about my friend, Bob, who looked at my favorite style and said, “If I had to look at that all day, I’d puke”.  When I put up a style a woman in the middle row got very uncomfortable. She said, “Could you turn that off? It makes me ill to look at it, or I’ll have to leave the room”. I quickly changed the style sheet, and she went on to say that she finally understood what was wrong in her life. People kept shoving solutions to her visual problem at her, and they told her she was crazy for claiming that they didn’t work. She said, “When people call you crazy long enough, you begin to believe it”.

I spent the rest of the day finding a style that would please her.  With, ZoneClipper, experimental software developed by Abhay Mhatre and me, she now reads the HTML articles she needs for her work in comfort.

Had PDF been the medium, there would be no happy ending.  My student and I are both grateful for the gift of style choice we get from HTML+CSS, but PDF obstructs choice.

Don’t Blame Yourself

If you have low vision, and you have lots of trouble reading PDF files, you are not alone, and you are not doing anything wrong.  Chances are, there is no way you can make that PDF document look like you need it to look.  The reflow option on the Adobe Reader is buggy.  Saving as HTML usually introduces many errors even with properly tagged PDF.  The widely touted claim of PDF accessibility excludes you.  My advise to my community of visual readers with low vision is do not blame yourself, just dig in and treat your PDF document like it is paper.  For you and me PDF is effectively paper.

Contrast PDF With HTML

PDF does not separate content from presentation, at the level needed to support reading with low vision.  PDF allows the ability to distinguish between headings, paragraphs and lists elements even if you cannot see the text.  It enables document element navigation like heading navigation.  This is one level of separating of content from presentation, but it is incomplete.

Most other technologies allow element level detection, but they also support separation of presentation from content, all the way down to the individual letter of text. This is the level people with low vision need.  The visual style preferences of people with full sight shut readers with low vision out of reading most text.  Font sizes, visually confusing font faces, kerning, single spaced lines and disorienting color schemes like the standard black print on white background are just a few factors of presentation that  contribute to impaired perception of text.  PDF cannot remove most of these barriers.  It can adjust size and color in limited ways, but that is it.  Within a PDF file, the style and content of text are inextricably tangled.

When you contrast PDF with HTML, you understand just how limited the visual choices are for PDF.  HTML and CSS enable every change in text presentation needed to include low vision.  With HTML and CSS you can choose font family, font size, color, spacing (line, word and letter), margin size and borders.  Moreover, you can apply different presentations to different document elements.  Headings can have one look. Paragraphs can have another look that visually distinguishes them from headings.   Lists can have another look.  Visual readers with low vision need visual cues to separate the semantic elements of documents.  They are like people with full sight, they just need different visual cues.

The templates for most word processors supply a similar range of changes in presentations.  They are not as clean as HTML with CSS, but they work.  PDF is unique in its extreme inflexibility.  That is why it is inaccessible for visual readers with low vision.  It denies the freedom necessary to adjust the presentation of text. People with low vision just cannot get the flexible typography they need to read, especially professional materials.   PDF files, even tagged PDF files, just cannot deliver.

I never read PDF for fun.  It usually causes me physical pain and nausea.  I make numerous reading errors.  Of my many friends with low vision I know none who can finish long documents in PDF using Adobe Reader.  I have finished two in my lifetime.

Most of the time, I print the document.  I use Xerox enlargement to get a 140% bump in size.  Then I use a 2.5x hand magnifier.  That gives me 350% enlargement, sore eyes and a very stiff neck.  PDF is just too much for my reading stamina.

6 thoughts on “While I was teaching… Nose to the Page (1)”

  1. Dear Wayne Dick,

    I am so glad you are writing about this and sharing this information. This is an area of accessibility that is rarely discussed beyond “Be sure the page content reflows properly when enlarged 200x for low vision users of screen magnifiers.”
    Your class at AccessU was a big “Ah Ha!” for me. I’ve been in the field of accessibility for 11 years and I was stunned at how much I don’t know about low vision. Thanks to you, I am now more aware, still learning and looking for solutions.

  2. You are correct. PDF was never designed with the need to enable style replacement – in fact, it was designed with the exact opposite in mind (fixed/frozen styling). And it is that feature that makes it the commonly used format that it is for many type of content – especially those are that are mandated for a specific look (eg. legal documents, forms, etc.)

    It sounds like what is needed for people with low vision is a PDF viewer that is able (at the user’s request) to extract the semantics and the content, and then present them via customized style sheets. Yes?

    Leonard Rosenthol
    PDF Architect
    Adobe Systems

  3. We had a brilliant example of this problem today – we had been sent a pdf with directions to halls for a new student (no address with post code, just directions!) but the document was password locked so the only thing that could be done with it was print it out.

    Sadly the font used was almost illegible even for her young eyes, as their website has no page with directions we had to copy the directions from the enlarged document on screen (by hand) just so the driver could navigate.

  4. Leonard Rosenthol, I’m not meaning to be catty, but wouldn’t a “viewer that is able (at the user’s request) to extract the semantics and the content, and then present them via customized stylesheets” simply be the application the PDF was created with in the first place plus its source file?

    For example, if the file was created in MS Word, you could view the document in Word and in your own template, a template customized to meet your needs.

    If the file was created in html, you should be able to tell your browser to ignore the original CSS and use your own in its place.

    Still, the approach you mention—adding a stylesheet feature to PDF—would be valuable when no electronic source file is available. For example, if I were to create a PDF from a hard copy by scanning the document, running OCR, and then tagging the contents, it would be wonderful for me to be able to pass that along to Wayne and for him to be able to tell his own PDF viewer how to present each style to him. Regardless of whether his vision is sensitive hue, contrast, font face, font size, column width, or some other design attribute, Wayne should be able to use his own PDF reader to adjust the settings so he can read comfortably.

    In other words, rather than keep PDF no better than paper, you would be turning PDF into a powerful tool for capturing content currently available only on paper and making that content accessible to people with any type of visual impairment.

    And your suggestion hits squarely upon the key to making content accessible to people who have low vision:
    – The authoring tool must support and encourage proper semantic tagging.
    – Authors (and document designers) must use that feature.
    – The user agent must allow the user to override the display settings built into the document, whether through a template, a stylesheet, or some other means.

    In focusing on the designer’s chosen settings—for example, in WCAG 2.0 1.4.3 (Contrast—Minimum) and 1.4.6 (Contrast—Enhanced)—the accessibility guidelines actually make things worse for Wayne and people with similar visual disabilities. And they make life more difficult for me, as I must negotiate with designers and our customers in a battle of their sense of aesthetics against a tool’s measurement of color contrast.

    Instead, the greater emphasis should be on the capabilities of the user agent. If you present the content in a way that enables the standard user agent to provide 1.4.6 (Resize Text) and 1.4.8 ([control over] Visual Presentation), then, regardless of your chosen contrast settings, you should be allowed to claim conformance at level AAA. (By “standard user agent,” I mean a browser for html documents, Word for Word documents, and so forth.)

    As it stands now, documents that conform with WCAG 2.0 at level AAA must meet 1.4.8’s call for a contrast ratio of at least 7.0:1—high enough to cause Wayne physical pain.

    And that’s just not right. Our most highly accessible documents shouldn’t hurt anyone.

Leave a Reply

Your email address will not be published. Required fields are marked *