APCA Alternate SC for WCAG 2.3 Proposal #31
Replies: 2 comments 2 replies
-
|
Can you give more insight into the process of this proposal? Eg. has it been accepted? Is there any review date and expected acceptance date (if the review goes well), who reviews it, etc. You mention "several years for a WCAG 3 release", can you elaborate why it takes so long? Is this because this isn't people's main job, because the team doesn't meet regularly, because tests needs to be scheduled and/or funded? |
Beta Was this translation helpful? Give feedback.
-
|
Hi bart @bartclaeys No, I am told that this will never become part of WCAG_2 ever. The charter for WCAG_2 does not allow for correcting past mistakes like the contrast math. There is a version I am releasing this week that is called "Bridge PCA" that is backwards compatible and therefore needs to official approval to use it. If you pass Bridge-PCA, you pass WCAG_2 automatically. I don't have much to comment on the rest — the standards process is slow regardless of the organization. It is always a multi-year process. |
Beta Was this translation helpful? Give feedback.
-
|
There are no plans for WCAG 2.3. But there are no plans that there not be a WCAG 2.3 either! Please see the AG WG charter, and the scope/out-of-scope portions in particular. If the AG WG decides to work on a WCAG 2.3, it might not be the case that the strict backwards compatibility (that 2.1 and 2.2 enjoy) is a prerequisite. So |
Beta Was this translation helpful? Give feedback.
-
Hi Bruce @bruce-usab Really? I was given the impression that it was a non-starter, but that is encouraging to hear. Due to the extended timelines, and the rather unexpected interest and early adopters, I've been looking into other formalized avenues in terms of standards. |
Beta Was this translation helpful? Give feedback.
-
Proposed WCAG 2.3 Alternate Contrast SC (APCA lite)
This was a proposal to incorporate APCA into WCAG 2.3. 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..
In "New-Sibling" concept, the entire 1.4.x group of SCs are replaced by an alternate group, the 1.5.x group. A site could choose to conform to either 1.4.x OR to 1.5.x.
Sample SC — NOT FOR PRODUCTION
Success Criterion 1.5.3 Contrast (Minimum)
(Level AA)
The visual presentation of readable text and readable text in images has an Lc contrast value no less than the following:
BODY TEXT: columns of readable content text shall use
a font & contrast combination no less than:
CONTENT TEXT: all readable content text that is not body
text, shall use a font & contrast combination no less than:
ANCILLARY TEXT: non-content text that is not significant to use
or understanding should use a font & contrast combination no less than:
INCIDENTAL TEXT: no specific contrast requirement, but designers
are advised that text contrast values lower than Lc 30
may be invisible to some users.
DISCUSSION
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.
WCAG 2.x contrast is entrenched. Completely replacing it for a WCAG 2.3 is not going to fly. Instead, I propose we create a new sibling category of SCs such as 1.5.x that can be chosen as an alternate 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
Why Change WCAG 2 Contrast?
In April 2019, I started thread #695, detailing my first analysis of the problems inherent on the WCAG 2.x contrast math. The short answer is the entire WCAG 2.x contrast method and math are not really useful, and in fact not much better than a coin-flip, with the alleged "useful results" being a product of confirmation bias. This is laid out in thread #695 which includes a literal ton of prima facie evidence on this subject.
No Blame, No Game
When WCAG 2.x and 1.4.3 was developed, circa 2005/6, there was no "Google fonts"", the iPhone was just beginning, web fonts like Verdana were fairly robust. And importantly, we all used CRT displays instead of LCD, and sites frequently used the default font sizes around 16px & black on light grey, and web fonts that were only normal or bold. So the significant problems introduced with today's thin fonts, small device screens, and content rich JS enabled sites were not yet an issue, whereas they are today.
Here are three quick comparative articles with examples. These were using an earlier version of APCA, but the results are similar.
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, see especially the third article "shootout".
Specifics on Features
APCA for WCAG 3 is a new paradigm in predicting readability and discernibility contrast. It is highly inclusive, science based, easy to implement and use, and sensible & functional for both designers and end users.
Body Text and Font Sizing
“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.
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.
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.
x-Height
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”.
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…
Supra-threshold Contrast
Basically, for fonts smaller than 24px to 32px or so, they do not derive much benefit from contrast constancy and the contrast sensitivity (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.
Guidelines 1.5.x Visually Distinguishable, Advanced Alternate to 1.4.x
(clickable buttons, controls)
As an example here’s an alternate version of 1.4.3 SC, but using APCA.
SC 1.5.3 SAMPLE DRAFT (With Definitions) — 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 Lc contrast value no less than the following:
BODY TEXT: columns of readable text shall use a font & contrast combination no less than:
CONTENT TEXT: all readable text that is not body text shall use a font & contrast combination no less than:
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.
BOLD FONTS (weight 700): the required contrast value for a weight 700 font can be reduced by Lc15 relative to a weight 400 font of the same size and family, but never to lower than Lc30.
INCIDENTAL TEXT: no contrast requirement, but designers are advised that contrast values lower than Lc 15 may be invisible to some users.
DEFINITIONS
REFERENCE FONT: All size and weights are based on the reference font.
TEXT VALUES: Body text and content text values are intended for minimum fluent readability at best speed and comprehension. Columns of text require higher contrast than single lines of text. Ancillary text values are intended for basic legibility and spot reading.
BODY TEXT: (Critical Fluent Readability) Body text is defined as more than two lines of text in a block or column format, and intended as content.
CONTENT TEXT: (Fluent Readability) this is readable text important to the understanding or use of the content, but that is not body text in blocks or columns. This includes headlines, buttons, menu controls, etc.
ANCILLARY TEXT: (Spot Readability) this is non-content text that is not significant to the use or understanding of the content, and can be It is used such as for copyright, form place holders, bylines, etc. While it is not particularly important, it must still must be visible.
INCIDENTAL TEXT: (Undefined Readability) 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 Lc15 may be invisible to many users.
NON TEXT ELEMENTS
SYMBOLIC NON TEXT: Elements that are not lexical but that do have specific meaning that needs to be understood, such as icons, pictographs, and certain kinds of controls that are more than simple buttons.
DISCERNIBLE NON TEXT: Elements that are neither lexical nor symbolic, such as a form input, simple buttons (the shape, not including text), page or text dividers, focus indicators and other visual feedback.
Beta Was this translation helpful? Give feedback.
All reactions