W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > October to December 2011

Re: Exclusion of Visual Readers with Low Vision form WCAG 2.0 and the 508 Revise

From: Wayne Dick <wed@csulb.edu>
Date: Wed, 19 Oct 2011 20:32:07 -0700
Message-ID: <CAJeQ8SDNkbuYCTN3ZL632CSZQkitXFG9M08keKMbSfjtxb=-fQ@mail.gmail.com>
To: w3c-wai-ig@w3.org
Dear John,

First, HTML with CSS that satisfies WCAG 2.0 at Level AA gives
sufficient typographic access for low vision. My problem is with
for-profit proprietary formats that do not provide sufficient
typographic access.  I am disappointed in WCAG WG for not holding
non-W3C formats to the same standard as W3C technologies.  This is
especially important when the inflexible document format contains
online content like newspapers, periodicals, eBooks, user's manuals,
instructional information or legal content.

I do not address UAAG or ATAG here because they are nice to quote, and
very distracting, but irrelevant to my essay.  My problem is with WCAG
WG and their narrow interpretation of the separation principle that
enables fundamentally inaccessible proprietary content to claim level
AA compliance. Now that it has been brought to my attention, I also
find similar problems with Chapter 4 and 5 of the 508 Draft. Content
that prevents effective reading for visual readers with low vision
will pass these provisions.

Let me put a fine point on it: WCAG 2.0 under the interpretation of
WCAG WG excludes necessary typographic access for effective visual
reading with low vision.  This is the most critical access needed by
for visual reading with low vision.

Regarding the legal standing, 508 is the measure for legal compliance
with the ADA and Section 504 of the Rehabilitation Act.  Chapters 4
and 5 harmonize very closely to WCAG 2.0 on matters of content.  At
WAI we like that fact and call it standards harmonization. Draft 508
has even dutifully included the mistaken SC 1.4.3 verbatim.

>From Draft 508, I choose 409.2 as an example, because it actually
addresses text style explicitly and it clearly demonstrates the
general ignorance of policy developers regarding visual reading with
low vision. WCAG WG is not the only group that misunderstands the
need.  409.2 is a good exemplar of Draft 508 because 508 really
suggest little else. I will also assume that word wrapping from
Chapter 5 is satisfied, another requirement on text in Draft 508.

"409.2 User Preferences.  Applications shall provide a mode of
operation that uses user preferences for platform settings for color,
contrast, font type, font size, and focus cursor."

This access is better than nothing, but it is seriously inadequate. If
that is all that is required of developers then Draft 508 promotes
unequal access.

409.2 is incomplete. It does not provide enough style choice to
support perception.  Letter, word and line spacing are important for
addressing crowding and tracking problems.  Line length (margin size)
is also important.  Text style is just one dimension of typographic
access.  The other dimensions are missing entirely in 409.2.

A second dimension of typographic access is the ability to change
style at the document element level.  The user preferences at the
platform level do not cover the range of document elements found in
real written expositions.  Without a template for user preferences,
similar to style sheets or templates found in good word processor, the
programmer of the user agent is left to guess about what to do with
unspecified document elements. Most programmers are not low vision
specialists, and guesses are often wrong.

Understand this fact.  Visual readers with low vision are visual.
That means they need visual semantics to distinguish between elements,
just like visual readers with full sight.  The problem is that
typography of normal print usually does not match the needs of low
vision.  A one to one typographic transformation  from the elements in
normal print to the elements in enhanced print is needed for equal
access.  For example, in a large print environment use of size to
distinguish heading text from paragraph text, wastes too much space.
Font faces are a better discriminators.  I use the following system
for myself.  My heading font face differs from the paragraph font
face.  In addition, I place periods "." before headings, e.g ". H1",
".. H2", "... H3", "... . H4", "... .. H5", "... ... H6".  This is
easy to manage with CSS.  The font size varies little across elements,
usually 32 to 40 pixels.  I use color, because my visual damage leaves
color vision.  Of course some others with low vision cannot use color,
but rich style options like borders can be used as color substitutes.
Full style access gives the ability to adjust text to the exact need
of the user.

409.2 does not consider this variability across elements. It does not
describe the level of detail necessary to transform text for visual
access.  The dimension of element style is missing, as it is in WCAG
2.0. Element is used in other contexts (navigation, operation etc.),
but it is not used in a context for access to typography.  WCAG SC
1.4.4 is a clear example this blunt force approach of WCAG 2.0.  It
only conceives of a uniform enlargement scale across all element
types.

One more example should suffice to demonstrate typographic access at
the element level.  In HTML, authors use  <em> and <strong> that
usually translate to italics and bold respectively.  Their meaning is
to emphasize and strongly emphasize the content. They are inline call
outs. Unfortunately, italics are hard for some people (like me) and
bold can be hard to perceive with some font faces.  I just use a
different font faces for these elements. These are readable to me, but
detectable.  Typographic control at the document level gives this
ability to transcribe the author's intended message into a perceivable
mode, even subtle meanings.  This is entirely within the scope of
separation of information and structure from presentation.  With
complete typographic access to visual semantics this type of
transcription is possible.

Now a key point is this.  A different person will probably need
different typographic translation of visual semantics, but without a
template structure like CSS a one to one translation is not possible.
The problem with 409.2 is that it does not enable one to one
transcription of document's visual semantics.  The problem with WCAG
2.0 is that it does not require this as accessibility support for SC
1.3.1. Faithful transcription to speech is required accessibility
support. Faithful transcription to perceivable text is not (according
to WCAG WG).

A second shortcoming 409.2 and another dimension of typographic access
is layout within a context of variable font size.  If you have never
set you minimum font size to 24px then you cannot understand how badly
most web pages behave.  Columns bleed; lines slam into each other;
critical buttons get pushed off the page; input fields are too small
for large text input, and horizontal navigation bars blast off the
right end of the viewport. Attempting to actually use platform
settings frequently results in reading chaos.

This need to adjust layout is another reason to allow full style
access.  The user must be able to augment the authors style to include
the layout to support significant enlargement of font.  I am one of
the few people who really writes customizable user style sheets.
After struggling a long time, I created an extensive reset style sheet
that simply restored the page to HTML 4.01 default styles.  After the
reset phase, I apply my individual styles to the cascade. This
prevents most problems except those caused by active content after
page load.  I am a retired professor of computer science and solving
this problem was difficult for me.  I doubt an ordinary user could do
this. However, there is one key fact about HTML, XML and other W3C
markup languages. Necessary user access to typography does exist for
these language. Less skilled users can approach experts to obtain
typographic access.

Some for-profit proprietary format lack the ability to exceed the
inadequate one-dimensional access of Draft 508 409.2.  Their user
agents do not provide one to one access to the typography document
elements, and nobody has attempted to approach the problem.
Accessibility support for one to one access to visual semantics does
not exist.   These vendors limit typographic choice to the 409.2
minimum.  Document element level access is not available.  Some can be
transformed to HTML with significant loss of quality. Documents in the
original proprietary format do not permit significant change in
typographic style.  If the document is secure then style modification
is out of reach, except the minimal 508 409.2.  With only the ability
to change font face, font size and color many documents are impossible
to finish.

Simple perception of text is one barrier for visual readers with low
vision.  The biggest problem is stamina.  It is easy to start a book
length document, but soon eye and neck pain coupled with nausea set
in, and it becomes too difficult to finish.  To finish online books,
news paper articles, manuals and legal instructions one needs
typographic isomorphism: a one to one translation of normally styled
document elements to the typographic elements needed by the user.  One
also needs a layout environment that supports typographic style
change.  Many for-profit proprietary formats do not permit this
access, but they pass WCAG 2.0 at level AA, and Draft 508 would pass
them too.

As I mention in my article, an outhouse is better than a bush, but it
is not a flush toilet.  The WCAG 2.0 / Draft 508 approach is similar
to outhouse access for visual reading with low vision.  It provides
some access but it is separate and profoundly unequal.

Sincerely, Wayne
Received on Thursday, 20 October 2011 03:32:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 20 October 2011 03:32:45 GMT