W3C home > Mailing lists > Public > public-comments-wcag20@w3.org > April 2010

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

From: Loretta Guarino Reid <lorettaguarino@google.com>
Date: Fri, 23 Apr 2010 18:24:53 -0700
Message-ID: <h2t824e742c1004231824rd206ccc3h199309df66cf2ba8@mail.gmail.com>
To: Wayne Dick <wed@csulb.edu>
Cc: public-comments-wcag20@w3.org
On Thu, Dec 24, 2009 at 4:20 PM, Wayne Dick <wed@csulb.edu> wrote:
> 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.
>

================================
Response from the Working Group
================================
Thanks for your follow-up replies on this. Because WCAG 2.0 is now a
W3C Recommendation, it's no longer possible for us make changes to the
requirements. While we agree that the behaviors you describe are
important for some users, WCAG 2.0 does not require that authors
ensure element-level font/text styling in order to conform.

We believe that the suggestions you're making are best addressed in
the context of the User Agent Accessibility Guidelines. In fact, the
current draft of UAAG 2.0, guideline 3.6 [1] includes a number of
requirements that specifically relate to this topic. If you haven't
already, we would suggest that you review the UAAG 2.0 requirements to
be sure that the concerns you've raised here are adequately covered.

[1] UAAG Guideline 3.6 Provide text configuration.
<http://www.w3.org/TR/2010/WD-UAAG20-20100311/Overview.html#gl-text-config>

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 Saturday, 24 April 2010 01:25:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:11:12 UTC