-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Contrast measurement of text under WCAG3 #285
Comments
Thank you for commenting Ram @RamNathaniel This is a well understood behaviorAnd is already compensated for by the APCA math and lookup tables, and is also discussed in the specification at least to some degree. The new APCA math and minimum font size and weight tables already take this into account in a way the old WCAG 2.x contrast did not. Among other things, the specification indicates that "-webkit-font-smoothing: antialiased" is prohibited for thin fonts (only default sub-pixel anti-aliasing is allowed or contrast must be increased by 30 or font stroke width no less than 2.5px if the blur-type font smoothing is used). Also, the specification is designed around the standard (100%) zoom level, on a minimum resolution screen, and is further based on multiple psychophysical studies on readability (Lovie-Kitchin, Legge, Arditi, et.al.) Most of the highly technical information such as you are mentioning was removed from the actual written standard (to which I objected), but is nevertheless going to be placed into a white paper. Some of the pre-white paper information is here: https://www.w3.org/WAI/GL/task-forces/silver/wiki/Visual_Contrast_of_Text_Subgroup/Whitepaper Thank you for your comments, Andy Andrew Somers |
Hi @jspellman my response above should be complete, but I am unclear if this should be marked "ready for survey" or "comment: no change" ? |
@jspellman This is ready for survey, per Andy’s response on February 22nd regarding the topic of contrast measurement. |
DRAFT RESPONSE: We believe the question has been answered per Andy's comment on #285 (comment) I hope this answers your question, if it does not, please feel free to follow-up. Thank you, |
Hi,
When the WCAG 3 draft (as the WCAG 2.X before) defines the contrast of a text, it uses the defined text color and the background color. In reality, however, this text is then rendered onto pixels, and the graphics card uses an anti aliasing mechanism, making the text round. Such anti aliasing mechanism changes the actual color used, and pixels may get some color between the background and the text color. For example, black text over white background may appear to be shades of gray.
This behavior cause that in low resolution screens, the text appears to be in lower contrast than it is calculated in the WCAG 3 (draft) or previous WCAG 2.X. For (purely) illustration purposes, one can simply take a website that meats the standards, and zoom out in the browser to the extent that the text appears very small - you will notice that the letters become not as contrastive.
I suggest that the committee change the requirements, that in the actual device the original color of the text will be visible, so that when a visually challenged individual tries to read the text, the contrast displayed will not be sub-standard.
Please note - there are ways of implementing and enforcing this - current web pages know the physical resolution they are displayed on, and if the text is defined to have a certain font size in pixels (a common practice), developers can verify that when rendering in such physical resolution the full contrast of the text is displayed. Such validation can also be done automatically, in a very easy manner.
Thank you for your time, and I would love to answer any questions.
Ram Nathaniel
The text was updated successfully, but these errors were encountered: