Low Vision Proposal: Needs

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 [1] 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 society.

HTML with CSS and Javascript can achieve all of the 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 is needed.

Everything that is described here can be achieved by documents with a primary use of reading, using HTML, CSS and Javascript. This content includes but is not limited to: news papers, magazines, professional and research papers, conference proceedings, law, case law, trade magazines and books.

Need— Choice of presentation down to the element/ tag/ role level

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 presentation include:

Responsibility for element level access— [2]

Content— Content must be encoded so that information, structures or relationships are expressed using element/ tag/ role level semantics. Using progressive enhancement with HTML/ CSS/ Javascript this can already be achieved.  Content types that cannot support this type of coding are not accessible to people with low vision.

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

Need— Navigation, Operation

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.

Need— Synchronized text-to-speech [2]

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

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.

Responsibility for synchronized text-to-speech—

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

Conclusion:

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.




[1] 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 face.

[2] While the responsibility of assistive technology is critical here, the topic is too large for this essay.