W3C home > Mailing lists > Public > public-comments-wcag20@w3.org > December 2009

Re: A test of the flexibility of WCAG 2.0 to adapt to a new situation presented by tagged PDF.

From: Wayne Dick <wed@csulb.edu>
Date: Wed, 23 Dec 2009 19:12:56 -0800
Message-ID: <4B32DC38.4000808@csulb.edu>
To: Loretta Guarino Reid <lorettaguarino@google.com>
CC: public-comments-wcag20@w3.org
I still do not believe 1.3.1 is met.  It is met 
for Zoom Text users, and I guess if I want to buy 
special software just for the purpose of reading 
PDF I could.  I have tried Zoom Text it does not 
work for a person with moderate low vision.  You 
just don't know what we need.  Your decision will 
limit the reading freedom of millions of people 
like me.  Yes we will adopt vastly inferior 
accommodations, but 1.3.1 is not met.  You should 
have taken the time to finish your fail cases.


Loretta Guarino Reid wrote:
> On Fri, Dec 11, 2009 at 11:57 AM, Wayne Dick <wed@csulb.edu> wrote:
>> Dear WCAG WG
>> I cannot read PDF effectively.  I have moderate
>> low vision (20/80 fully corrected) caused by
>> central retina damage.  This has been a lifelong
>> issue, and I'm an old hand at trying assistive
>> technologies.
>> The problem is that PDF does not have an assistive
>> technology that permits individualized: (1)
>> modification of font-family based on element (tag)
>> type, (2) enlargement of letter, word and line
>> spacing for text and (3) variable enlargement
>> linked to element type.  These modifications are
>> important for many people like me (Moderate Low
>> Vision 20/70 - 20/160).  This need is well
>> documented.
>> I believe that one cannot claim conformance with
>> 1.3.1 and hence at Level A in this case.  Here is
>> my logic:
>> 1.      Criterion 1.3.1 (Info and Relationships) says:
>> Information, structure, and relationships conveyed
>> through presentation can be programmatically
>> determined or are available in text. (Level A).
>> Adobe claims the physical structure of tagged PDF
>> files do meet this.  I have no reason to doubt them.
>> 2.      Accessing text in tagged PDF is closed to users
>> for all the necessary parameters I have mentioned.
>> 3.      Text is part of information and expresses
>> relationships.  Characters (letters, digits and
>> punctuation) are central to reading.  Characters
>> in the wrong font are difficult to perceive.
>> Serifs cause visual complexity and reduce
>> perception of foreground.  Also, white space
>> expresses relationship.  In words space helps
>> distinguish letters, in lines space separates
>> words and between lines space indicates reading
>> sequence (Criterion 1.3.2).  The problem is this:
>> without enlarged spacing individual letters within
>> words and words in lines get lost or confused.
>> Small spacing between lines causes reading
>> information from the wrong line out of sequence,
>> the tracking problem.  All these semantic cues are
>> presented visually.  Since, 1.3.1 refers to
>> information, structure and relationships without
>> any qualification, I have always assumed that
>> 1.3.1 applies to text.  I don’t mean to the
>> natural language meaning of text, just the
>> document structural meaning. Information that can
>> be programmatically determined.
>> 4.      PDF has no accessibility support to enable the
>> modifications of text that my disability group
>> requires.
>> 5.      Tagged PDF is a structured medium, so the
>> sufficient techniques that apply to tagged PDF are
>> in Case A of the Sufficient Techniques for 1.3.1.
>>  G140: “Separating information and structure from
>> presentation to enable different presentations,”
>> is part of this set of techniques.  All these
>> techniques must meet to satisfy Case A, but G140
>> has incomplete accessibility support for modifying
>> text presentation.
>> 6.      Sufficiency is not necessity, so this does not
>> prove inaccessibility, but the only published
>> proof that tagged PDF is accessible is not
>> accessibility supported for G140.  Hence, tagged
>> PDF cannot use Case A of the sufficient techniques
>> for 1.3.1 to claim accessibility.  The only other
>> case published in the techniques document does not
>> apply.
>> 7.      Tagged PDF provides the cues necessary to
>> support access to text, but there is no attainable
>> assistive technology that enables this access.
>> This excludes people with moderate low vision from
>> using PDF effectively.
>> 8.      I apply Conformance Requirement 4: Only
>> Accessibility-Supported Ways of Using
>> Technologies: Only accessibility-supported ways of
>> using technologies are relied upon to satisfy the
>> success criteria. Any information or functionality
>> that is provided in a way that is not
>> accessibility supported is also available in a way
>> that is accessibility supported. (See
>> Understanding accessibility support.).  It follows
>> that the only reasonable way to post PDF at this
>> time and claim Level A support is to include an
>> alternative accessibility support.
>> When WCAG WG developed Criterion 1.3.1 and
>> technique G140, I doubt you ever envisioned a
>> medium that would enable programmatic
>> determination at all levels, and would not provide
>> the accessibility support needed to change
>> presentation of text in necessary ways.  Now we
>> have tagged PDF, and it falls exactly into that
>> category.
>> You made WCAG 2.0 adaptable to changing
>> technology.  Tagged PDF is such a new technology.
>>  It is a qualitative improvement over original
>> PDF.  You put all that work into generality to
>> accommodate cases like this.  You did not write
>> 1.3.1 saying "Information, structures and
>> relationships must be programmatically determined
>> ... at the tag level only.  There was no
>> qualification of information, structure and
>> relationships.  That is good because it left this
>> criterion applicable to text as well as tags.  As
>> I have shown, the text nodes associated with tags
>> also contain information and relationships that
>> are critical to understanding.
>> There alternative media that enable text level
>> alteration of presentation to the individual user.
>>  HTML with CSS is perfect.  Most word processors
>> have a style template concept that enables simple
>> conversion from one visual presentation to
>> another.  Both are system level objects that can
>> be used for reading.
>> My question is this.  Regarding this new category
>> of medium:Can a medium claim Level A conformance
>> if: (1) includes programmatic access to
>> information, structure and relationships, but (2)
>> has no supporting technology to change text
>> presentation to meet the needs of a well known and
>> large group of people with disabilities? Does
>> Conformance Requirement 4 apply?  Also, does 1.3.1
>> apply to the syntactic indicators of structure and
>> relationships apply to text within elements?
>> I personally thought I was protected by 1.3.1.  If
>> 1.3.1 does not apply, but I cannot use the text
>> with any known assistive technology does 1.1.1
>> fail? Is such a medium effectively non-text with
>> regard to accessibility support?
>> I would like to conclude with some minor points.
>> People with moderate low vision usually can see
>> headings.  We usually don’t need alternative text.
>>  Most of us like to use a mouse.  We just cannot
>> see the normal, most important, text.  Programs
>> like JAWS are disorienting because we depend on
>> the reduced sight we have, and even the lowest
>> level of chatter disrupts the concentration we
>> need to use our compromised vision.  Zoom
>> technologies rob us of our visual map of the page.
>>  HTML and many word processors provide us the
>> typographic control we need to change the
>> presentation to meet our needs.  A medium that
>> does not enable these users to change presentation
>> in the way they need, individually, excludes us,
>> and I think we are excluded because 1.3.1 and G140
>> are not fully supported.
>> I request that (not G140) be made a failure case for 1.3.1.  This technique
>> should be necessary. To my mind 1.3.1 always was meant to give the freedom
>> to change presentation - to a usable format: non-visual or visual.
>> To appreciate the needs of moderate low vision see:
>> http://www.csulb.edu/~wed/public/521/521_XSLT/ModLowVis.html
>> Sincerely,
>> Wayne Dick
> ================================
> Response from the Working Group
> ================================
> Hi Wayne,
> Thank you for sending your comments in to the group.
> We reviewed them carefully as a full group and did some background
> research as well.
> Our conclusion was that 1.3.1 was satisfied for properly created PDF.
> First it turns out there are assistive technologies that will allow
> you to change fonts, font size, font color etc in a PDF.
> -  Acrobat Reader and Acrobat Pro allow you to change font color,
> font size, and it will reflow text to avoid horizontal scrolling.
> -  ZoomText 8.1 / DocReader allows you to change the font.
> So there is accessibility support for font changing, font-face, size,
> and colors.
> But beyond this we looked at the broader question you raised.   And we
> concluded that SC 1.3.1 is automatically satisfied for content that
> qualifies as text ("sequence of characters that can be
> programmatically determined, where the sequence is expressing
> something in human language").   So 1.3.1 was met generically as well.
>   PDF can be read - and can be read by assistive technologies.  The
> fact that regular user agents do not allow all of the desired
> behaviors would not make content fail SC 1.3.1.
> In addition, the visual presentation of text is addressed at Level AA
> by 1.4.3 Contrast (Minimum), SC 1.4.4 Resize text, 1.4.5 Images of
> Text, and at Level AAA by 1.4.6 Contrast (Enhanced), 1.4.8 Visual
> Presentation, and 1.4.9 Images of Text (No Exception)
> Thank you for your inquiry.  If you have further questions - please
> let us know.
> Loretta Guarino Reid, WCAG WG Co-Chair
> Gregg Vanderheiden, WCAG WG Co-Chair
> Michael Cooper, WCAG WG Staff Contact
> On behalf of the WCAG Working Group
Received on Thursday, 24 December 2009 03:13:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:14:52 UTC