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: John Foliot <jfoliot@stanford.edu>
Date: Tue, 18 Oct 2011 13:06:56 -0700 (PDT)
To: <wed@csulb.edu>, <w3c-wai-ig@w3.org>
Message-ID: <04a501cc8dd1$7bef3fa0$73cdbee0$@edu>
Wayne Dick wrote:
> When WCAG WG developed WCAG 2.0 they lacked the expertise needed to
> write guidelines for all visual disabilities.  Two years after aproval
> of WCAG 2.0 the WG made a interpretive decision that virtually
> eleminated visual readers with low vision from civil rights
> protection.

Hi Wayne,

I am some-what confused by this statement. The W3C's WCAG documents (both 1 
and 2), while supportive of Human Rights Legislation, have no force of law 
in *any* country that I am aware of. Can you cite any Human Rights 
legislation that suggests differently?

> Subsequent revise of 508 followed this lead.  The result
> is that today, visual readers with low vision have less legal
> protection in the US than they did before 1980.

While current US Federal legislation in the realm of online accessibility 
does in many ways shape global directions, it has a very limited scope. 
Specifically, Section 508 only affects US Federally funded entities, and has 
no force of law on Private sector actors or other sovereign entities at this 

The US Department of Justice are currently looking at re-opening the US ADA 
(http://www.ada.gov/anprm2010.htm) to address short-comings that have 
emerged over the past 20 years (mostly, although not exclusively, in the 
area of digital inclusion). However, lobbying efforts should be at elected 
US officials: the W3C-WAI, while again influential in digital accessibility 
subject matter expertise, have no direct influence over US or International 

Lainey Feingold has written on the topic of current US Legislation, and it 
is a sad and troubling state of affairs today: 

However, once-again, this is a US legal system issue, and not a W3C issue 

> The technology to eliminate almost all print disabilities related to
> VR/LV has been well established since adoption of CSS 1 (1996) and HTML
>  4.01 (1999). The underlying concept is
> separation of information, structure and relations from presentation,
> the Separation Principle. It is completely possible to give visual
> readers with low vision complete individualized access to the visual
> style they need to achieve advanced literacy. The only obstacle is
> will.

Actually, the only obstacle is software vendors not realizing and reacting 
to a real need. However, as private companies with share-holders and 
corporate agendas, they cannot be *forced* by the W3C to do anything. This 
is a sad but honest reality. Federal and State laws on the other hand are a 
completely different situation...

> Today, access to style is under siege. Proprietary content vendors do
> not want to recognize the need.  One vendor actually claims that zoom
> is enough to meet the literacy needs of low vision. Vendors are so
> stingy with the style access they permit that literacy just slips
> further and further away.

Wayne, your sense of frustration and anger is palpable and shared by many 
(including myself), but I think you are turning that frustration and anger 
on the wrong people here. This is a software issue, and it's the software 
vendors who need to start doing a better job. If not by persuasion 
(something that the W3C has worked hard on), then by legislation (contact 
the DOJ, or your local elected officials).

> The problem has gotten worse since the adoption of the Web Content
> Accessibility Guidelines (WCAG 2.0) in 2008. This is because the WCAG
> Working Group endorses the concept that accessibility support for
> individualized access to style is not covered by the guidelines.

This is simply because WCAG focuses on "content" and not user-agents 
(software tools), so WCAG is the inappropriate place to talk about how users 
interact with their tools. That is the role of UAAG (User Agent 
Accessibility Guidelines), and those guidelines are pretty clear about 
user-interaction with alternative Style Sheets: 

"1.7.2 User Style Sheets::  If one or more user style sheets are defined, 
the user has the following options: (Level A)
   (a) select and apply one or more user style sheets, or
   (b) turn off user style sheets."

Once again however it is important to note that these are *guidelines* and 
not legislation; to *force* software tools to support this requirement (an 
'A' requirement BTW) will require that the politicians and other law-makers 
take this recommendation (guideline) and give it legal teeth.

> When
> the new revise of Section 508 —based on WCAG 2.0— is finished, visual
> readers with low vision will have less protection under the law than
> they did before the original Section 508.  It will be legal in the
> United States to deny access to visual style other than magnification.
> Let’s hope that Australia does not follow the American example.

Once again it is important to note that Section 508 (even if/when refreshed) 
has limited scope: the real prize is the ADA (which *does* cover commercial 
entities), and the path to affect change there, while delayed, is very 
clear: it will take political will in the United States, and not some magic 
waving of a wand from the W3C.

It is also worth noting that WCAG 2 (indirectly) maps to Chapter 5: 
Electronic Documents (refresh: 
http://www.access-board.gov/sec508/refresh/draft-rule.htm#documents) while 
much of UAAG maps to Chapter 4:  Platforms, Applications, and Interactive 
Content (refresh: 

Finally, a reading of Advisory 409.2 of the 508 refresh states: "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."

So where is the problem again?

> I define the separation principle as follows:
> A document conforms to the Separation Principle whenever all of the
> information, structure and relationships in the document can be
> programmatically determined.
> This is the wording of WCAG 2.0 success criterion SC 1.3.1 almost
> exactly.

Wait, so what exactly then is the issue with WCAG 2?  You started this note 
by saying that WCAG 2 did a disservice to a specific user-group, but then 
you say that WCAG 2 defines what you want "almost exactly".  Now I am very 

> The complete wording of SC 1.3.1 permits plain text as a fall
> back when markup language is unavailable, but this is an exception to
> the separation principle.  Plain text lacks deterministic
> identification of structure and relationships.
> With good HTML, Daisy or EPub document structures, CSS can provide
> completely individualized access to a visual presentation that will
> serve any individual’s personal reading needs. Most modern web content
> is not good enough to apply user style sheets without first
> eradicating the style choices of the author.  However, if one
> successfully clears the author’s style with JavaScript or another
> pre-process, web pages that obey separation can be restyled to a
> custom format that is very readable for most in VR/LV.

So this is an authoring issue then?

The only answer to this is education, given that any fool can be a web 
author (and we have millions of web-pages to back up that statement).

I'm not saying that this is not a problem, but there is nothing we can do to 
stop an author from writing bad HTML, any more than we can do anything about 
authors butchering the English language (pick any rap song you want) - in 
fact it could be argued (not that I would) that an author's "right" to write 
bad HTML mark-up is constitutionally protected in the US by the First 
Amendment. You and I would likely be in agreement that this is (shall we 
say) Bull Feathers, but trust me, a good lawyer would not be quite so quick 
to dismiss this (just ask the good folks at Netflix).

> The browser I use for professional access to user style is Opera on
> the PC and Mac.  I also use Firefox as follows:  I store a user style
> sheet “userContent.css” to my choice in the “Firefox Chrome”
> directory.  When I start Firefox, I go to “View > Page Style” and
> choose “no style”. That shuts off the author’s style (on page load,
> and during subsequent actions), and it leaves my style in control.
> Firefox, Internet Explorer, Safari (PC and Mac) and Opera are the only
> browsers that give reasonable access to user stylesheets.  Opera and
> Firefox are the only browsers that enables users to kill the author’s
> style completely and overlay their own style.  Opera, Safari and
> Internet Explorer make it ease to switch stylesheets within the same
> session, or use the author’s style.

So the majority of browsers today *do* support user-style sheets, it's just 
cumbersome to invoke them (and of course the end user needs to know how to 
create a custom CSS to meet their needs).

What I am hearing is that the process for working with user style-sheets in 
the browsers needs to be improved and made more user-friendly. Good point, 
but outside of WCAG, which is about *content* and not user-interaction.

> .. The WCAG Working Group  Abridges the Separation Principle to Exclude
> Late in 2009, it became clear that some proprietary formats lacked
> accessibility support for using SC 1.3.1 because there was no
> assistive technology to provide individualized access to style needed
> for visual reading with low vision.

"proprietary formats"?  Wikipedia defines this as:

	"Proprietary software is computer software licensed under exclusive legal 
right of the copyright holder. The licensee is given the right to use the 
software under certain conditions, but restricted from other uses, such as 
modification, further distribution, or reverse engineering."

In other words, it is owned by an entity, and they, and they alone, have the 
legal right to make changes to that software. If a proprietary format does 
not meet your needs, you have few choices: suffer through that format, lobby 
the patent owner to make changes, lobby law-makers to force changes or don't 
use it. None of these options involve the W3C.

> The matter was brought before the
> WCAG Working Group for clarification, and the committee determined
> that SC 1.3.1 referred to document structures like headings, tables
> and lists that could not be identified without markup tag structures.

Correct. Also, without this structural mark-up, user style-sheets would be 
significantly more difficult to create or support, as you would have to 
create a custom style sheet for *each and every site*.

> The primary purpose was for navigation and identification of
> relationships (mainly spacial relationships like tables). The
> committee concluded that SC 1.3.1 did not refer to an ability to
> determine document structure for the purpose of changing the visual
> presentation of text. Specifically, the need for accessibility support
> to provide access to visual style was not implied by SC 1.3.1 or
> anywhere in the guidelines.

I think you are making an interpretation here that was not actually 
articulated. Structural markup is essential for interoperability of user 
style sheets, but 'styling' is outside of WCAG's purview (and for good 
reason). Imagine if instead of not setting a 'standard', WCAG *mandated* 
that <h1> should render at 24pt?

Irrespective of all of this, WCAG 2 *still has no force of law*, so pointing 
at the WCAG WG as some type of villain here is completely off the mark.

> It is not surprising that a working group with little representation
> from low vision on their panel came to this conclusion.  Imagining the
> difficulty of comprehending spacial relationships and identifying
> visual structures from a non-visual perspective is easier than
> understanding the individualized subtle style issues needed to enable
> accessibility for visual reading with low vision.  It was hard for
> them to imagine that significant change in visual style was also
> necessary to perceive and comprehend the information, structure and
> relationships on a page.  I doubt that many of them had witnessed
> profound change of visual style applied to visual readers with low
> vision.

Wayne, I think that this is opinionated poppy-cock.

I know many (if not most) of the active VOLUNTEERS who are part of the WCAG 
WG personally, and your painting them as some kind of unknowing, uncaring, 
unimaginative villains is highly offensive. Lamenting the lack of 
representation of one or more VR/LV participants within a volunteer group 
simply points back to the fact that nobody stepped up to the plate from the 
VR/LV community - are you suggesting that the W3C should somehow *force* 
somebody to volunteer? Really?

> The working group’s lack of experience was complicated by the fact
> that no single style accommodation will work for all or even the
> majority of visual readers with low vision. High contrast, for
> example, will help some and harm others. From an industrial
> perspective that would appear impractical, but the W3C already had
> invented the magic bullet.  The W3C had already solved the problem
> with HTML and CSS, and following that solution was the key to other
> technologies.

So in other words, a group of inexperienced working group members - all 
volunteers at the W3C - none-the-less came up with the "magic bullet" of 

> Some proprietary vendors just do not want to take the extra step.

Now you are getting to the root of the problem. This is not a W3C problem, 
this is a vendor problem.

> They
> will provide navigational access and identification of some
> relationships for blindness, but they will not provide open access to
> visual typography.  WCAG Working Group agrees they do not need to
> provide this level of separation of content from presentation, and it
> is a devastating loss for VR/LV.

I think you are mixing issues and WAI working groups here without 
recognizing that different groups deliver on different issues. I once again 
point to the UAAG WG's document which clearly states that users should have 
the ability to replace author-supplied style-sheets with user-generated 

WCAG states that authors should use structured mark-up (headings, lists, 
paragraphs, etc.) without prescribing how those structural constructs should 
*look like*, which is what you are discussing. An H1 should have a default 
rendering, yes, but it should be allowed to be styled in whatever fashion 
the user requires: black on white or white on black, 17pt font or 30pt font. 
WCAG (rightly) does not differentiate, as for some users the "visual" 
rendering is not visual at all, it's conveyed as a hierarchal navigation 
heading. The "C" in WCAG is content, not style or design.


* WCAG is an instructional guideline/standard - it has no force of law.
* WCAG focuses on Content structure, and to a lesser extent design 
considerations such as allowing for scalability of text, color and 
color-contrast issues, etc. It does not address User Agents, nor 
user-interactions: that is covered by UAAG.
* UAAG clearly states that User-Agents should allow users to replace author 
sheets with user sheets.
* Section 508 (refresh/draft) Chapters 4 and 5 map (indirectly) to UAAG and 
WCAG, and between the 4 (WCAG, UAAG, 508 chapter 4, 508 Chapter 5) your 
concerns *are* accounted for.

* The majority of modern browsers today *do* support user-style sheets - 
however interacting with them is difficult.
* Some proprietary software tools only partially support WCAG/UAAG 
* Poorly authored (web) content does not take full advantage of the 
separation of structure and design, thus introducing rendering problems for 
the VR/LV community.

What is still needed:

* Better, more user-friendly support for User-supplied style sheets in the 
modern browser.
* Stronger legislation and enforcement at the Federal and State levels, both 
in the USA and in other countries around the world, directed at software 
vendors and content authors.
* Better education directed at content authors to use appropriate structural 
markup, and to have a cleaner separation of content and style (i.e. linked 
style-sheets rather than embedded or in-line style markup).

I suspect that upon inspection, you will find that the W3C WAI are working 
hard to affect those changes, using mostly volunteer effort and massive 
outreach efforts. However the W3C has no magic powers nor imperial right to 
force anyone to do anything, and suggesting to the contrary, or blaming them 
for the current state of support is both unfair, unwarranted and 


Received on Tuesday, 18 October 2011 20:07:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:36:38 UTC