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

Now that I am no longer mad I would like to say 
that I appreciate your work, but I wish you would 
address my issues.  You addressed none of them.

(1) modification of font-family based on element 
(tag) type,
(2) enlargement of letter, word and line spacing 
for text, and
(3) variable enlargement

Now to (1) element level control of font-family: 
The last time I checked Zoom Text they did not 
support modification of font family at the 
document element level. All browsers of HTML/CSS 
do this. Most word processors with templates 
address this issue.  Acrobat Reader does not. So, 
please demonstrate an assistive technology that 
does support this for PDF.

(2) Control over letter, word and line spacing: 
This was not addressed.  It is considered so 
essential to traditional document design that that 
it is included as a standard feature of most 
authoring tools for HTML/CSS, word processing 
files and PDF.  It is also recognized as a 
critical need for people who have low vision and 
who are not legally blind.

(3) Variable Enlargement:  Again not addressed.. 
Authoring tools for HTML/CSS, word processing 
documents and PDF consider variable enlargement at 
the document element level to be essential 
requirements for a fully sighted audience.  It is 
  important for people with partial sight who are 
not legally blind.

Regarding the other success criteria mentioned, 
they are irrelevant.  I know Acrobat Reader 
supports color/contrast and also word wrapping. 
That is why I did not mention them as a problem. 
The ability to enlarge everything by 200% does not 
address element level variability of zoom.  Also, 
moderate low vision ranges from (20/70-20/160). 
200% uniform enlargement will probably be inadequate.

You have not addressed the fact that the 
accessibility needs of people who have low vision 
and are not legally blind can be supported by any 
form of PDF.

Many people who have low vision but are not 
legally blind like a one column format that 
provide variable size and font control to express 
visual semantics.  We don't need a redical 
transformation like Zoom Text or a screen reader. 
  We need enhanced text.  HTML/CSS and most word 
processing formats enable this capability - they 
enable an independence of meaning from 
presentation.  PDF could do this, I know that.  My 
point right now they don't.

One problem is that your committee never 
considered the full range of people with print 
disabilities caused by visual impairments.  Your 
criteria is broad enough to cover all of us, but 
you consider inappropriate assistive technologies 
when you address people with low vision who are 
not legally blind.  Zoom Text and screen reader 
support give accessibility support for people who 
are legally or totally blind.  The problem is that 
the majority of people with uncorrectable visual 
impairments are not blind - legally or otherwise. 
  HTML/CSS and word processing formats can support 
this group, but PDF does not.

If accessibility support did not exist extensively 
for similar document technologies, I would 
consider this long term development problem for 
everyone.  The issue is PDF stands alone 
conspicuously in not providing any way to obtain 
this support.  I think that is divergent enough 
from the norm of document technologies, that it 
qualifies as a significant lack of accessibility 
support.

Received on Thursday, 24 December 2009 23:21:25 UTC