Talk:Ideas for scope and work topics (August 2021)

From Low Vision Accessibility Task Force
(Redirected from Talk:Agenda)

I am not a regular contributor on any wiki other than those under WAI/GL. What is the thinking behind having this talk page being so long and so similar to the article? Both of those aspects I find to be blockers to having a conversation. Bruce Bailey (talk) 14:13, 1 September 2021 (UTC)

Well, Template:Reply to when I saw that Sam was adding discussion, I wanted to move the discussion portion over to this talk page, and simplify the main page down to a list and perhaps some proposals, though those perhaps proposals should go to a page dedicated to that purpose. Is this me taking something simple and making it too complex again? 😳 Andrew Somers (talk) 13:11, 2 September 2021 (UTC)


AGENDA OPEN DISCUSSION

This is the talk page for the meeting agenda page. The agenda page should include only the gist of the agenda item or a proposal, and then link to the supporting discussion on this page. This separation is intended to keep the Agenda page easy to view during a meeting. Each agenda section should link to a discussion on this page,

Agenda and Discussion Guidelines

Main agenda page format/content guidelines:

  • Agenda item is preferrably a single bullet point. By agenda item, I mean a specific topic for discussion in the meeting.
  • A proposal, such as a new CS property, will entail much more than a bullet point, but should be kept to the minimum to describe the proposal.
  • Link here for both agenda items and proposals. A link immediately after the title to a section on THIS talk page with the supporting commentary, to facilitate a more open discussion here.
  • Add new agenda items or new proposals at the bottom of the Agenda page, organization and archiving to be determined at a later date.

This agenda talk page format/content guidelines:

  • Use separate subsection headings to discuss different agenda items: Mixing it all into one long post complicates discussion.
  • Sign your posts with four tildes (~~~~), which automatically turn into your username and a timestamp, like this: Template:Nobr
  • Minor edit flag is only for typographical corrections, formatting fixes, and similar changes that do not substantively change content.
  • Separate multiple paragraphs with whitespace: If a single post has several points, it makes it clearer to separate them with a blank line. However, avoid adding blank lines between lines that begin with wikitext symbols for lists. These symbols include:
    • asterisks (*), which make bulleted lists;
    • hash symbols (#), which make numbered lists;
    • semi-colons (;), which make the first half of an HTML association list (rendered as bold-faced text); and
    • colons (:), which make the second half of an HTML association list, but which are popularly used for the resulting visual indentation effect.
      • note that colons automatically add paragraph whitespace with newlines.
  • Thread your post: Use indentation as shown below to clearly indicate to whom you are replying. Normally colons are used.

Discussion Formatting

== Sample Subsection Header ==
The first comment in a section has no colons before it. To make a new paragraph, return twice.

The same user is continuing the first comment, blank newline added
to format paragraph separately ~~~~
: Second comment, a reply to the first comment is indented one level. ~~~~
::Third comment, a reply to the second comment should be indented one more level. ~~~~
::This is another user's reply to the ''second'' comment, indented same as previous comment. ~~~~
:A subsequent reply to the ''first'' comment is indented one level. ~~~~

The above formatting looks like:

Sample Subsection Header

The first comment in a section has no colons before it.

The same user is continuing the first comment, blank newline added to format paragraph separately User One (talk) 02:49, 1 July 2021 (UTC)

Second comment, a reply to the first comment is indented one level. User Two (talk) 02:49, 1 July 2021 (UTC)
Third comment, a reply to the second comment should be indented one more level. User Three (talk) 02:49, 1 July 2021 (UTC)
This is another user's reply to the second comment, indented same as previous comment. User Four (talk) 02:49, 1 July 2021 (UTC)
A subsequent reply to the first comment is indented one level. User Five (talk) 02:49, 1 July 2021 (UTC)

AGENDA DISCUSSION SUBSECTIONS

Should the LVTF be Renamed to Reflect Larger Scope?

Can we consider renaming this reborn LVTF to express a more encompassing scope?

DISCUSSION: Visual Accessibility is one area of a11y that encompasses nearly the entire population. And it is the most variable and the least binary in nature. Visual perception does not fall neatly into a little binary cubbyhole. And what is a good accommodation for one person may be harmful to another. The fact there are these interferences indicates that we must look at the bigger picture. (see what I did there?)

Further there are emerging technologies such as HDR Rec2100 / UltraHD which are amazing in terms of image quality, yet also present significant issues for visual accessibility. All that said, I'd like to suggest that we rename the LVTF to reflect this with a more inclusive title:

Proposed New Name: VATF • Visual Accessibility Task Force
Other possible ideas:
  • VWTF • Visual Web Task Force
  • RTF • Readability Task Force
  • RCTF • Readable Content Task Force
  • HPTF • Human Perception Task Force

Andrew Somers (talk) 03:13, 28 August 2021 (UTC)

Indeed, I think this is an important point to discuss. I would like to see our scope reflecting the experience for everyone in the population, and yes some of these needs are conflicting, which may require some user agent adaption to resolve. Sam Waller (talk) 12:42, 31 August 2021 (UTC)


New CSS and Related Technologies

DISCUSSION

Background on Font Sizing

Two very needed CSS properties are font-x-size: and the companion ex-to-em: Also needed is a means for addressing the inconsistencies of font weight and perceived contrast to provide better guidance in terms of guidelines and standards for content design.

Spatial Frequency is a primary determiner of perceived contrast, and by extension readability. In a practical sense, spatial frequency most relates to font weight & stroke width (border width), but also font size, and tracking/leading (letter and line spacing). While developing the SAPC and APCA algorithm for Silver, investigation revealed scientific consensus that spatial frequency, and not color, is the more critical factor when it comes to perception of contrast, particularly at high spatial frequencies (small and thin fonts). This has substantial implications for critical font size and weight, as well as the critical color distances.

The Font Problem: in the early 80s, before personal computers and WYSIWYG desktop publishing, I did newspaper pasteup the old fashion way: sending things to a typesetter, getting it back a day later and using razor blades and hot wax to pastup. The ink was black only, never grey, so to modulate contrast we’d use a lighter or heavier weight font. Today, it takes nothing to flick the CSS color codes into some truly bad design choices.

But wait, there’s more: this problem has accelerated since 2009 and WCAG 2.0. Back then, everyone used ”web safe” fonts, because it was problematic and unreliable to do it any other way. Websafe fonts were mostly a decent weight to render well onscreen (notable exceptions like the atrocious Courier New just prove Microsoft does not pay attention to needs.) Also a decade ago, most web designers just used black with a light background. And in truth, that is how we learned way back when: Strong contrast, especially for body text.

Fast forward to our modern era and folks who have never even heard of an offset press, or know why it was best to use only use black ink on body text, and modulate contrast with font weight instead. And Then…. Google FONTS. Google fonts made font access easy for all designers, hosting a thousand free fonts, in all weights including too thin to see for even normally sighted individuals. And designers are using these thin fonts AND using them with light grey all at the same time, not grasping the ancient design theory behind thin fonts in the first place. Combine this with webkit-smoothing, and boom, half the internet is unreadable now. A contributing factor is that people think the WCAG ”4.5:1” is a valid target for everything, when nothing could be farther from the truth.

Font Inconsistency: There are few real standards for fonts: there is no standard for instance that specifies the ratio of the x-height to the font-size. As a result, it is difficult to predict how content will appear on some browsers. Fonts are literally all over the place in terms of their x-height. Take a look at this font evaluation for plenty of examples of inconsistent x-height.

But if we are authoring standards, we need a consistent and repeatable way to determine things such as how big a font renders on the screen. Defining the standard around x-height makes the most sense, as the vast majority of text is composed of the lower case letters. If we could affirmatively set the font's rendering size based on x-height, we could set a consistent size regardless of variations in font design (whimsy fonts notwithstanding). Andrew Somers (talk) 03:30, 1 September 2021 (UTC)

Indeed, I agree that x-height is really important, and it would make most sense to define the threshold values on this basis. Conveniently though, the ratio of x-height to font-size is constant for a given font-name. So, it would seem plausible to generate a lookup table that converts font-size to x-height for the most commonly used fonts, and I would think it would only take a few minutes to add an extra font-name to this list. This might make it possible to enable automated checking of compliance via x-height, without requiring a new CSS property to be introduced and recognised by the browsers. Sam Waller (talk) 12:42, 31 August 2021 (UTC)
That's not guaranteed. And there are a lot of name conflicts, plus there are so many fonts that such a lookup would be huge and of marginal utility. Look at the PANOSE registry for one. an external third party database for metadata is a non-starter — lookup to a third party site? Maintain a mirror on the present server? All destined to fail. BEST PRACTICE: metadata should be in the file it is related to. Determining the x-height from the font itself is straightforward, with the exception of swash/fantasy fonts. Regardless there is a definite benefit to having the x-height embedded in metadata in the font file along with the many other metrics. the x-height property IS already available in many font files, but not enforced. For accessibility, it needs to be enforced for web fonts, with a fallback for the user agent determining x-height by examining the lower case x glyph.Andrew Somers (talk) 07:25, 1 September 2021 (UTC)

font-x-size: Proposal Discussion

See Agenda Page for proposal of font-x-size:

Ridding the internet of thin, light grey fonts is a core goal of this work, the following proposed CSS properties support this goal. 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.

We really need to be pushing to get this into CSS 4! Andrew Somers (talk) 03:30, 28 August 2021 (UTC)

Font Meta Data

The W3C has specs for web fonts — but it barely mentions x-height. And font metadata is inconsistent in font files as well. This is identified as an area that needs attention and some consistent and standardized best practices. So in addition to the two new properties for CSS listed above, we would also want to add x-height metadata to the font spec for at least webfonts to help facilitate the use of x-height for font-sizing.

It is certainly possible for a user agent to sample the lowercase x glyph to determine the x-height, but that can fail in some cases such as swash fonts. Creating a mandatory metadata field in the webfont specification provides this power to the font designer where it belongs. Andrew Somers (talk) 03:30, 28 August 2021 (UTC)

Proposed LVTF Key Agenda Items

Silver/WCAG 3

DISCUSSION

Font size and user scalability guideline:

Discuss the need for the proportional scaling method that is not based on percentage

Regarding scaling: the current 200% requirement is weak, and does not address the larger issue. 200% is literally the difference between 20/20 and 20/40. This does little the help low vision. Plues the problem with large fonts or headlines — those should not be scaled up by the same percentage. For best readability, the critical font size is a font that is two to three times larger than the acuity minimum. for normal vision that is about 14px to 16px. For 20/40 that is 28px to 32px. For low vision, a font size of 92px can be needed..But we also weant to prevent fonts larger than 120px as that impacts readability as well. Andrew Somers (talk) 05:37, 1 September 2021 (UTC)

WCAG 2.x

DISCUSSION

APCA Lite Alt Contrast SC

  • Discuss the “APCA-Lite” alternate contrast guideline(s) as a potential WCAG 2.3 set of SCs, and 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.

I consider this an important “stepping stone” into the more complete APCA based contrast guidelines in Silver. The very favorable response in the design community to APCA thus far makes me think this is a useful path, and has the added benefit of providing an earlier replacement to the much maligned 2.0/1.4.3 etc. SCs. Considering that the 2.x guidelines will be “live” well after Silver is official further increases the need to do this. Andrew Somers (talk) 05:37, 28 August 2021 (UTC)

CSS/HTML/Browser Technologies

  • Discuss the need for liaisons to the many other W3 standards working groups.

Over the last two years of research into visual needs, one thing that is abundantly apparent is that there is too much conflict between individual visual user needs to have any “one size helps all” design guideline — user needs profiles and user customization is ultimately the direction we need to promote for true universal accessibility. This is much more a matter of browser technology and CSS flexibility for user adjustments, and we need to take a more proactive approach promoting these goals. Andrew Somers (talk) 05:37, 28 August 2021 (UTC)

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

CVD is a condition wherein some of the "color sensing" cells of the retina are impaired or missing, resulting in difficulty discriminating between certain colors. Some variation of this condition affects an estimated 6% of the population, primarily males. However, it is important to know that the vast majority of CVD individuals can still see some colors.
99.998% of those with CVD are not color blind. They only have a reduced color discrimination. Even the most profound deuteranope or protanope can still see hundreds of thousands of colors (far shy of the many millions of normal vision, but not devoid of color perception). Only the very rare achromatopsia is monochromatic, and that small group has other more serious vision problems that require AT regardless of their lack of color discrimination. (For instance, blue cone monochromacy is also afflicted with low vision of 20/70 or worse, and severe photophobia. There is some discussion regarding taking blue cone monochromacy out of the CVD classification all together.) For live examples, see the CVD Simulator.

Like most things in perception, CVD is not an absolute, but a wide spectrum of subtle variations from a mild reduction in discrimination ability, to a complete inability to discern between reds and greens for instance (deuteranopia/protanopia). But these most common types do see blue, and colors that stimulate the S cone (blue). Andrew Somers (talk) 05:37, 28 August 2021 (UTC)

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. Some ideas here to float:

Candidate Term:
  • Color Limited, short for Limited Color Vision
Color Limited Vision is the most descriptive of the actual condition.

Alternate Candidate Ideas:
  • Hue Affected, short for hue affect disorder
  • Color Impaired, short for impaired color vision
  • Chroma Deficient, short for chroma deficient perception
  • Color Dark, short for diminished color vision
  • Chroma Reduced, short for reduced chroma perception
  • Low Color, short for Low Color Vision

Andrew Somers (talk) 05:37, 28 August 2021 (UTC)

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

Body Text and Font Sizing Discussion

“Body Text” is a particularly important distinction from all other text due to density and resulting impact on spatial frequency/contrast. The fact it is not given special consideration is one of the problems with the current 1.4.3, Some other 1.4.3 fails that should be addressed are a minimum size for all content text (i.e. 12px or an x-height of 6px), as well as a minimum weight (major glyph strokes no less than 1px) and prohibiting the use of “font smoothing” for thin small fonts. Andrew Somers (talk) 05:37, 27 August 2021 (UTC)

Indeed, I would like to see 2.3 mentioning the difference between 'body paragraphs of text' and 'short words/phrases of text for spot reading', with different requirements for each. I would be glad to discuss the most appropriate terminology for these different types of text Sam Waller (talk) 12:54, 31 August 2021 (UTC)
I just added the definition for body text to the example draft:
BODY TEXT: Body text is defined as more than two lines of text in a block or column format, and intended as content.
It is stated as such in the WCAG 3 draft as well. Andrew Somers (talk) 06:42, 1 September 2021 (UTC)

As for weight: neither CSS 700 nor CSS bold are defined in a standard way, anywhere. Font weights are not standardized, and this has been a problem since before the Italians started printing and competing with Gutenberg in the 1400s !!! That said, weight 700 and bold are both “technology agnostic” and defined in CSS as being equivalent, as is 300 for light, 400 for normal and 700 for bold.

{IP in development: a standardized font weight assessment tool} At the moment we only have “Major stroke widths equivalent to Helvetica for a given weight and x-height” it's a little weak, but it’s where the technology is at. As I’ve discussed elsewhere, ALL the font metrics affect contrast and readability, including the built in spacing, kerning, ligatures, counters, etc. ad nauseam…

A critically important future advancement is to define CSS text sizes in terms of the proposed "font-x-height", and not "font-size” which defines the font's body, but is not at all standardized in terms of the size the glyphs render onscreen. And there is no useful CSS property for setting font size via x-height as discussed above. Presently we are stuck with using font-size, and then adding a disclaimer of “assuming the x-height is 50% of the font size”.

WCAG 2.x contrast is entrenched. Completely replacing it for WCAG 2.3 is not going to fly. Instead, I propose we create a new category of SCs such as 1.5.x that can optionally be used instead of the 1.4.x series SCs. In other words, alternates for 1.4.3 and 1.4.6 and a complementary non-text SC to replace 1.4.11, then adding complementary spacing and resize SCs as alternates to replace 1.4.4, 1.4.8, 1.4.12 Andrew Somers (talk) 05:37, 27 August 2021 (UTC)

Indeed, I agree WCAG 2.x contrast warrants specific discussion within this group. I would particularly like to understand the rationale behind this statement, which I cannot currently follow the logic for (From https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum.html): "The empirical finding that in the population, visual acuity of 20/40 is associated with a contrast sensitivity loss of roughly 1.5 ARDITI-FAYE. A user with 20/40 would thus require a contrast ratio of 3 * 1.5 = 4.5 to 1."Sam Waller (talk) 12:54, 31 August 2021 (UTC)
Somewhere, possibly in thread #695, I discuss how this is a spurious assertion with no basis in fact nor evidence. The math is wrong, and there is no basis for a contrast sensitivity of 1.5 to be a multiplier of anything. The Peli Robson CS scale is log, and 2 is normal vision, 1.5 is impaired, and 1.0 is low vision. Consider that for a moment. A higher value, 2, is better vision, how could 1.5 then be a multiplier? Dr. Arditi is cited but he never said anything like this, and in fact in Dr Arditi's 2017 article he laments the lack of any empirical evidence for the "long held standard" of 3:1, indicating it was an assertion with no empirical basis. Andrew Somers (talk) 05:37, 1 September 2021 (UTC)
I would think the next steps might depend on whether this statement can be supported by actual evidence that 4.5:1 vs 3:1 actually makes a difference for those with 20/40 vision, or whether 4.5:1 contrast can be defended in a different way. This might feed into whether we need to change 1.4, or provide an alternative section 1.5 as suggested.Sam Waller (talk) 12:54, 31 August 2021 (UTC)
The short answer is no, it is not supportable. The entire WCAG 2.x contrast method and math is bot really useful and not much better than a coin-flip, as i laid out in thread #695 which includes a pile of prima facie evidence on this subject.
When 2.x was developed, in 2008, there was no Google fonts, mobile devices were just beginning, and web fonts like Verdana were fairly robust, and sites were mostly using the default size of 16px. So, there was not the significant problem of today's thin fonts, small device screens, etc. Many of the problems with the 2.x/1.4.3 contrast were known back then — the far reaching consequences were probably not apparent, but otherwise I'm not going to get into any of the by gone politics on that subject.
That said, the 1.4.3/WCAG 2.x is NOT going to change. Once approved it is cast in stone. It is a matter of law in many nations. That it is wrong to this degree is why I devoted years in the research and development of replacement methods and maths, leveraging my nearly 40 years of professional experience in in color, imaging, vision, and light in here in Hollywood to the task. The best that can be done regarding WCAG 2.x is an add-on alternate solution, which is what I proposed on the Agenda page.Andrew Somers (talk) 05:37, 1 September 2021 (UTC)
Also, I believe the current contrast thresholds are not fit for purpose when considering light text on dark backgrounds. This could perhaps be fixed by moving to a different contrast calculation method (as proposed by Andy), or it might be fixable by specifying different threshold levels for dark on light text as supposed to light on dark text. This might mean the issue could be minimised by rewriting 1.4, rather than providing an alternative calculation method via a new section 1.5. I would be glad to further discuss these possibilities in future meetings Sam Waller (talk) 12:42, 31 August 2021 (UTC)
As I mentioned above, re-writing 1.4 is off the table, and I am just conveying what I was once told. "There shall be no changes to legacy WCAG 2.x documents". And when WCAG 3 is live, WCAG 2.x will *continue* as a normative document. 2.0 & 2.1 will not be changed in any material way, it's left the building so to speak, and is codified in law. But besides that, there is no point trying to "modify" it when the underlying approach is wrong. If you look at thread #695, I had some modified add-on SCs being discussed a couple years ago, such as a minimum background color, but that still does not fix the underlying problem. Such a "fix" is like using Bondo™ & paint to cover up the corrosion on a truss that's rusted through. The bridge is still gonna fall. This: `(L1 + 0.05) / (L2 + 0.05)` is a single point failure, or perhaps better stated, it's using a hammer to screw in a wood screw... into concrete. It does nothing useful, and provably permits false passes that harm CVD individuals, while falsely failing color pairs that would be preferred for CVD. In other words, it can make matters worse.
I have a couple quick comparative articles with examples. These were using an earlier version of APCA, but the results are similar, please take a look as it answers a lot of your questions:
And also, it is not just light text on dark backgrounds where it fails. In the above example articles, you'll see it breaks for dark color pairs, passing colors that should fail. This has been gone over often over the last couple years, so I'm just trying to catch you up to where we're at. The best proactive solution is to fix future versions. Thus far, the proposed fix has the support of the design community, who otherwise reject the old WCAG 2.x Andrew Somers (talk) 05:37, 1 September 2021 (UTC)

Link to Draft Examples of the 1.5.3 SC (Alternate Contrast Method)

CONTINUED DISCUSSION

Indeed, I agree that something along the lines of the above would be a huge step in the right direction. However, I'm not currently convinced that bold fonts should allow contrast to be reduced for body text, if there is evidence that supports this than I'd be glad to see it, or alternatively the guidance regarding bold fonts could be limited to content text. In order to confirm the actual thresholds, I think we would first need to find some way of defining the levels of vision ability that we would expect to be able to read the text, without requiring adjustment via the user agent.Sam Waller (talk) 12:54, 31 August 2021 (UTC)
By design, the Lc values are about 15 between a 300/400 and 700 font that is otherwise the same size. Part of the emphasis here is to not break lots of WCAG 2.x sites, and the present 1.4.3 SC has a corollary in that the inflection point is an 18.5px bold font or a 24px normal font. That said, I'm not opposed to prohibiting that contrast reduction for body text, as that is a principal problem with the internet today.Andrew Somers (talk) 06:42, 1 September 2021 (UTC)
I'm not currently sure how the thresholds ought to be affected by 300 vs 400 weight font. I would be glad to see the evidence/rationale that supports the current proposals, and/or discuss this point further in future meetings.Sam Waller (talk) 12:54, 31 August 2021 (UTC)
Basically, for fonts smaller than 24px to 32px or so, they do not derive much benefit from contrast constancy and the CS is still substantially affected by spatial frequency. And threshold is not really a good term here. For readability, contrast needs to be far supra-threshold, 10 to 20 times the contrast of JND. That said, even suprathreshold, small thin fonts are in contrast deficit due to spatial frequency, thus the contrast minimum is increased relative to the CS curve. In fact if you look at the lookup tables, the CS curve is somewhat visible in the table values. Andrew Somers (talk) 06:42, 1 September 2021 (UTC)
I'm not currently sure about whether the distinction between ancillary and content text is unavoidably essential, and I'm not currently sure whether this distinction could be tested in an automated manner. I would be glad to discuss this point further in future meetings.Sam Waller (talk) 12:42, 31 August 2021 (UTC)
We are pushing for substantially higher contrast for body text, as well as a minimum font size which the current 1.4.3 does not do, so something has to give. This demands the addition of ancillary text, things like "copyright" or byline, that do not need to be highly readable must have a relaxed standard. In classical design they are usually tucked away, "fine print". It would be very wrong to demand that a copyright notice for instance be at the same high contrast and size as content. Such an assertion is unsupportable, but must be codified in the SC to exclude it from the other minimums. Andrew Somers (talk) 06:42, 1 September 2021 (UTC)

Add New Agenda Items Below
Retrieved from "https://www.w3.org/WAI/GL/low-vision-a11y-tf/wiki/index.php?title=Talk:Ideas_for_scope_and_work_topics_(August_2021)&oldid=3973"