The Commercial Disability

Visual readers with low vision (VR/LV) do not have the assistive technology they need for the simple task of reading.  This technology exists for W3C technologies like HTML with CSS, but even that access is difficult to realize.  While the accessibility community focuses all its efforts on access to active content, the basic problem of literacy for VR/LV remains unaddressed, but not unsolved.

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.

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.

Screen magnifiers just do not do the job for professional level literacy.  They are better than nothing, but an outhouse is preferable to going behind a bush. The claim that screen magnification is accessibility support for visual readers with low vision is like saying normal people get indoor plumbing, but VR/LV only can use the outhouse. We are even supposed to be grateful for this inequity.

Vendors are under no pressure to provide literature in accessible formats, on the web or in electronic publications, and developing a universal technology for all of the electronic publication formats is profoundly difficult.  The print disabilities of visual readers with low vision should really be renamed commercial disabilities. VR/LV is kept in a state of artificial semi-literacy because inclusion is commercially inconvenient.

The exact problem is this:  VR/LV needs access to change the visual style of typography.  That means they need to be able to have the style they need even though, the document may be protected from theft or misuse.  Vendors deserve their digital rights management, but digital rights should not extend to visual presentation.

At present, venders dictate what style modifications readers can have.  Adobe Reader permits very restricted enlargement, and global choice of foreground and background color.  Their reflow option is a big disappointment.  It does not enable text find; it loses content, and it cannot locate bookmarks within the text.  The iBook reader permits a small range of choice in color, font-face, and font-size. The iBook loses the entire advantage of its largest font size because it forces two column format in landscape view regardless of the font size.  The Kindle does have a one column landscape mode giving a good line length in large print mode, but the DX has many other style limits. The smaller kindle gives more style choices, but once again there are not enough to meet the range of needs required by VR/LV. What VR/LV needs is full style choice.  Clearly, hardware devices like the Kindle cannot provide color choice, but there is no reason for the Kindle Cloud application not to give extensive style choice. No Kindle device gives style choice for menus. Another issue with the Kindle system is that some text cannot be modified at all.

Proprietary venders could provide this full visual access, and many do.  Microsoft Word has a template system that rivals CSS.  Reading Word is generally easier than other formats, and many people with VR/LV read files into Word, adjust the styles and read the restyled text.  What is missing today are standards and regulations that pressure vendors across the web and electronic publishing industries to provide access to rich visual style. The accessibility community has successfully identified and protected access needed by blindness, but the needs of other visually impaired people (the majority) go neglected.  The population of VR/LV is now exploding as the baby boomers reach old age, and age related low vision. Baby boomers are computer users, and they will be expecting real accessibility.

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. 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.


The Exact Need

Access to typographic style is the single most important need of visual readers with low vision.  The well known factors are: font face color (back and fore), spacing (line, word and letter) and of course font size.  Increase in font size must also be accompanied with full and intelligent word wrapping.  Line length on a page is also important.  Arbitrary choices like two column format for landscape mode are discriminatory.

These choices must extend to the document element level.  One must be capable of modifying headings and paragraphs differently. Global document level choices are not nearly enough.  The essential point is this, visual readers with low vision are visual readers first.  They need a visual typography that is as rich a typography as the ones used by visual readers with full sight.

Currently most technology does not come close to providing necessary typographic access.  Safari on IOS has no style access, not even text only enlargement. The Kindle falls short on every platform.  Google Search engine, GMail and Google tools are inconsistent. None of them are easy to modify.  The Flash version of GMail does not support free choice of visual style, and GMail has taken to scolding users who need the HTML interface.  Chrome is borderline inaccessible. Adobe PDF and text material in Adobe Flash are inaccessible to VR/LV.

Safari (Mac and PC), Firefox, Internet Explorer and Opera are good.  Opera is by far the best. In "user" style mode Opera permits you can turn off the author's style sheet and load your own.  Another good vendor is Safari Books Online.  They tried a Flash interface, and when users complained they gave us an HTML alternative.  They support this alternative well.  Thank you Apple, Mozilla, Microsoft, Opera and O'Reilly for being very helpful.

Exactly what style access do people with VR/LV need?  Well that choice must be up to the individual.  Some need very large print.  Some need smaller print.  Color and spacing choices are all over the map.  Everything revolves around the user's exact needs.

There are more than 30 causes of low vision, and around 15 subsystems of the eye and brain that can be attacked to produce low vision Foundations of Low Vision, A. Corn, J. Erin. There are literally hundreds of ways partial sight can manifest itself. That extreme variation in presentation of low vision is why I focus on visual readers with low vision.  Being a visual reader, regardless of physiological damage, indicates a level of visual functioning that can benefit from customized typography. People with low vision, and their low vision specialists are the only people who can make the final choice on accommodation.  Today there are simply not enough choices offered for people with low vision or their low vision specialists to make an informed decision.

I know this because I am one of the only people in the world who has constructed individualized solutions for myself and others.  When you have the full power of CSS behind you, there are no typographic changes too difficult. If you are reading this with your eyes and have low vision, please contact me.  I can probably help you with web content. and 1-562-256-4458.

The Separation Principle Applied to Style Accessibility

Separation of information, structure and relationships from presentation applied to the goal of full typographic access is key to literacy for visual readers with low vision.  Any abridgement of this access will limit literacy for some group of people in VR/LV.  For the developers note the following: You have probably been taught the separation principle as it applies to heading navigation and table access.  This access is essential for blindness and helps VR/LV, but it is not the only access needed from the separation principle.  Most web sites that pass WCAG 2.0 at Level AA, do not support typographic access with any grace. This is ironic because, the separation principle was developed to provide flexible control of visual style. Accessibility was a serendipitous after thought.

A computer program can guide the mechanical process of printing by using specific presentation codes with complete accuracy.  However, a program cannot understand the information, structure and relationships in a document well enough using visual presentation codes alone to transcribe one visual presentation of a document to another visual presentation of the same document.

As early as 1967 this had become a serious problem.  Publishers wanted to keep document content in a form that could be presented in a consistent format across complete publication series.  They also wanted to change this visual formatting at will. Below is a description of the change from printer oriented document formats to markup language —originally called generic coding. It appeared in the Boston Globe in an obituary for William Tunnicliffe, the originator of the concept.

"Historically, electronic manuscripts contained control codes or macros that caused the document to be formatted in a particular way ("specific coding"). In contrast, generic coding, which began in the late 1960s, uses descriptive tags (for example, "heading", rather than "format-17"). Many credit the start of the generic coding movement to a presentation made by William Tunnicliffe, chairman of the Graphic Communications Association (GCA) Composition Committee, during a meeting at the Canadian Government Printing Office in September 1967: his topic -- the separation of information content of documents from their format." Harvey Bingham, 12 Sep 1996

Markup language solved the problem of separation.  Unlike specific coding language, markup language  associated content elements with specific deterministic markers so that: (1) Information, structure and relationships could be recognized by deterministic programs, and (2) The information could be presented in many different presentation formats as usage required. It took a long time and considerable effort on the part of many people, for this concept to develop into the SGML Standard, the parent of HTML and the web.  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. 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.

I repeat for emphasis: Most web content does not follow the separation principle well enough for effective visual transformations.  Try a user style sheet to see how well your page translates. To do this you must attach a style sheet from outside your web page. Safari on the Mac or PC makes testing user style sheets the easiest.  If you do this you may learn a lot about how much your own style choices interfere with the style choices of people with low vision.

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.

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.  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. 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.

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.

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.

Some proprietary vendors just do not want to take the extra step. 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.

Even though I understand how the mistake could be made, I have always been surprised that WCAG WG made the decision they did.  Accessibility support for user choice of style is core to supporting visual reading with low vision, and it is a natural outcome of programmatically determined information, structure and relationships.  Without application of the Separation Principle to the problem of visual style, people in VR/LV live in semi-literacy.  WCAG 2.0 actually cites reading assistants, programs that help users change font size, font face, spacing and color as a form of assistive technology in their normative definition of assistive technology.  The Working Group thought this assistive technology was important enough to highlight in a normative definition, but they do not feel that it is necessary accessibility support.

I also find it ironic that a committee of the World Wide Web Consortium came to this conclusion. The ability to obtain flexible data to manipulate visual style was the reason Tunnicliffe proposed separation back in 1967.  The ability to have flexible visual style was the need that propelled the Separation Principle to become the SGML standard. From that came HTML and the web. There would be no W3C without this principle and its application to visual style.

What Can You Do?

Test alternative style sheets on your web pages.  Do not include the alternative CSS in your own HTML code because you will not experience the user's problem.  You must see the problem as an outsider sees it. Use the methods of Safari (preferences) or Internet Explorer (internet options) to add a style sheet from the browser.  You can user Opera or try the Firefox trick I use above.  That will not reveal as many problems in your code, but it will show you how it could look.  My 100 words per page style sheet example given in the last blog is also a good test.  Try your web site out with even higher magnification.  How far can you magnify before your web pages break down completely?

Avoid the shortcomings I identified in my last blog.  Don't use inline styles.  Never use "!important".  Remember, user stylesheets reveal all hidden information.  Design with the goal in mind that some people will be viewing your page in a visual format you never imagined, and part of your job is to help them. Apply the Separation Principle with extreme strictness.  Make it easy for a user to eradicate the style choices you build so carefully into your document for your dominant audience.

Do not choose PDF or use Flash to convey textual content. These file formats are not accessible for VR/LV. If you must reference a PDF document, provide an alternative HTML form if your institution permits it.