> My initial instinct is that finding 12 colors that are visually distinguishable for all users is likely impossible.
Without going to lightness extremes, I agree that this likely isn't possible, at least when trying to accommodate all three types of dichromacy and for small color patch sizes (like those typically used for line and scatter plots). For example, you could take the 10-color accessible palette from work I've published [1] and add black and bright yellow to get twelve colors, but the lightness extremes of adding these colors would result in significantly-different visual weights. Based on a validation survey I conducted, I think even ten colors is pushing the limit of what's reasonable when lightness extremes aren't used.
> could share what colors in the 12-bit palette...are problematic
#9d5 and #4d8 is the color pair I find particularly problematic.
While not completely identical, it looks very similar (I also only have strong protanomaly, not complete protanopia, so I wouldn't expect it to look identical).
Color-vision deficiency simulations collapse colors along the confusion lines, but this can be done multiple ways. These different mapping will all look the same (and identical to the original) to a dichromat but will appear different, with different perceptual differences between colors, to a color-normal individual. Simulating in a way that accurately portrays perceived color distances is still an open research problem.
Please don't use rainbow-type palettes, as they generally have poor accessibility for colorblind individuals. With my red deficiency, the middle two colors in this palette look virtually identical.
I wrote a simple web-based night sky viewer a while ago [1], which renders the 750 brightest stars from coordinates in a data file (along with the moon). It uses D3.js to do fully client-side SVG-based rendering for interactive use, but it could be simplified to render server side to an SVG file. I think the main complication is that by adding stars, a projection needs to be decided on, and you'd need to consider the aspect ratio of the browser window.
However, to properly screen for color vision deficiencies requires calibrated spectra. Thus, even a color-calibrated monitor is insufficient, since color calibration assumes that the standard cone response functions are valid, which isn't the case for anomalous trichromats (which encompasses the most common types of colorblindness). This is why screening, such as with the HRR test, is done with plates printed with spectrally-calibrated inks in controlled lightning conditions (again with a known spectrum).
With images taken at night, you can run the images through Astrometry.net, which is a blind astrometric solver and will provide you with RA / Dec for most images, as long as you have at least a dozen or two stars visible. The code compares asterisms formed by multiple stars to index files built from Gaia or other similar data. This is the technique that's used more frequently for microwave telescopes located where there's a normal diurnal cycle, e.g., CLASS. The smaller the field of the view, the higher the precision, but it also works fine with a camera with a zoom lens.
BICEP, however, is located at the South Pole on a moving ice sheet, requiring frequent updates to its pointing model, and has six months of continuous daylight, so daytime star pointing observations are required. This requires a different technique. Instead of looking at asterisms with multiple stars, the optical pointing telescope is pointed at a single star using an initial pointing model, the telescope pointing is adjusted until the star is centered, and the offset is recorded. This measurement process is repeated for the few dozen brightest stars, which acquires the data needed for refining the pointing model.
BICEP3 actually uses a >20 year old CCD camera with analog video output (BICEP Array uses newer cameras, with more modern sensors). Daytime star pointings are possible by using a low-pass filter to block visible light and take advantage of the sensitivity of CCD / CMOS sensors to the near infrared, where the daytime sky is more transparent, combined with baffling.
> the default color palette is colorblind-friendly
No, it very much isn't. The second and third colors, the orange and the green, look extremely similar to protanopes (red deficiency). Fortunately, there's a plan to fix this for Matplotlib 4.0.
You're correct, and the other responses saying otherwise are misinformed. Protanopes do not have long-wavelength cones and thus have reduced sensitivity to that end of the visible spectrum, i.e., red light appears dimmer to such individuals. This is also why red on black (or vice versa) is a color combination with poor accessibility, since it has reduced contrast for protanopes as the red appears darker and thus closer to black.
That's to be expected since the Coblis methods, particularly the v1/ColorMatrix version, are known to be very inaccurate. Unfortunately, it's usually the top search result for "colorblindness simulator," which leads folks with normal color vision who try to check for color vision deficiency accessibility to conclude that the images they're checking are accessible in cases when they're not.
It applied a linear transform to RGB values, like the current method, but the original matrices were the "colorjack.com matrices" [1] that have been floating around the internet for a while. They weren't derived scientifically and are quite inaccurate, at least for protanopia.
For those interested, I've done some recent research on this topic [1], which tries to find cycles of colors that optimize both accessibility for color vision deficiencies, using simulations and minimum perceptual distances, and aesthetics, using crowd-sourced survey data.
The simulation technique [1] currently used by the Firefox / Chrome dev tools is reasonable, so it's definitely much better than not checking for color vision deficiency accessibility at all. Ideally, color should only be used for progressive enhancement; if your UI can be used in grayscale, it's probably fine.
However, the method originally used by both browsers, which is also used by some other tools, had no scientific provenance and produced clearly incorrect results, so one needs to be careful about this sort of thing in general.
I'd argue that the 147 named CSS colors are still too many (but definitely better than the ~16.8 million sRGB colors). Regardless, since hex codes are used in practice, they would still need to be dealt with.
This would be true if the CSS color names were actually reasonable, but many of them are not.
One would be better off using the results [1] of Heer & Stone (2012) [2] (or a similar analysis) to assign names to sRGB colors. You end up with 33 unique names instead of more than 100, and the number of unique names can be reduced further by merging synonyms.
The WCAG also define the contrast ratio in terms of sRGB, which is not a perceptually-uniform color space. This makes the WCAG contrast ratios somewhat meaningless in terms of human visual perception. It's accessibility by edict, not science.
There's a rather lengthy discussion of this on the WCAG issue tracker [1].
The issue isn't with referring to colors on a chart by name but with using a color name as the sole identifier. Referring to parts of a chart by color is fine, and provides additional information, as long as a line style or shape identifier is also used, e.g., the "blue solid line" and the "orange dashed line" in the case of a line plot or the "blue circles" and the "orange squares" in the case of a scatter plot. Ideally, I think color swatches should also be included when referring to colors, so it isn't necessary to match the name to the color [1].
> The key would be to spend an absurd amount of time carefully cataloguing good colors – by hand – and training it to extrapolate from that information.
It's a bit more nuanced than that. Not only do you need to catalog good colors (and color combinations), you need to have it done by a large number of people, since different people perceive color differently and have different aesthetic preferences. This is something I've been working on in the limited context of color cycles for data visualization and plotting [1][2]. Based on my preliminary analysis, these data are quite noisy.
Without going to lightness extremes, I agree that this likely isn't possible, at least when trying to accommodate all three types of dichromacy and for small color patch sizes (like those typically used for line and scatter plots). For example, you could take the 10-color accessible palette from work I've published [1] and add black and bright yellow to get twelve colors, but the lightness extremes of adding these colors would result in significantly-different visual weights. Based on a validation survey I conducted, I think even ten colors is pushing the limit of what's reasonable when lightness extremes aren't used.
> could share what colors in the 12-bit palette...are problematic
#9d5 and #4d8 is the color pair I find particularly problematic.
[1] https://arxiv.org/abs/2107.02270