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
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.
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.
Create content that can be presented in different ways (for example simpler layout) without losing information or structure.
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.
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.
Someone on the Access Board will have a GMail account on a PC. In Firefox
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.
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.