Ideas for scope and work topics (August 2021)

Scope of the Reborn LVTF

Background & Genesis

From a legal perspective, "Low Vision" is typically defined as a corrected acuity of 20/70 thru 20/200, with 20/200 being legally blind. However this would seem to imply that this group does not serve the user needs of those with 20/60 or better vision. While laws such as Social Security Disability focus on acuity (ability of the eye to focus and resolve) they ignore a more important visual metric, that of Contrast Sensitivity (CS). Some diseases can significantly deteriorate CS to the point the individual is profoundly impaired, while having little effect on acuity measurements. For instance patients with diabetic retinopathy complain that while their acuity is good, even 20/20, they have difficulty functioning due to substantially reduced contrast perception.

100% of sighted users have visual accessibility needs. Even an individual with perfect vision still has definable needs for best readability. And 100% of sighted users have varying visual needs across their lifetime. It takes 20 years to develop peak contrast sensitivity, and after 40, vision capabilities decline. I submit that describing accessibility regarding vision is best understood as a wide spectrum of needs, and the totality of these needs are in conflict with each other, requiring a broad open perspective that considers 100% of users visual needs.

In January 2021, the LVTF had been dormant for some time, and with concerns about addressing the many visual accessibility issues the following proposal was floated to leadership: Visual Accessibility Task Force partially pasted below as a reference of the initial expected scope:

January Proposal for Review

A proposal to create a Visual Accessibility Task Force.

Such a task force seems increasingly necessary for a variety of reasons. Some goals of the proposed VATF are:

• A central W3 clearinghouse for visual accessibility information.
  • irrespective of standards and with a generalized scope.
• A means to officially liaison with the other W3 standards groups like CSS and HTML.
  • There is much going on in CSS that will affect accessibility.
  • This organization is large enough that “left hand not knowing what the right hand is doing” is a growing concern.
  • We have specific needs for additions to CSS and/or HTML that need proactive management and promotion within the standards tracks.
  • There is obvious massive overlap of technology development that seems to be operating in a near vacuum from each other.
• A compartmentalization of visual accessibility research vectors.
  • E.g. my research and development has specific stated goals, but there may be other proposed research with different end points that are best handled on a separate track.
  • There is a definite need to be able to recruit and assign tasks, such as those mentioned above, that need management and diligent followthrough.
• Outreach and education for new visual accessibility technology and methods.

For instance, there is a lot developing in CSS color that affects accessibility, but I personally am stretched too thin to be effective in lobbying for certain features or changes. The same is true of CSS in general, such as our need for a useable x-height property mentioned above

And finally, while Silver/WCAG 3 is in FPWD stage, and moving forward, my understanding is that WCAG 2.x will continue to be a living standard in parallel for a long time to come. This is a concern, as there are a number of issues, not to mention liabilities for this organization, contained therein. One mission of the VATF would be to present/provide updates for WCAG 2.x that are in keeping with modern research in this field but aligned with the WCAG 2 structure.

Ultimately, I believe a VATF is the proactive approach to address these issues.

Thank you, Andrew Somers

Leadership indicated that reviving the LVTF and potentially renaming it was the better way to go than creating a new charter. Chris got going organizing along with Shawn and John — I'm excited to see the renewed interest in visual accessibility!!! Looking back on today's meeting, let's add in some of the existing work on scope, agenda, and action items:

Should the LVTF be Renamed to Reflect Larger Scope?

Link to discussion

Proposed New Name: VATF • Visual Accessibility Task Force

---

New CSS and Related Technologies

Accessibility is hampered by a number of factors:

• Browser technology is not implemented as needed for best practices for accessibility.
• Content authors lack needed tools and methods to best accommodate best practices.
• CSS, HTML, and related standards do not always evolve with accessibility in mind.
• Some asset types such as web fonts lack consistent parameters or standards.
• Users have limited options for personal customization, which is a key to many aspects of accessibility.

Oversight, liaison, and substantially greater interaction is needed particularly as it pertains to visual accessibility.

Proposed Font Size Related CSS Properties

DISCUSSION: Background on Font Sizing

Proposing a useable x-height property: font-x-size: The depreciated and essentially unsupported font-size-adjust: property isn’t the answer. What we need is a CSS property that can set a font's size by specifying the desired x-height directly.

Examples

div { font-x-size: 12px; } // This would set the font’s x-height to 12px, (more or less a font-size of 24px, depending on ratio)

div { font-x-size: 1em; } // This sets the font’s x-height to the font body height of the parent element font.

div { font-x-size: 1ex; } // This one sets the current font’s x-height to match the parent element’s x-height.

This proposal involves both a new CSS property and also a modification of the usage of ex length (or possibly a new length type.)

Right now, if you use {font-size: 1ex;} that font’s body size becomes the size of the parent element’s lowercase x. Yes this is useful for some things, but I am talking about a different use case. We need a way to directly set a font’s x-height to a specific value. So, if we use 1ex with this proposed CSS property, font-x-size:, it would set the current font’s x-height to match the parent x-height. If we use a different length, then it sets the current font’s x-height to that length.

One of the advantages here is the parent element and child element could both use two different font families, yet maintain the same x-height, or more importantly maintain affirmative control of the relative size of a font as rendered on screen, regardless of the font family used.

Companion Property

Because x-height vs font body height is not consistent, if font size is being set via font-x-size, then the em value needs to be defined relative to the x-height, or else em values will have unexpected results. So, when font-x-size is used to set a font size, then the em value for that element should default to 2x the set x-height. But to allow flexibility, we need to propose the property ex-to-em: to allow flexibility and consistency. The ex-to-em: property will by default set the em size as 2x the x-height of an element where font-x-size: was used to set the font size.

Examples

  div { 
    font-x-size:  12px;  
    ex-to-em: 1.5;
  }
        /* Here, ex-to-em is using a unitless measure, so the em is set to 18px in this case. The default, when only font-x-size is used, would be ex-to-em: 2;   */

  div { 
    font-x-size:  12px;  
    ex-to-em: 20px;
  }
        /* Here, ex-to-em accepts a length, so is used to assert that 1em = 20px in the current scope, without affecting the current font. This would be a good tag to have and use for other purposes. */

  div { 
    font-x-size:  12px;  
  }
        /* Here, the em is 24px, the default when  font-x-size:  is used to set the font size.  */

Font Meta Data

NEED: Add x-height as a required metric in web font files.

DISCUSSION: Meta Data for Web Fonts

---

Proposed LVTF Key Agenda Items

Silver/WCAG 3

Important items relating to WCAG 3 development.

1. Extend the APCA based Visual Contrast guidelines to more clearly include non-text.
2. Also, better define use-case based needs & guidelines.
3. Add guidance for inline link differentiation.
4. Discuss color (hue/chroma) guidance, and the {IP redacted items}
5. Discuss the related design issues of spacing/tracking/leading/padding, providing design guidance, and unifying with the “visually distinct” guideline, as these are directly related to contrast.
6. Font size and user scalability guideline:

Discuss Font size and user scalability on TALK page

WCAG 2.x

Important items relating to supporting the existing WCAG 2.x guidelines.

1. Discuss the “APCA-Lite” alternate contrast guideline(s) as a potential WCAG 2.2 set of SCs
2. There are some visual presentation guidelines in 2.x that would do well with a significant revision, such as the one for inline text links which does not resolve visual needs. Again, leading into Silver but also revising a standard that will be in effect for a long time to come.

Discuss APCA Lite Alt Contrast for WCAG 2 on on TALK page

CSS/HTML/Browser Technologies

Important items relating to the larger scope of web technologies.

1. Discuss the need for liaisons to the many other W3 standards working groups. There are things going on in CSS color for instance that need attention and that have implications for accessibility.
2. To better implement guidelines for Visual Contrast for Silver/WCAG, there are a number of needed properties/tags for CSS such as a font-x-height: property that we need to see implemented due to the importance for accessibility guidelines.
3. The other concept that deserves some discussion is the set of CSS properties that need an “-adjust-by:” parameter, so that a user-defined stylesheet would not over-write, but only adjust the author’s CSS styles. I.e. font-size, spacing, max or minimum size, etc.
4. CSS already has some media-query types for “preferred contrast” etc. but these are not widely used, and are incomplete, and not even discussed in any of the accessibility guidelines... {IP redacted items}

Further CSS and Tech Discussion on TALK page

Ableist Terminology ("Color Blind")

The use of the term "Color Blind" is essentially abelist, and IMO one of the important "tip toe" steps forward is promoting appropriate terminology.

What is Color Vision Deficiency and discussion on TALK page.

see also: this article on terminology

Proposing a New Term

Instead of Color Blind, we need a new term that is not so completely incorrect and ableist. The medical terms for some disabilities are changed as often as every 30 years or so, It should not be too difficult to change colorblind to a better and more correct/inclusive term with the appropriate promotion.

Proposed New Term:

• Color Limited, short for Limited Color Vision

Color Limited Vision is most descriptive of the actual condition.

Agenda question: best pro active approach?

---

Proposed WCAG 2.3 Alternate Contrast SC (APCA lite)

APCA can be modified into a plug & play replacement for the old WCAG 2.x contrast methods, and provide more immediate results (and acceptance), rather than waiting for several years for a WCAG 3 release..

Alternate Contrast SC DISCUSSION on Talk Page

Guideline 1.5 Visually Distinguishable, Advanced Alternate to 1.4

1.5.1 Color Coding, inline links (limitations on hue/chroma for information coding)

1.5.2 Discernible Contrast (APCA for discernibility of other text and informational non-text.)

1.5.3 Readable Contrast (APCA for readability of body text, includes minimum weights and size)

1.5.4 Text resize and reflow (no horizontal scroll, etc)

1.5.5 Inter-variable text scaling (large text no more than 120px, small text up to 92px min)

1.5.6 Preferred text contrast and minimum sizes (optional stronger contrast than 1.5.3)

1.5.7 Text leading, kerning, tracking (letter & line spacing, justification & flow rules)

1.5.8 Text layout – element spacing, padding, margins

1.5.9 Images containing content text (special text design, company logo)

1.5.10 Decorative text and decorative images of text (non-content)

1.5.11 Use of busy bg images/textures under content-text prohibited (textures are no more than Lc 30)

1.5.12 Non-text discernible contrast — static elements (shapes, dividers, disabled fields)

1.5.13 Non-text discernible contrast — focus, hover states (clickable buttons, controls)

1.5.14 Non-text understandable contrast — informational icons or with specific meaning (home, envelope, phone)

---

---

As an example here’s an alternate version of 1.4.3 SC, but using APCA. It is displayed here with the font size and values for english/latin alphabet for easy reading, instead of the explainers on a separate page as they would be in WCAG 2.x. In practice, different languages and alphabet types may have different specs specific to their language.

SC 1.5.3 SAMPLE DRAFT — NOT FOR PRODUCTION

Success Criterion 1.5.3 Readable Contrast

(Level AA)

The visual presentation of readable text, and readable text in images, has an L^c contrast value no less than the following:

BODY TEXT: columns of readable text shall use a font & contrast combination no less than:

• SMALL • 14px at no less than 300 weight has contrast of L^c 90 or more.
• MEDIUM • 18px at no less than 400 weight has contrast of L^c 75 or more.

CONTENT TEXT: all readable text that is not body text shall use a font & contrast combination no less than:

• SMALL • 12px at no less than 300 weight has contrast of L^c 75 or more.
• MEDIUM • 18px at no less than 400 weight has contrast of L^c 60 or more.
• MEDIUM • 24px at no less than 300 weight has contrast of L^c 60 or more.
• LARGE • 36px at no less than 400 weight has contrast of L^c 45 or more.
• LARGE • 48px at no less than 300 weight has contrast of L^c 45 or more.

ANCILLARY TEXT: this is non-content text that is not significant to the use or understanding of the content. It is used such as for copyright, form place holders, bylines, etc. While it is not particularly important, it must still must be visible.

• SMALL • 10px at no less than 300 weight has contrast of L^c 60 or more.
• MEDIUM • 24px at no less than 200 weight has contrast of L^c 45 or more.

BODY TEXT: Body text is defined as more than two lines of text in a block or column format, and intended as content.

BOLD FONTS (weight 700): In general, if the weight is increased from 300 or 400 to 700 for a given font size, the required contrast value can be reduced by L^c15.

INCIDENTAL TEXT: text or non-text that is pure decoration, placeholder text, text not visible to anyone, text that is part of a picture containing other significant visual content, or is a brand logotype, has no contrast requirement, however designers are advised that contrast values lower than L^c30 may be invisible to some users.

---

Additional Discussion regarding APCA as an alternate SC for WCAG 2.x