This is a first draft at defining what is needed to extend access to people with low vision/ partial sight. Currently, WCAG provides ineffective support for people with low vision who (1) need enlargement of more than 200% (20–24 point font), (2) cannot use an interface that requires horizontal scrolling for reading,operation, or understanding, (3) require additional text customization to read effectively or (4) require synchronized text to speech.
While many of these features appear like usability
issues to users with normal vision, they interfere with the
perception, operation and understanding of web content for people
with low vision with greater frequency and more impact than they
do for people with normal vision. In this context these usability
issues become barriers to access. Reading a font face that is
smaller than your critical print size  is
annoying. For example, legal disclaimers are sized to discourage
reading. For all people who are classified as having a low vision
disability in the United States and around the world (20–24 point
font, 200% of normal) is well below the critical print size. That
means that all reading is like reading legal disclaimers, a
barrier. Horizontal scrolling is annoying if you encounter it once
a week. It is a barrier when you must use it to do almost
everything. Single spacing is not optimal for normal readers, but
its impact on tracking causes most people with low vision to make
numerous reading errors per view port. This usability issue thus
becomes an accessibility barrier. These barriers inhibit
education, employment and participation in society. The problem
with these barriers is that they preempt any chance of equally
effective access to necessities of social participation in modern
accessibility needs expressed here with no changes to authoring
tools or browsers. There are many changes to authoring tools
and user agents that would assist this accessibility. Many are
anticipated in the UAAG 2.0 document. Limited by WCAG 2.0 the ATAG
2.0 document does not include low vision support that exceeds WCAG
2.0. Other document types that cannot support these requirements
may achieve WCAG 2.0 accessibility but they are not accessible to
the population identified here. The barriers to use are too high
for all but a highly skilled, tiny minority to surmount.
This document tries to address which agents are
responsible for these capabilities, but the primary focus here is
not whether developers, content types, user agents or authoring
tools can do it using current models. This essay focuses on what
Reason: (for element/
tag / role
level access to presentation)— The presentation structure of small
capacity view ports must be significantly different from those
with normal and large capacity. For example, size is a poor
feature to distinguish headings from other text in a low capacity
view port. Large headings just waste too much space. Responsive
design has refined restructuring to a science. The key is that
presentation control over elements is a necessary condition for
presentations to fit in limited space. Specific choices for
Semantically void elements like <span> and <div> associated with presentation must be for decoration only, or they must contain roles. They cannot be used to convey meaning through presentation. The reason for this is clear. These constructs are created and referenced using author defined identifiers that cannot be parsed deterministically. The meaning cannot be accessed by a program. For example, <span class="citation" style="font-style: italic">...</span> is readable by a human but programmatically non-deterministic.
Note: Using the definitions and language of WCAG 2.0 this requirement already includes information, structures and relationships expressed at the text level. There is non-normative language that softens these conditions for some types of content, but the normative language requires text level separation of semantics from presentation.
User Agent— Display of presentation modifications provided by assistive technology need to be incorporated into content and rendered. UAAG 2.0 guidelines 1.4 and 1.8 address many of these issues. There are some exceptions in CSS 3 that enable user agents to ignore CSS for certain form elements. This really compromises access.
Authoring Tool— Authoring tools
themselves must satisfy these rules. The immutable multiple column
format of authoring tools makes coding a daily accessibility
struggle. The panels are close to unusable without screen
magnification (a constant usability challenge). The code space
leaves precious little space for large print code. Word
wrapping that preserves indentation is rare. The practical
mitigating features that assist with usable formatting are not
labeled as accessibility features, and take days and weeks to
find. The presentation of most authoring tools makes it clear that
no consideration of professional use by people with partial sight
occurred. At the content level, the authoring tool must
actively promote using elements/ tags/ roles to express
information, structures and relationships and warn when
semantically void elements/ tags carry presentation. ATAG 2.0 B.2
anticipates much of this need. B.2.4 requires assistance with
The primary content needs for navigation and
operation are covered in current WCAG 2.0. Limited view port
capacity creates navigation issues similar to screen
reading. When a view port holds from 15 to 50 words, the
[page up] and [page down] are not effective navigation tools.
There are also some special needs relating to mouse access:
Click access for text-to-speech— Reason: Screen readers support non visual access. Partially sighted users may not be able to read the content of a paragraph but they can see that they are viewing a paragraph and may know exactly which paragraph they want to read (i.e. The first paragraph after a given heading.) This is mainly an assistive technology issue, however a user agent option to set focus on an object with a click even if it is not coded to be receive focus would draw screen reader focus to the object, and enable text-to-speech orientation via mouse. One hack for files like a Bookshare book is to set tabindex="0" on every paragraph, and then read with a screen reader by tabbing paragraph to paragraph.
Increased Focus Visibility— Reason: The current implementations of the focus visible requirement are not too visible. While this is primarily a user agent issue, content can be coded to support this. Perhaps authoring tools could explicitly support visible focus templates. For partially sighted users this WCAG requirement (2.4.7) can enable or disable mouse use.
By synchronized text-to-speech we mean visual tracking of the
text being read aloud. This can be done by visually
highlighting paragraphs, sentences, lines or words in spoken
Rationale: Synchronized TTS is a good way to read documents of intermediate difficulty to the user. One can read quickly but focus on the content a little more than one can with simple audio. Also, the bimodal presentation can reduce reading errors. Note: A self paced medium like customized type without voice can be used to support extremely focused reading like formulas or success criteria.
separation of semantics from presentation is the first
requirement. To synchronize highlighting and speech the AT
needs to know its position relative to the document objects and
reading position at all times.
User Agent— The user agent must inform the AT as to the reading position relative to elements/ tags/ roles and physical lines and position on the view port as rendered for support for the user. UAAG Guideline 2.5 addresses this. Assistive technologies should use the information from Guidelind 2.5 to set the reading pointer.
Authoring Tool— As before guidance
in producing semantic markup is the first goal. Semantic markup of
text level objects must be strongly encouraged or enforced. It may
also be desirable to enable authors to set tabindex="0" to give
focus to items like paragraphs that usually do not receive focus.
This is a beginning point for needs. This will
cause difficulty for developers and manufactures of text formats.
It will require change in the models used for assistive
technology, because the models we have do not work for a super
majority of people with partial sight. We can either live in
denial of the fact that screen magnification does not support
effective reading for a super majority, or we can expand our
notion of accessibility support to match real user needs. Today
WCAG does not support the needs of almost all people with low
vision, because it does not support the needs stated above.
It is time for WCAG to move from accessibility guidelines in name
to accessibility guidelines in fact.
Low vision is a good place to start. It reminds us that we cannot force disabilities into models. We must modify our models to accommodate disabilities.
 Critical Print Size (CPS)— This the
minimum font size at which a person reads at maximum speed. This
is approximately 10-12 point for normal readers, depending on font
 While the responsibility of assistive
technology is critical here, the topic is too large for this