Second Written Comment to the Access Board about the 508 Refresh

Three New Rules for 508 that Can Be Added to WCAG 2.0 Techniques to Support Low Vision Without Changing Normative Language

In my document, Written Testimony to the US Access Board from the California Council of Citizens with Low Vision, I identified many issues with the 508 Refresh that exclude people from the activity of reading ICT (Information Communication Technology) documents  containing expository text.

I am proposing three new rules that identify failures of accessibility. The fail cases can be added to the 508 Refresh rules without changing the practice of including WCAG 2.0 by reference.  The proposed changes would greatly support the ability to write accommodations for people with low vision. This is because they could be added to the fail cases of WCAG 2.0 Guideline 1.3 without changing normative language of the standard. They are consistent with the wording of WCAG. 

These rules that define content failures should apply to all data formats, not just HTML, CSS and Java Script.  EPUB, MOBI, PDF and any proprietary publication formats for ICT reading material are included. If the PDF standards contradict these fail cases then these rules should override the PDF standard. The rules are meant to provide access to reading all electronic publications, not just web publications. These include but are not limited to: professional journals, news publications in ICT format, BLOG publications, electronic books, electronic instructional materials, and high stakes assessment instruments used for schools and employment.

The ultimate goal of the new rules is this.  (1) Content must make sense and can be read an used when the authors visual presentation is removed. (2) Content is linear and in proper reading order when the author's visual presentation is removed. Finally, the author's visual presentation can be replaced by a visual presentation format that matches the visual requirements of the reader. Specifically, the reader of content can have the color (back and fore), font-family, font-size, letter spacing, line spacing and line length needed to support effective visual reading. No reader should be subjected to horizontal scrolling when reading at any font size so long as the line length fits at least one word per line on a view port.

Most disability technologists view a model of assistive technology (AT) in which the AT resides outside of mainstream applications.  Screen readers and screen magnifiers are not part of browsers or other platform applications.  This model is flawed when addressing the visual customization issues required by people with low vision.  This is because, for visual customization of text there is no more powerful software than the web browser, word processor or portable document player.  What is needed is a way for the assistive technology developer to have access to ICT documents through the mechanism of the browser, word processor or media player.  Specifically, visual flexibility resides in the ability to change the  visual presentation profiles (style specifications). Assistive technology for low  vision needs to replace the style specifications of authors and replace them by style specifications needed by users with special needs. The power of the browser, word processor or portable document player can then be used to display the user's customized visual profiles.  This pathway is non-existent or seriously compromised by the current structure of ICT documents that pass WCAG 2.0 at Level AA or the PDF international standard. The changes given here to the WCAG 2.0 Techniques offer a solution to this problem. For standard HTML this would take the form of custom style sheets prepared for the individual user's requirements. For other technologies template capability could be improved to support this access.

The important thing to note is this would give assistive technology writers access to style through the browsers, word processors and portable document players and they would require no change to the normative language of WCAG 2.0.

Fail Case List

These fail cases result from presentation choices by content authors that prohibit simplified formats that permit reasonable visual adaptability. These should be added to the Techniques of the WCAG 2.0 document and require no change to WCAG 2.0. They are related to Guideline 1.3 and Success Criteria 1.3.1 and 1.3.2. We include the wording here for convenience.

Guideline 1.3 Adaptable:

Create content that can be presented in different ways (for example simpler layout) without losing information or structure.

1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)

1.3.2 Meaningful Sequence: When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined. (Level A)

Exception to New Fail Case 2: Tables that are used to express a grid relationship are exempt from New Fail Case 2. Formally, a table must define a partial function from pairs of rows and columns into a set of data values in order to be exempt from the fail case.  These are called data tables.

Example: A spread sheet type object is a tabular relationship that uses a grid as a mathematical definition of a partial function from rows and columns to values.  Such objects cannot be listed in linear format because the functional relation would be lost.  More complex structures are needed such as heading associations to support non-visual or low visual access.  That is why tables that depend on the grid format to provide meaning are exempted from New Fail Case 2.

Note: The term style specification is used because not all ICT documents use style sheets. PDF, Word and even HTML have ways to specify style for a presentation effect that do not use style sheets exclusively as the method.  Users should be able to remove or change all style specifications and retain meaning. The core concept is that the meaning of content should not depend on visual presentation. Guideline 1.3 calls out "simpler format" as a normative example.

Brief Explanation of the Fail Cases

New Fail Case 1 restores 1194.22(d) of the current 508, which has been lost in the 508 Refresh. The author's visual presentation must be removable. The ability to perceive, operate or understand must not depend on the author's presentation.

New Fail Case 2 states that the format of a document can be simplified to linear by simply removing the author's style. Multiple column format prevents effective enlargement. A page that can be linearized ensures the author's presentation does not disrupt the reading order. This implies the elimination of layout tables since they cannot be rendered linear by removing the author's presentation. This poses no real loss to developers since equal control is available with CSS.  Removal of layout tables was an advisory technique, but with multiple column style specifications in CSS 3 and the ability to set the "display" property on elements to table, table-row-group, table-row and table-cell, use of the table element for layout should be deprecated at last.

New Fail Case 3 simply states that a page should not lose meaning just because the user changes the color or text styles (e.g. foreground and background color, font family, font-size, letter spacing, line-spacing and line length). All of these are aspects of presentation and should be changeable to support better visual perception. While this might seem like a major conceptual change it is consistent with  the wording of 1.3, 1.3.1 and 1.3.2. It can be changed without changing WCAG 2.0. Therefore harmonization can be maintained.

If the author's page is so rigid that it cannot be understandable with enlargement then it fails. If the the author's presentation requires horizontal scrolling with enlargement then it disrupts the understandability and fails. If the author's contrast, an aspect of color presentation, cannot be modified by the user, then the content fails. 

Example of New Fail Cases 1 and 2:

Someone on the Access Board will have a GMail account on a PC.  In Firefox

  1. Go to mail.google.com and log in if necessary.
  2. From the Firefox menu take View > Page Style > No Style.
  3. A redirecting page will appear that references a Basic HTML page with rudimentary functionality.

To see a success case just look at the Access Board homepage. The same procedure creates a readable and linear page.

Other examples of failure include the electronic version of Scientific American, the online New York Times (PDF format), almost all electronic journals and bulletins of the Association for Computing Machinery and conference proceedings published by Springer-Verlag.


Example of New Fail Case 3 and a Correction

The following presentations of program code, in this case HTML, look the same until you try to enlarge them.  The first becomes extremely difficult to read and the second can enlarge almost without limit. The rigid code uses the pre formatted <PRE> element and implements spacing with space characters.  The flexible code uses a data table.  The line numbers are table header cells that span rows. The code lines are table data cells.  Upon enlargement the rigid code content requires horizontal scrolling. The flexible code word wraps nicely. In the rigid code the line numbers are associated visually with the code. With the flexible model the line numbers are related semantically through the table header relationship.  When the text enlarges, the line numbers are still associated visually. A screen reader can read from code cell to code cell and the line numbers are read as line headings. Readers with full visual access do not see this issue as a problem, but it is exactly issues like this that keep students with low vision from graduating in disciplines like computer science.

Rigid Code

Flexible Code