- 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>
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 time. 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 law. Lainey Feingold has written on the topic of current US Legislation, and it is a sad and troubling state of affairs today: http://lflegal.com/2011/07/web-delay/ However, once-again, this is a US legal system issue, and not a W3C issue per-se. > 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: http://www.w3.org/TR/UAAG20/#gl-style-sheets-config "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: http://www.access-board.gov/sec508/refresh/draft-rule.htm#software). 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 confused. > 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 > VR/LV > > 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 HTML + CSS? > 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 style-sheets. 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. Summary: * 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 guidelines. * 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 inappropriate. Cheers! JF
Received on Tuesday, 18 October 2011 20:07:27 UTC