Possibly adding SCs to WCAG 2.3 - Lc tool ?

Here's the example SC for reference, using APCA (Lc)

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 300 weight has contrast of L^c 90 or more.
MEDIUM • 18px 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 300 weight has contrast of L^c 75 or more.
MEDIUM • 18px 400 weight has contrast of L^c 60 or more.
MEDIUM • 24px 300 weight has contrast of L^c 60 or more.
LARGE • 36px 400 weight has contrast of L^c 45 or more.
LARGE • 48px 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 300 weight has contrast of L^c 60 or more.
MEDIUM • 24px 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.

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.

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

[Additional Discussion regarding APCA as an alternate SC for WCAG 2.x]: https://www.w3.org/WAI/GL/low-vision-a11y-tf/wiki/Talk:Agenda#Body_Text_and_Font_Sizing_Discussion

Hi @Myndex I like your list of criteria. The ability of the criteria numbering to change in WCAG 2.x is very unlikely. Many of these are covered - but covered in different criteria at different levels. If we pursue somethin for 2.3, etc. we'd probably need to determine if we had criteria that plug the holes or if we need to change levels of current criteria. I agree reorganizing as a whole would make most sense as it makes the whole guideline more clear - but my expectation is that may be a challenge. We also need backwards compatibility for 2.x - so a proportional allowance with potentially higher resize would fit as an addition to the current 1.4.4.

Hi Jonathan @mraccess77

Well, the idea here is to find a way to incorporate APCA, the new contrast math into WCAG 2.3 as an alternate SC — we've already established that we can not replace the WCAG 2.x contrast wholesale — but Bruce, Chris and I were talking about the possibility of adding it as an alternate to the 1.4.3 et al... so, as an alternate, to be effective, it would need all the 1.4.x modified to support the APCA math. Thus came the idea to mirror 1.4.x SCs with a 1.5.x series — this would give designers the choice to use either 1.4.x or 1.5.x.

The backwards compatibility is that the 1.4.x SCs would remain unchanged. The 1.5.x SCs would be an alternate, thus backwards compatibility is assured, and forward compatibility is the ultimate goal.

Content creators are outspoken regarding their distaste for WCAG 2.x contrast — and as you may remember that is how I ended up here in the first place a few years ago. We've established how it's faulty and to what degree. We have a functional replacement that is perceptually uniform and very functional. But WCAG 2.x contrast methods are codified into law in many places, so it can not be wholesale replaced (which of course would be my preference).

APCA is a complete paradigm shift, rooted in modern vision science, and aligning with modern technologies. "New" is ideal for WCAG 3, but "alternate" is what is called for for WCAG 2.x.

Thank you!

Andy

The outcomes of 1.4.x would all need to be met for backwards compatibility - so I'm not sure how we could have an alternative unless the outcomes for text such as the ratios hard coded into 1.4.3 were met. If you could share details of that we need to discuss with the Accessibility Guidelines working group chairs.

Taking an alternative route would mean you could meet 2.3 but not 2.2 which would create confusion or lead to lack of adoption of 2.3.

Hi Jonathan @mraccess77

Well, the idea was for 2.3 that the 1.4.x SCs would all still be there, unchanged. The 1.5.x SCs would be added as a "set" of alternates that could be used instead of the 1.4.x SCs, this way there would be no conflict, the 1.5.x set would be an optional alternative to the 1.4.x,

Before the rebirth of LVTF, @bruce-usab and @ChrisLoiselle and I discussed this as a possible path forward. HOWEVER, I am not read in on all the politics and workflows fo W3/AGWG, for that I rely on all of you — to me it seemed that the best path was as a set of alternates to the group of 1.4.x SCs, which have issues due to the underlying problems with the older math/methods.

But my understanding has been that replacing the WCAG 2.x contrast math is a non-starter. Maybe @bruce-usab can chime in on this as he's been my main liaison with the W3/AGWG since I started this project (April 2019). If you told me that we would change the entire set of 1.4.x using a version of APCA, instead, then I could make that happen, but I've been told that can not happen.

Here are some things:

I designed APCA to use a simple number, L^c for "perceptual lightness contrast" for two reasons. 1) A simple scalar value is the better way to create a perceptually uniform model (ratios is not).

I'm on record regarding how WCAG 2.x contrast ratios do not work as intended.
The fix is not to try and modify a perceptually uniform model to fit into that older space.
It's not just the WCAG 2.x math that is at issue, it is the SCs that were created for it as well. It's the whole package. I don't see some minimally invasive approach here. At the very least, this not like changing a tire. 2) Perhaps more important, an APCA value like L^c60 will not get confused with the ratio 4.5:1, even though they may have a similar intent.
If APCA used ratios, there would be a massive issue of confusion of "which math created this ratio" and we don't want that.
APCA is perceptually uniform, and accurate, for how we perceive suprathreshold contrast for readability. WCAG 2.x is not, and as a result the SCs that were created around WCAG 2.x don't really apply as written to APCA.
The way to address this (discussed a few months ago) was a complete set of SCs that could be used as alternates, and that were written specifically for use with APCA.

Maybe Bruce or Chris can chime in here — I am not as in touch with the inner workings of AGWG, but I am open to discussing ways to take this science and bring it into 2.3.

Thank you,

Andy

w3c / low-vision-a11y-tf