WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: PDF on websites + PDF is *not* accessible

for

From: Ryan E. Benson
Date: Jul 9, 2013 4:13PM

Duff said:
First, this statement is equally true for plenty of implementations of HTML
/ CSS / JavaScript technology, various combinations of which produce
results that defeat today's AT technologies. It's hardly a "PDF problem" -
calling out PDF specifically in this case is misleading.

Duff this is incorrect. I can open up most browsers and define a user
stylesheet which allows me to do about anything I wish provided that I
understand CSS. Either by default, or via plugins, I can define a custom
stylesheet for a specific site. For example, in Firefox I have an outline
which makes it clear where the focus is. Of course there are ways
developers can get around my stylesheet.For example the Gmail UI likes to
use spans/divs instead of whatever a semantically appropriate tag would be.
In Acrobat, I can only choose from a few back/foreground colors.

--
Ryan E. Benson


On Tue, Jul 9, 2013 at 11:51 AM, Duff Johnson < <EMAIL REMOVED> > wrote:

> Shawn,
>
> You've called out PDF as a format for specific comment. You've made
> several assertions pertaining to technical and practical realities.
>
> While I deeply respect your perspective and the conversation thus far not
> all statements have been accurate, informative or helpful.
>
> This is an important forum, and I want to put the record straight.
>
> A summary of my extended response (see below) is this:
>
> - Shawn's confusing the PDF format itself with software implementations
> thereof. Contra her claim, this is the fundamental "misnomer" at hand in
> the discussion.
>
> - In WCAG 2.0 terms Shawn's conflating "accessibility" with
> "accessibility-supported." They are rightly distinct; collapsing the
> distinction does not serve understanding or drive solutions to improve PDF
> accessibility.
>
> - Such confusion is *naturally* understandable for end-users. Informed
> advocates, however, need to respect these critical distinctions to be
> maximally effective in terms of influencing software development - the
> aforementioned "implementations."
>
> - The work Shawn's doing with TAdER is a superb contribution to critical,
> practical information for any developer working on user experience -
> including those focussed on making electronic documents accessible. The
> project would be more successful if it refrained from inaccurate
> generalizations while making technical claims.
>
> > Background from previous comments is below [1].
> >
> > The problem is that PDF is currently *not sufficiently accessible* to
> many people with low vision, dyslexia, and related conditions and
> situations that impact reading - because Adobe Reader and other PDF viewers
> lack sufficient text customization functionality.
>
> First, this statement is equally true for plenty of implementations of
> HTML / CSS / JavaScript technology, various combinations of which produce
> results that defeat today's AT technologies. It's hardly a "PDF problem" -
> calling out PDF specifically in this case is misleading.
>
> That said, if plain HTML can meet TAdER requirements then it's hard to
> understand why PDF/UA doesn't as well since PDF/UA files may be readily
> exported to plain HTML while (key point!) retaining the ability to fallback
> to the real document.
>
> The later point, however, is that you cannot reasonably claim there's any
> misnomer in describing properly-tagged (PDF/UA-1) files as "accessible".
> They are accessible within any reasonable definition that you'd apply to
> WCAG 2.0 conforming HTML.
>
> But that's not my core point, which is that categorical statements such as
> you've offered are actually and notably injurious to the cause of promoting
> development in accessibility technology. You won't win new software
> development efforts by attacking the file-formats themselves.
>
> Look at it this way: Accessible alternatives to PDF files will depend in
> the real-world on re-use of PDF content because it is the only available
> content in many given situations. Lots of stuff is in PDF for reasons that
> just make sense to the players at hand in their respective business
> contexts, and that's the reality with which you need to engage.
>
> Having accepted it one ought (it seems to me) focus on highlighting the
> *lack* of technical barriers to full access to PDF, the degree of
> standardization available, the extent of implementation tools from PDFlib,
> iText, Adobe, Microsoft and others. Give developers reasons to invest in
> accessibility tools; do not foreclose on the potential for investment by
> proclaiming that somehow alternatives must be provided!
>
> When tagging or re-use fails a given user for a given reason, why, the PDF
> is the *critical* backup, tedious as it make be, it's still the *actual*
> document.
>
> That's the PDF focus and value-proposition, and it's got nothing to do
> with the ability to adjust kerning for X percent of users who need such.
> Equal access to the *same* content is - or ought to be - the focus here.
> There's no technical barrier to full accessibility (including TAdER
> parameters) to content delivered in PDF, and you do the community a
> disservice when you suggest otherwise.
>
> You would achieve far more, I think, by making statements similar to the
> following:
>
> "PDF files can only be considered fully accessible in every possible
> use-case when full TAdER text management is available."
>
> Only when you are using such constructive terms will you will then be
> helping, rather that hurting, the cause of improving access to content that
> exists (fact) in PDF.
>
> > Even well tagged PDF that is more accessible to screen reader users is
> still *not accessible* to many people with other print disabilities.
> Accessibility is more than screen reader access.
>
> This is a straw-man. No-one claims this for PDF any more than for HTML.
>
> > Unfortunately, "tagged PDF" started getting called "accessible PDF" --
> that is inaccurate and a harmful misnomer.
>
> Let's be completely clear on this.
>
> PDF that conforms with PDF/UA-1 (ISO 14289-1) is accessible, period.
> Whether it is accessibility-supported for any given need is *another
> matter* - a question for implementers, but assuredly not in question with
> respect to the file format.
>
> If vanilla HTML meets TAdER or TAdER-relevent standards for accessibility,
> then it's fair to say that PDF can qualify, because PDF/UA-1 conforming PDF
> files can be exported to the user's chosen HTML implementation. As you
> rightly point out, forms aren't yet supported in VIP Reader. Why is this
> more worthy of note that X, Y or Z failure of FaceBook, or iTunes or
> whatever to accommodate TAdER preferences?
>
> Do you really want to suggest that PDF is inaccessible now but can "become
> accessible" when (for example (VIP Reader adds the ability to print? C'mon.
>
> Now, anyone can and will concede that it's also possible to simply "tag"
> PDF without doing it well, just as its possible to do a half-ass job of
> ensuring CSS usage is accessible (for example). Tagging is a critical but
> insufficient part of meeting accessibility requirements for PDF content.
> Tell them that, instead of trying to make an (incorrect) grossly general
> claim about the file-format as a whole.
>
> > It perpetuates the lack of awareness, even among accessibility
> specialists, that PDF is actually not accessible to many people with print
> disabilities.
> >
> >> My job is to communicate one person's ideas to another person.
> >> I want to provide what is both legally required and what is desirable
> to the users.
> >
> > While PDF is a useful medium for some situations; when it is used, there
> must be a more accessible alternative provided in order for the information
> to be available to people with disabilities.
>
> Once upon a time this was true. Today, this claim is inaccurate as
> written. It would be much more useful if it were re-written as follows (for
> example):
>
> "While PDF is a vital medium for many situations; when it is used, PDF
> creation, editing or reading software should create or read PDF/UA in order
> to generate or provide appropriate alternative representations of the PDF's
> content in order for that PDF's actual and inherent content to be available
> to the greatest possible number of people with disabilities."
>
> > I've been fairly quiet about this for many years (except to Adobe
> product managers :) because the accessibility of PDF has improved from
> years ago, but I'm deeply concerned about the *misconception that PDF is
> accessible*.
>
> PDF *can* be made accessible, and at this level of generalization, it's
> absurd to highlight PDF in format terms. Plenty of large-scale HTML
> implementations don't meet your preferred specifications for full
> accessibility today but I don't see you calling out HTML per se as
> "inaccessible."
>
> > For more info, please see:
> > * Text Customization for Readability <http://www.tader.info/>;
>
> I commend you for this site, and would unreservedly recommend that reader
> software implementers - regardless of medium - review your substantive
> recommendations for UI controls in readers.
>
> > * PDF viewers section of Support for Text Customization <
> http://www.tader.info/support.html#PDFisNOTaccessible>;
> >
> > (That is a work in progress and I welcome feedback directly.)
>
> Well, I've been no less public that you, I guess, with my opinion! ;)
>
> Duff.
> > > >