apca-w3 - npm Package Compare versions

		# APCA W3 JS Library Documentation
		### Updated Dec 1, 2021 for 0.98G-4g W3 npm release

		### Updated Jan 10, 2022 for 0.1.0 W3 npm release

		NOTE: colorParsley is now a dependency in its own package.

		This is a set of JS functions/objects to determine a contrast value for a color pair, using the SAPC/APCA methods.
		@@ -10,3 +13,3 @@

		## apca-w3-v.0.0.98g-4g.min.js — SIMPLE QUICK START
		## apca-w3-0.1.0.min.js — SIMPLE QUICK START
		This APCA version is the version licensed to the W3/AGWG for use with web content accessibility standards, WCAG 3.
		@@ -16,32 +19,118 @@

		The sRGBtoY() function takes two sRGB encoded colors, where each color is one of:
		- integer in RGB order, (i.e. 0xRRGGBB or 16777216).
		- a hex string such as #fff or aabbcc (hash # is not required)
		- a CSS named color such as 'aliceblue' or 'magenta'
		- as rgb(123,123,123)
		and then returns luminance (Y)
		## QuickStart
		### _Install_

		The APCAcontrast() function takes the text and background luminance.
		```javascript
		npm i apca-w3
		```

		### API
		The API for "APCA_0_98G_4g_minimal" is trivially simple. Send text and background sRGB numeric values to the sRGBtoY() function, and send the resulting text-Y and background-Y to the APCAcontrast function, it returns a signed float of the numeric L<sup>c</sup> contrast result.
		### _Import_
		```javascript
		import { APCAcontrast, sRGBtoY, displayP3toY, colorParsley } from 'apca-w3';
		```
		### _Usage:_
		PARSE:
		If you need to parse a color string or 24bit number, use the colorParsley() function:
		```javascript
		let rgbaArray = colorParsley('aliceblue');
		```
		CONVERT TO Ys
		Send rgba INT array [123,123,123,1.0] to sRGBtoY() — this is a slightly different luminance Y that the IEC oiecewise.

		The two inputs are TEXT color and BACKGROUND color in that order. Each must be a numeric NOT a string, as this simple version has no string parsing utilities.
		### EXAMPLE:
		```js
		txtColor = 'darkslategrey'; // named color of the text, which is 2f4f4f
		bgColor = 0xabcdef; // numeric color for the background, as will be rendered
		```javascript
		let Ys = sRGBtoY([123,123,123,1.0]);
		```
		FIND Lc CONTRAST
		First color _must_ be text, second color must be the background.

		contrastLc = APCAcontrast( sRGBtoY(txtColor) , sRGBtoY(bgColor) );
		```javascript
		let textColor = [17,17,17,1.0];
		let backgroundColor = [232,230,221,1.0];

		let contrastLc = APCAcontrast( sRGBtoY( textColor ), sRGBtoY( backgroundColor ) );
		````

		### _String Theory_
		The following are the available input types for colorParsley(), HSL is not implemented at the moment. All are automatically recognized:

		### INPUT as STRINGS:
		- No Alpha
		- ` '#abc' ` or ` 'abc' ` (interpreted as ` 'aabbcc' `)
		- ` '#abcdef' ` or ` 'abcdef' ` (hash is ignored)
		- ` 'rgb(123, 45, 67)' `
		- ` 'aquamarine' ` or ` 'magenta' ` (full CSS4 named colors list)

		- With Alpha _(alpha is NOT presently calculated, and assumed as fully opaque)_
		- ` '#abcf' ` or ` 'abcf' ` (interpreted as ` 'aabbccff' `)
		- ` '#123456ff' ` or ` '123456ff' ` (hash is ignored)
		- ` 'rgba(123, 45, 67, 1.0)' `

		### INPUT as NUMBER:
		- As hex
		- ` 0xabcdef `
		- As integer
		- ` 11259375 `

		No alpha parsing for _numbers_ in part as there are big and little endian issues that need to be resolved.

		### Parsing Removal
		The function is called "colorParsley()" because what is that useless leafy thing the restaurant puts on the plate? Well, most mature software already has good parsing, and you may want to minimize the file leaving all that "parsley" at the restaurant.

		In the src folder .js file, there is a ` /*/ ` type code toggle, see the comments just before the parsing fucntions. you can disable the entire set of parsing functions before minimizing if you like to go lean and clean.

		This changes the import to:

		````javascript
		// import with parsing off/removed:
		import { APCAcontrast, sRGBtoY, displayP3toY } from 'apca-w3';
		````


		### Font Use Lookup Table

		```javascript
		// APCA FONT LOOKUP TABLE 0.98G-4g-b3
		// Font Size and Reference Font Weight
		// THIS GRID FOR FLUENT TEXT USE CASE ONLY DEC 12 2021

		const apcaFluentGrid = [
		["min", "min", "min", "min", "min", "min", "min", "min", "min"],
		["min", "min", "min", "min", "min", "min", "min", "min", "min"],
		["min", "min", "min", 95, 90, 85, 80, "min", "min"],
		["min", "min", "min", 90, 85, 80, 75, "min", "min"],
		["min", "min", 95, 80, 75, 65, 60, 55, "min"],
		["min", "min", 90, 75, 65, 60, 55, 50, 45],
		["min", 95, 85, 65, 60, 55, 50, 45, 40],
		["min", 90, 75, 60, 55, 50, 45, 40, 35],
		["min", 85, 70, 55, 50, 45, 40, 35, 30],
		[90, 75, 60, 50, 45, 40, 35, 30, "max"],
		[85, 70, 55, 45, 40, 35, 30, "max", "max"],
		[75, 60, 50, 40, 35, 30, "max", "max", "max"],
		[70, 55, 45, 35, 30, "max", "max", "max", "max"],
		[60, 45, 40, 30, "max", "max", "max", "max", "max"],
		];
		```
		Each color must be a 24bit color (8 bit per channel) as a single integer (or 0x) sRGB encoded color, i.e. White is either the integer 16777216 or the hex 0xffffff. A signed int is returned with a positive or negative value. Negative values mean light text and a dark background, positive values mean dark text and a light background. 60.0, or -60.0 is a contrast "sort of like" the old WCAG 2's 4.5:1. NOTE: the total range is now less than ± 110, so output can be rounded to a signed INT but DO NOT output an absolute value - light text on dark BG should return a negative number.

		### IMPORTANT: Do Not Mix Up Text and Background inputs.
		APCA is polarity dependent, and correct results require that the TXT and BG are processed via the correct inputs.
		-----
		## EXTRAS
		Additional documentation, including a plain language walkthrough, LaTeX math, and more are available [at the SAPC repo.](https://github.com/Myndex/SAPC-APCA)

		PARAMETER CHANGE for 0.98G: The order in parameters is APCAcontrast(text,background) — THIS IS THE REVERSE OF SOME EARLIER VERSIONS. This is because there will be additional background colors in a near future version, such as` APCAcontrast(text, BGlocal, BGsurround, BGpage...) ` and the intention is to follow visible layer order, as a stack from top to bottom.
		### Current APCA Constants ( 0.1.0 - W3 )
		These constants are for use with the web standard sRGB colorspace.
		```javascript
		// 0.98G-4g-W3 constants (W3 license only):

		Exponents = { mainTRC: 2.4, normBG: 0.56, normTXT: 0.57, revTXT: 0.62, revBG: 0.65, };

		ColorSpace = { sRco: 0.2126729, sGco: 0.7151522, sBco: 0.0721750, };

		Clamps = { blkThrs: 0.022, blkClmp: 1.414, loClip: 0.1, deltaYmin: 0.0005, };

		Scalers = { scaleBoW: 1.14, loBoWoffset: 0.027,
		scaleWoB: 1.14, loWoBoffset: 0.027, };
		```

		-----

		## TESTING YOUR IMPLEMENTATION • APCA 0.98 G-4g
		## TESTING YOUR IMPLEMENTATION • APCA 0.1.0 G-4g

		@@ -57,3 +146,3 @@ If you've implemented the code and want a quick sanity check,

		TEXT vs BKGND • EXPECTED RESULT for 0.98 G-4g
		TEXT vs BKGND • EXPECTED RESULT for 0.1.0 G-4g

		@@ -80,3 +169,3 @@ #888 vs #fff • 63.056469930209424

		_Andrew Somers
		_Andrew Somers
		(User Myndex)_
		@@ -83,0 +172,0 @@

docs/Why_APCA.md

		# Why the New Contrast Method APCA
		This is a brief discussion on the need for a new contrast method to guide designers of web content.
		This is a brief discussion on the need for a new contrast method to guide creators of web content. The old WCAG 2.x method and 1.4.3 contrast is being replaced in WCAG 3.0, here is an overview of the need for this change.

		The old WCAG 2.x method and 1.4.3 contrast is being replaced in WCAG 3.0, and as I am the author of the WCAG 3.0 contrast, and leading the ongoing research in this area, I wanted to discuss how the new contrast method fits into the conformance model in a non binary way.
		## The Contrast Problem
		WCAG 2.x contrast and 1.4.3 and the related understandings and guidelines were born in an era before smart phones and iPads, when displays were mostly CRT type and websites used core web fonts. But that was a decade and a half ago. Today the contrast guidelines are in need of a complete overhaul due to the massive changes in computer display technology, web content, CSS functionality, and advances in vision science since 2005/2008, when WCAG 2.x was first introduced. For deeper background, I am on record with this since April 2019 in [WCAG issue 695](https://github.com/w3c/wcag/issues/695).

		### The 1.4.3 Problem
		First of all, WCAG 2.x contrast and 1.4.3 and the related understandings and guidelines are the single "most wrong" part of WCAG 2.x, and the part that was most in need of updates due to the massive related changes in web content and CSS functionality since 2008, when that standard was first introduced. I am on record with this since April 2019 in WCAG issue 695.
		There are a number of reasons that WCAG 2.x contrast is faulty, one of which is the binary pass/fail nature of the SC for a property that does not apply in a binary way across perception nor impairments. Humans are not binary computers, and it is important to understand the non-linear aspects of perception, and to set guidelines that correctly model perception as opposed to "brute forcing" arbitrary values that ultimately do more harm than good.

		There are a number of reasons that 1.4.3 and related are faulty, one of which is the binary nature of the SC for a property that does not apply in a binary way across perception nor impairments. It is a prime example of why "binary" is a fail for conformance models for properties relating to human perception. Humans are not binary computers, and it is important to understand the non-linear and non-binary aspects of perception, and to set guidelines that correctly model perception as opposed to "brute forcing" arbitrary values that ultimately do more harm than good.
		Let's begin with a general understanding of what color and contrast actually is outlined below. See more in my whitepaper ["Introduction to Color and Accessibility"](https://developer.mozilla.org/en-US/docs/Web/Accessibility/Understanding_Colors_and_Luminance#introduction_to_color_and_accessibility) and I also invite you to [read the draft white paper](https://www.w3.org/WAI/GL/task-forces/silver/wiki/Visual_Contrast_of_Text_Subgroup/Whitepaper).

		Let's begin with a general understanding of what color and contrast actually is outlined below. See more in my whitepaper ["Introduction to Color and Accessibility"](https://developer.mozilla.org/en-US/docs/Web/Accessibility/Understanding_Colors_and_Luminance#introduction_to_color_and_accessibility) and I also invite you to see the more in-depth discussions of Visual Contrast conformance at the [W3 Wiki for Visual Contrast](https://www.w3.org/WAI/GL/task-forces/silver/wiki/Visual_Contrast_of_Text_Subgroup)


		## Readability Contrast

		First, like color, contrast is not real. It is a perception. It is not a measure of the distance between two colors.
		Like color, contrast is not real. It is a perception. It is not a simple measure of the distance between two colors.

		Like all perceptions it is context sensitive. It is also substantially affected by spatial frequency, and is primarily a function of the luminance channel, while hue/chroma are far distant in effect, particularly as related to readability. High luminance contrast is required for fluent readability such that the text's words and letter-pairs are properly directed to and filtered by the Visual Word Form Area (VFWA) of the brain, leading into lexical processing.
		Like all perceptions it is context sensitive. It is also substantially affected by "spatial frequency" which essentially means font size and weight, and is primarily a function of our brain's lightness perception (aka luminance contrast). When it comes to color contrast (as in hue/chroma/saturation) the effect is less relevant, particularly as related to readability. High lightness/darkness contrast is required for fluent readability at best speed and comprehension, especially small body text in columns or blocks.

		Above a certain amount, contrast constancy may come into effect wherein further increases in contrast as far as color distances does not have an effect on perception for readability. However, as spatial frequency increases (meaning smaller and thinner letters) perceived contrast drops rapidly, such that lightness distance must be increased to compensate for small thin fonts.
		Above a certain amount, _contrast constancy_ may come into effect wherein further increases in contrast as far as color distance does not have an effect on perception for readability. The smaller and thinner the letters the lower the perceived contrast. Lightness/darkness difference must be increased to compensate for small thin fonts.

		For fluent readability, Dr. Lovie-Kitchin demonstrated, and Dr. Legge also showed, that contrast must be at least ten times the contrast sensitivity threshold (CS) of just noticeable differences (JND), and twenty times is preferred for adequate contrast reserve above the critical contrast.
		- For fluent readability, Drs Bailey/Lovie-Kitchin demonstrated, and Dr. Legge also showed, that contrast must be at least ten times the contrast sensitivity threshold (CS) of "just noticeable differences" (JND), and twenty times is preferred for adequate contrast reserve above the critical contrast.

		This defines the area of "suprathreshold critical contrast for readability." I refer to this as "readability contrast" for simplicity. A similar suprathreshold exists for acuity in terms of font size, which is separate and in addition to the font sizing issues related to contrast spatial frequency. Contributing factors are white space, tracker/leading (letter and line spacing) aspect ratio, weight, etc etc...
		This defines the area of "supra-threshold critical contrast for readability." I refer to this as "readability contrast" for simplicity. A similar suprathreshold exists for acuity in terms of font size, which is separate and in addition to the font sizing issues related to spatial frequency driven contrast. Contributing factors are white space, tracker/leading (letter and line spacing) aspect ratio, weight, etc etc...

		Spot reading contrast has a lower requirement than fluent readability contrast. Non-lexical object contrast also has a lower luminance contrast requirement. And there are some differences in terms of the importance of color (hue/chroma) for some categories of stimuli, and certainly for information coding.

		No single figure such as 4.5:1 is even remotely useful as a blanket statement, and I have demonstrated that it can even be harmful. Some gists with colorful examples of this are:
		No single figure such as 4.5:1 can be used as a blanket target for contrast. It has been demonstrated that WCAG 2 contrast can pass colors that should fail. Some articles with visual comparisons and examples of this are:

		- [Orange You Wondering About Contrast?](https://gist.github.com/Myndex/1dadb6dcac596f1cd7a5686a076f697f)
		- [The Lighter Side of Dark Backgrounds](https://gist.github.com/Myndex/c30dba273aa5eca426ad9f5200917c9d)
		### _Comparitive Contrast Articles_

		- [A Contrast of Errors](https://medium.com/tangledweb/a-contrast-of-errors-373c2665d42a) on Tangled Web, which looks at the history and the current international readability crisis.
		- Part I: [Orange You Wondering About Contrast?](https://gist.github.com/Myndex/1dadb6dcac596f1cd7a5686a076f697f) Answering some contrast questions, and demonstrating a real solution to the infamous orange conundrum.
		- Part II: [The Lighter Side of Dark Backgrounds](https://gist.github.com/Myndex/c30dba273aa5eca426ad9f5200917c9d) An article comparing some parts of APCA with the old WCAG 2 contrast methods, demonstrating how WCAG_2 contrast does not help color vision types, and can cause negative results.
		- Part III: [WCAG 2 vs APCA Contrast Shootout](https://gist.github.com/Myndex/069a4079b0de2930e72d5401bde9af98#wcag-2-vs-apca-contrast-shootout) Answering some recent questions regarding APCA, with comparisons and examples of the old (WCAG 2 1.4.3) and the future WCAG 3 / APCA.

		And finally, the problems of 4.5:1 are not only in accessibility, but fails for normal vision, and further causes such problems for designers that it is often just ignored. 1.4.3 is in fact sometimes ignored even by those who claim to be A11y supporters.
		The problems of 4.5:1 are not only in accessibility, but impacts standard vision. The inherent problems with the WCAG_2 contrast math have been known for some time and [widely critisized](https://macwright.com/2019/03/30/color-contrast-is-a-problem.html). Including studies [by others showing that color insensitive types](https://www.bounteous.com/insights/2019/03/22/orange-you-accessible-mini-case-study-color-ratio/) are not well served. The WCAG_2 contrast specs often cause enough problems for designers [that it is ignored](https://uxmovement.com/buttons/the-myths-of-color-contrast-accessibility/) and today, some 86% of websites are failing WCAG\_2 contrast—but some of these failures are not due to poor accessibility but due to the incorrect math of WCAG\_2 contrast.


		## The Solution
		APCA, the Advanced Perceptual Contrast Algorithm is a part of the larger S-Luv Accessibility/Readability Color Appearance Model (SARCAM, formerly SAPC), which is specifically related to appearance on self-illuminated RGB computer displays, and for modeling impairments, with a focus on readability.

		APCA, the Advanced Perceptual Contrast Algorithm is a product of the larger SLUV Advanced Perceptual Color (SAPC) appearance model, which is specifically related to appearance on self illuminated RGB computer displays, and for modeling impairments.

		### Lightness contrast
		The APCA generates a contrast value based on a color pair, but this value is perceptually based: that is, regardless of how light or dark the colors are, a contrast value of 60 represents the same perceived readability contrast. This is absolutely not the case with WCAG 2.x, which far overstates contrast for dark colors to the point that 4.5:1 can be functionally unreadable.
		The APCA generates a contrast value based on a color pair, and this value is perceptually based: that is, regardless of how light or dark the colors are, a contrast value of 60 represents the same perceived readability contrast. This is absolutely not the case with WCAG 2.x, which far overstates contrast for dark colors to the point that 4.5:1 can be functionally unreadable.

		The APCA contrast value is perceptually uniform, and based on the point where the CS curve flattens due to contrast constancy. Halving or doubling the APCA value relates to a halving or doubling of the perceived contrast.

		### Spatial contrast
		The APCA then uses a lookup table to associate font size and weight to the readability contrast. The lookup tables shown thus far are for latin fonts. Different languages may want to have their own modified lookup tables specific to their needs.
		### Different Uses, Different Contrasts
		The APCA has a set of levels related to use cases — for instance, Lc 75 is the minimum for body text. This makes for an easy way to use ACPA, very similar to 1.4.3 in terms of ease of use.

		### Pass/Fail
		A principal point here is that a strict pass/fail is not instructive, is arbitrary, and not necessarily solving a given user need. In fact user needs when it comes to contrast are conflicting in that what is good for one can be harmful to another. This is even true of font size.
		The APCA also has an optional lookup table to associate font size and weight to the readability contrast (Lc value). The lookup tables allow for even greater accuracy and therefore greater flexibility in design.

		More than anything this points to the importance of real user personalization, an area where the technology is literally missing (and a work in progress). For the guidelines though we can set ranges for targets and expectations toward making the web readable for all. Developing personalization capabilities is ongoing.
		### Failing Pass/Fail
		A key takeaway is that a strict pass/fail with a blanket contrast ratio is not instructive as a guideline, and does not necessarily solve a given user need. In fact, user needs when it comes to contrast are conflicting—what is good for one can be harmful to another. This is even true of font size.

		### Multilevel conformance
		Because of the wide and variable nature of user needs vs use cases in visual contrast, we've divided the scoring into ranges.
		- Preferred: this is the stealth level 5 — it is not a 5 in terms of score, that would still be 4 — but it is a target to encourage designers to work toward when possible.
		- Score 4 is the level for fluent readability best practices, and intended to accommodate sighted users including those with impairments that do not otherwise need assistive technology.
		- Score 3 is a "safety catch" for well designed sites that in testing had a flaw that should not fail the site, but provide guidance for future improvement.
		- Score 2 and 1 are "deficient" and "poor", intended to help sites that currently pass WCAG 2.x but have readability problems still "pass" while providing guidance for improvement.
		- Score 0 is a fail, and fails the site. If a site scores 0 it was likely not passing WCAG 2.x either, though there may be edge cases there.
		This points to the importance of real user personalization, an area where the technology is literally missing (and a work in progress). For the guidelines though, we can set ranges for targets and expectations toward making the web readable for all.

		### Non Binary
		The method for predicting readability contrast is not binary, and the scoring of results is also not binary. It is range based, and dependent on multiple factors, yet is simple enough to be fully automated. So I don't think using the term "binary" is descriptive of this scoring methodology. It is clearly not "pass/fail" except at the extreme edge cases, and demonstrates the value of a range-based approach.
		## Use-Case Ranges
		These general levels are appropriate for use by themselves, without reference to the lookup table.

		In reference to the example tool for demonstrations, the contrast figure is associated with live updates of minimum font size and weight for score level 4: https://www.myndex.com/APCA/simple
		* 90 • Preferred level for fluent text and columns of body text with a font no smaller than 14px, or non-body text with a font no smaller than 12px. Also a recommended minimum for extremely thin fonts (light weight) of any size. Lc 90 is a _suggested maximum_ for very large and bold fonts (greater than 36px bold), and large areas of color.
		* 75 • The _minimum_ level for columns of body text with a font no smaller than 18px, or non-body text with a font no smaller than 14px. Also, should be used for any text where readability is important. This level is functionally similar to 6:1 ~ 7:1 relative to WCAG2.
		* 60 • The _minimum_ level recommended for readable content text, that is, text you want people to read, and no smaller than 16px, and not used as body text. This level is functionally similar to the old 4.5:1 in WCAG2.
		* 45 • The _minimum_ for larger text (larger than 24px normal weight or 19px bold) such as headlines, and large text that should be readably fluently. This is also the minimum for pictograms with fine details, or smaller outline icons. This level is functionally similar to the old 3:1 in WCAG2\.
		* 30 • The _absolute minimum_ for any text regardless of size or weight, including text for spot reading such as placeholder text and disabled element text, and the minimum for "understandable" or "uniquely identifiable" non-text elements such as "mostly solid" icons or pictograms.
		* 15 • The _absolute minimum_ for any non-text that needs to be discernible and differentiable, such as dividers, and in some cases large buttons or thick focus visible outlines, but does not include fine details. Designers should treat anything below this level as invisible, as it will not be visible for many users. This minimum level should be avoided for items important to the use or interaction of the site.

		_NOTES ON FONT SIZE_
		- Font sizes listed above assume an x-height ratio of at least 0.52\. Font weight is based on highly standardized reference fonts such as Helvetica or Arial. "px" means the CSS reference px not device pixels. The reference px is defined as 1.278 arc minutes of visual angle.

		I hope this clarifies the useful differences of a range based or multi-level score from a simplistic pass/fail approach.
		### Range Based Scoring
		While WCAG 3 is still in development, it includes a range-based conformance system. For contrast and fonts it is dependent on multiple factors, yet is simple enough to be fully automated.

		The overall approach improves design flexibility and readability at the same time. Readability is improved by increasing contrast in blocks of body text where it is needed, and design flexibility is achieved by relaxing contrast for large non-text elements which do not need brute force contrast due to their larger size.

		In reference to the example tool for demonstrations, the contrast value (Lc for Lightness Contrast) is associated with live updates of minimum font size and weight for the target score level: https://www.myndex.com/APCA/

		I hope this clarifies the useful differences of a perceptually accurate range-based model as a guideline toward best readability.


		Thank you,
		@@ -80,6 +88,8 @@

		_NOTICE: Personal opinions expressed are mine and may or may not reflect those of the W3 or AGWG unless specifically stated so._

		### _THE REVOLUTION WILL BE READABLE_

		_NOTICE: Personal opinions expressed are mine and may or may not reflect those of the W3 or AGWG unless specifically stated so._
		<img src="images/APCAlogo.png" width="640" alt="APCA The Revolution Will Be Readable">

package.json

		{
		"name": "apca-w3",
		"version": "0.0.98g-4g-w3",
		"version": "0.1.0",
		"description": "APCA the Advanced Perceptual Contrast Algorithm, a modern contrast method developed for WCAG 3",
		"main": "./dist/apca-w3-v.0.0.98g-4g.min.js",
		"main": "./dist/apca-w3-v.0.1.0.min.js",
		"keywords": [
		@@ -11,6 +11,8 @@ "color",
		"contrast",
		"perceptual contrast",
		"design tools",
		"accessibility",
		"readability",
		"WCAG",
		"accessibility",
		"readability"
		"APCA"
		],
		@@ -22,6 +24,14 @@ "author": "Andrew Somers",
		},
		"repository": {
		"type": "git",
		"url": "https://github.com/Myndex/apca-w3.git"
		},
		"homepage": "https://www.myndex.com/APCA/",
		"scripts": {
		"test": "echo \"Error: no test specified\" && exit 1"
		},
		"dependencies": {
		"colorparsley": ">=0.1.0",
		"npm": "^8.3.0"
		}
		}

104

README.md

		@@ -1,15 +0,23 @@
		# APCA • _THE REVOLUTION WILL BE READABLE™_

		<p align="center">
		<img src="images/APCAcolor4.png" alt="APCA The Revolution Will Be Readable" width="420"><br><br>

		<a href="https://github.com/Myndex/SAPC-APCA">
		<img src="https://badgen.net/badge/SAPC/Main Repo/db6b0b" alt="SAPC/Main Repo" />
		</a>
		<a href="https://npmjs.org/package/apca-w3">
		<img src="https://badgen.net/npm/v/apca-w3?color=3000c0&icon=npm" alt="version" />
		</a>
		<a href="https://npmjs.org/package/apca-w3">
		<img src="https://badgen.net/npm/dt/apca-w3?color=6000b0&icon=npm" alt="downloads" />
		<a href="https://github.com/Myndex/apca-w3/src/">
		<img src="https://badgen.net/badge/JS/Vanilla/889900" alt="plain vanilla JS" />
		</a>
		<a href="https://github.com/Myndex/apca-w3/blob/master/LICENSE.md">
		<img src="https://badgen.net/badge/license/W3 • Web Use?icon=github&color=BB5FD1" alt="license" />
		</a>
		</p>
		<p align="center">
		<a href="https://github.com/Myndex/apca-w3">
		<img src="https://badgen.net/github/last-commit/Myndex/apca-w3/?icon=github" alt="last commit" />
		</a>
		<a href="https://github.com/Myndex/apca-w3/blob/master/LICENSE.md">
		<img src="https://badgen.net/badge/license/W3 • Web Use?icon=github&color=BB5FD1" alt="license" />
		<a href="https://npmjs.org/package/apca-w3">
		<img src="https://badgen.net/npm/dt/apca-w3?color=6000b0&icon=npm" alt="downloads" />
		</a>
		@@ -19,31 +27,87 @@ <a href="https://twitter.com/MyndexResearch">
		</a>
		<a href="">
		<img src="https://badgen.net/badge/JS/Vanilla/889900" alt="CSS level 3" />
		</a>
		<a href="https://www.myndex.com/APCA/">
		<img src="https://badgen.net/badge/APCA/Live Tool/db6b0b" alt="APCA/Live Tool/" />
		</a>
		</p>


		# APCA for W3 & WCAG\_3
		## apca-w3
		The APCA in this repositiory is licensed to the W3/AGWG per the collaborative agreement.
		The APCA version in this repositiory is licensed to the W3/AGWG per the collaborative agreement.

		### Advanced Perceptual Contrast Algorithm

		Current Version: 0.0.98G-4g-betafish
		### CHANGE:
		colorParsley() is now in its own package and must be imported separately.

		#### Current Version: 0.1.0 G (w3) _beta_

		APCA is a contrast assessment method for predicting the perceived contrast between sRGB colors on a computer monitor. It has been developed as an assessment method for W3 Silver/WCAG3 accessibility standards relating to content for computer displays and mobile devices, with a focus on readability and understandability.

		### QuickStart
		*Usage:*
		## QuickStart
		### _Install_

		First color must be text, second color must be the background.
		```javascript
		npm i apca-w3
		```

		Lc = APCAcontrast(sRGBtoY(textColor),sRGBtoY(backgroundColor));
		### _Import_
		```javascript
		import { APCAcontrast, sRGBtoY, displayP3toY, colorParsley } from 'apca-w3';
		```
		### _Usage:_
		PARSE:
		If you need to parse a color string or 24bit number, use the colorParsley() function:
		```javascript
		let rgbaArray = colorParsley('aliceblue');
		```
		CONVERT TO Ys
		Send rgba INT array [123,123,123,1.0] to sRGBtoY() — this is a slightly different luminance Y that the IEC oiecewise.

		### Font Use Lookup Table
		Latest Lookup Table: November 17 2021
		```javascript
		let Ys = sRGBtoY([123,123,123,1.0]);
		```
		FIND Lc CONTRAST
		First color _must_ be text, second color must be the background.

		<img width="639" alt="Screen Shot 2021-11-18 at 2 26 32 AM" src="https://user-images.githubusercontent.com/42009457/142399918-60377fdf-39b9-4b80-b75a-01b6e61862dd.png">
		```javascript
		let textColor = [17,17,17,1.0];
		let backgroundColor = [232,230,221,1.0];

		let contrastLc = APCAcontrast( sRGBtoY( textColor ), sRGBtoY( backgroundColor ) );
		```
		### _String Theory_
		The following are the available input types for colorParsley(), HSL is not implemented at the moment. All are automatically recognized:

		<img width="596" alt="Screen Shot 2021-11-18 at 2 33 34 AM" src="https://user-images.githubusercontent.com/42009457/142400008-101f5891-1cff-4d3a-b689-4679fc53cb53.png">
		### INPUT as STRINGS:
		- No Alpha
		- ` '#abc' ` or ` 'abc' ` (interpreted as ` 'aabbcc' `)
		- ` '#abcdef' ` or ` 'abcdef' ` (hash is ignored)
		- ` 'rgb(123, 45, 67)' `
		- ` 'aquamarine' ` or ` 'magenta' ` (full CSS4 named colors list)

		- With Alpha _(alpha is NOT presently calculated, and assumed as fully opaque)_
		- ` '#abcf' ` or ` 'abcf' ` (interpreted as ` 'aabbccff' `)
		- ` '#123456ff' ` or ` '123456ff' ` (hash is ignored)
		- ` 'rgba(123, 45, 67,1.0)' `

		### INPUT as NUMBER:
		- As hex
		- ` 0xabcdef `
		- As integer
		- ` 11259375 `

		No alpha parsing for _numbers_ in part as there are big and little endian issues that need to be resolved.

		### Parsing Removal
		The function is called "colorParsley()" because what is that useless leafy thing the restaurant puts on the plate? Well, most mature software already has good parsing, and you may want to minimize the file leaving all that "parsley" at the restaurant.

		In the src folder .js file, there is a ` /*/ ` type code toggle, see the comments just before the parsing fucntions. you can disable the entire set of parsing functions before minimizing if you like to go lean and clean.

		This changes the import you need to use to:

		```javascript
		// import with parsing off/removed:
		import { APCAcontrast, sRGBtoY, displayP3toY } from 'apca-w3';
		```

		-----
		@@ -50,0 +114,0 @@ ## EXTRAS

dist/apca-w3-v.0.0.98g-4g.min.js

src/apca-w3-v.0.0.98g-4g.js

src/test.html

Sorry, the diff of this file is not supported yet

New alerts

Fixed alerts

Improved metrics

Worsened metrics

Dependency changes