Silver Community Group Teleconference

20 Dec 2019


jeanne, Chuck, janina, Lauriat, CharlesHall, Fazio, bruce_bailey, shari, LuisG, joe_cronin, KimD
jeanne, Shawn


Clear Words update

Visual Contrast pseudocode write-up

<Chuck> https://docs.google.com/document/d/1lmTpfgublIqRggMVbrwo55FMlyJo3Avp_TAvpuFttxI/edit#

<scribe> scribe: jeanne

Chuck: This is the structure: THere are a number of templates that have influenced the structure.
... we have been working on it via email.
... the older versions are in the later part of the document. Only need to review pages 1-7
... we used CLear Words for the latest structure.
... the Tests: I used the same format as the old WCAG standard
... used ANdy's pseudocode

<CharlesHall> i especially love “No font should be smaller than 14px for any content that is intended to be readable.” i vote for this being included in the normative section at some point.

Chuck: then there is a table that lists the values of how we recommend the results to be.

Andy: We are only presenting 1-7. Pages 8 and up are older material.

<Zakim> bruce_bailey, you wanted to ask for conversion from px to pt

Bruce: I want to know the basis of the px.

Andy: Visual angle, as the CSS reference pixel. This is defined by angle, and is the basis of determining resolution of the monitor.

<CharlesHall> is CSS reference pixel the density independent unit?

Andy: we used the CSS reference pixel.

Bruce: We have been using the CSS reference pixel.
... what size is 14 pixel?

Andy: That's the CSS reference pixel

<CharlesHall> what would the value of translation to point units be?

Andy: 1.33 points per pixel.
... 1.278 minutes of arc, which is what is used in research
... it is a research term
... The CSS reference pixel is the density independent unit. It's based on how the manufacturer wants to assign it.

Jeanne: The CSS reference pixel is the standard. Manufacturers choose to interpret it differently (like apple retina display is 2x CRP)

Andy: W3C: 96px display at 26 inches.

<Andy> 28"

Chuck: There was a question from Charles and a comment from Bruce, so I want to know how to present the information so that information is better presented.

Bruce: I have used points my entire professional like, and I'm not that comfortable using pixels for fonts

ANdy: That is what is used on the web.
... px is the canonical unit

<LuisG> +1 more than just web from Jeanne

Bruce: We can't ignore that designers use pts.

jeanne: We should provide both because we want to be beyond web, and we want to be usable.

<KimD> +1, I think we need a second unit

<Fazio> print doesn't reflect the same amount of light that screens project

<Fazio> The projected light from a screen changes the relationship

Jeanne: We aren't going to cover print, but we are going to go beyond web

<CharlesHall> i believe it is appropriate to use a single unit conversion example to solidify the formula used to convert CSS reference px. however, i don’t believe pt is a relevant unit.

<Fazio> More info for understanding I feel is important

<CharlesHall> +1 to that being confusing to designers using tools that still have pt as a value

<Fazio> Explaining the relationship of points to pixels is important to explain

Andy: I did this work solely in pixels

Jeanne: We won't do print, but there are many tools that still use points.

<Zakim> Lauriat, you wanted to ask about e-ink displays.

Shawn: What about the different types of displays such as e-ink. Google docs works surprisingly well on a KIndle, although the refresh rate is a bit slow.

Chuck: For our draft, we realize that there are a lot of things that we can do for individual monitor and ambient light. But for the February draft is that we are going to limit the scope to pixel to pixel like the current standards.

Andy: Some of the new monitors like e-ink are lacking in research.
... the bells and whistles, like dynamics, spacial frequency, and @@ are not part of this draft.
... the math is designed to include scalar tests, but it isn't here yet.
... this is based on existing research and existing standards.

<Lauriat> Very helpful, thank you!

Jeanne: Do you have questions for us?

<CharlesHall> it is not clear in the table what passes as sufficient.

Andy: Are we set up to handle the various types of impairments? This shows the baseline. I think there should be advanced criteria that may be personalizations

<Zakim> bruce_bailey, you wanted to ask what is contrast requirement for text at 16px

Bruce: I'm looking at the chart. At a default text size, it allows designers more flexibility than maybe we would think are ideal.
... so when I look at the chart, it appears that what the default would be 7:1. Am I reading it right?

<bruce_bailey> Minimum contrast requirement for normal size text seems MUCH higher to me than what we have in 2.0

Andy: Many of the things that designers do as best practices change the actual contrast. We go down farther with larger fonts. THere are six listed here.
... these are based on how we perceive the size of letters.
... there is a big problem with web fonts in the last 10 years because there are thinner fonts.

Bruce: This is a separate issue -- a better algorithm is a separate issue than that contrast in WCAG isn't sufficient anymore.

<Lauriat> Visual Contrast Draft link reposted: https://docs.google.com/document/d/1lmTpfgublIqRggMVbrwo55FMlyJo3Avp_TAvpuFttxI/edit

Chuck: I pulled some numbers that people are familar with.

Bruce: The reason that WCAG went with 4.5:1 because of 3 color problem. You cannot have 3 colors in 7:1

Andy: Contrast is about spacial frequency, not color.
... designers are using 200 weight fonts AND making them gray.
... my assumption is that they don't understand the history of the development of lighter weight fonts (to modulate black newspaper ink)

<CharlesHall> forgive the contrarian view, but this is the argument i always provide visual designers that feel constrained by choice:

<CharlesHall> “There are 140,737,479,966,720 combinations of hexcodes. Obviously not all of them are accessible. If only 1% of all color combinations are accessible, then there are still almost 141 million combinations to choose from. This seems more than adequate to paint any bikeshed you will come across for the rest of your career.” — “The Veil of Ignorance”, Adam Morse

Andy: 4.5:1 is a problem with normal vision, not even starting people with visual disabilities.
... in this formula, the width of the stroke is an important part of the formula.
... this is supported by an enormous body of research for decades.

<CharlesHall> no that is within the wcag range for 4.5:1

<bruce_bailey> @charles hall, at 8 bit, there are not very many color triples that provide 4.5:1 between all three

Bruce: This is fine for text. But what about the 3 color problem? You can't have a 7:1 for color with three colors

<CharlesHall> 141 million combinations that are conformant

Chuck: This is in the table at 60%

Bruce: The 4.5 was chosen to allow a background color, a text color and a heading color and all have contrast.

Andy: There is no AAA here. THis is really only an issue on small thin body text fonts. That's where the 7:1 comes in.
... maybe we need to make it 80% (? scribe got confused)
... It fixes some of the major problems in WCAG, especially with dark colors. I'm at the very peak of 4.5 where it works the best on sites.
... we want to make it the easiest sell -- the math is different because the WCAG levels are inconsistent with perception.

CHuck: It was my idea to put in the equivalents, so people would be more comfortable. BUT, it seems to be having the opposite effect.

Bruce: I'm afraid we are increasing the requirements

Andy: But the math is different, and we actually aren't increasing the requirements.

Shawn: I see designers using current WCAG because we are required to. But they apply it across blocks of text. I think we need to revisit that. And I think we need to show the rationale for the higher requirements.

<bruce_bailey> Agree that current draft is in a pretty good space

Shawn: I think this is good for the first draaft.

<CharlesHall> +1 to color examples. based on the sheer volume of articles on this topic (including outside of US), it is abundantly clear that the current luminance formula is challenged when certain combinations of colors fall in the prescribed range but fail perception.

Chuck: Our goal is to have something for January. What does this need to look like for February.

Shawn: It needs to be representative of where Silver is going.

<Lauriat> +1 to what Charles wrote on color examples.

<Chuck> Chuck: I'm not comfortable (yet) writing methods. I don't know about Andy. We may need some outside blood to do methods.

Andy: If all the colors are light, it is pretty close to WCAG. As the colors get darker, WCAG isn't as perceptually uniform.

Jeanne: Chuck - the new template is at https://docs.google.com/document/d/1Smly4XDxfzfXHa7AoUxoLXLy_3PdOXMkh0ZwtgksSPk/edit#heading=h.8j6pwbsnl608


There are no formal meetings for the next two weeks, however some of us will be calling in to work on projects during the daytime meeting times. I'm not epxecting anyone at COnformance call times because that is Christmas Eve and New Years Eve. There will be people on the Tuesday morning and Friday call times.

Happy holidays to all.

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2019/12/20 20:03:08 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Present: jeanne Chuck janina Lauriat CharlesHall Fazio bruce_bailey shari LuisG joe_cronin KimD
Found Scribe: jeanne
Inferring ScribeNick: jeanne
Found Date: 20 Dec 2019
People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)

[End of scribe.perl diagnostic output]