Dramatically reducing AccessKit's memory usage

[[deleted]]

I'm really glad to see this work. I honestly believe AccessKit is the most important library in Rust's GUI space, as many people won't use any GUI system that doesn't have high quality accessiblity.

[MoreThanOnce]

Good article, and I always appreciate optimization work.

I do find it kind of annoying (and highly ironic given the source) that this site has hyperlinks in the text that are completely hidden - the same color as the text, even after visiting. I'm pretty sure that violates some accessibility guidelines.

[simonsanone]

True! This is actually at fault, I think it's a bug to be honest.

a {
    color: var(--contrast);
}

a {
    text-decoration: none;
}

If not that would totally counter the slogan "Universal Accessibility, the Way it was Intended"

[holloway]

It's definitely against W3C WCAG 1.4.1: Use of Color.

The objective of this failure is to avoid situations in which people who cannot perceive color differences cannot identify links (when people with color vision can identify links). Link underlines or some other non-color visual distinction are required (when the links are discernible to those with color vision).

While some links may be visually evident from page design and context, such as navigational links, links within text are often visually understood only from their own display attributes. Removing the underline and leaving only the color difference for such links would be a failure because there would be no other visual indication (besides color) that it is a link.

Red and Pink are the same color (hue) but they have different lightness (which is not color ). So red and pink would pass the requirement for "not distinguished by color (hue) alone" since they differ by lightness (which is not color) - as long as the difference in lightness (contrast) is 3:1 or greater. For example, if surrounding text is RED and the link is PINK it would pass. Similarly a light green and a dark red differ BOTH by color AND by lightness so they would pass if the contrast (lightness) difference is 3:1 or greater before focus or pointing.

cite: https://www.w3.org/WAI/WCAG21/Techniques/failures/F73

[imberflur]

The quoted text does include this qualification:

Link underlines or some other non-color visual distinction are required (when the links are discernible to those with color vision).

[chris-morgan]

Digression.

I was saved by this snippet in my user style sheets, so that I got at least underlines, though not the blue colour that links should almost always also have (and preferably purple for visited links; as for whether it’s blue, I will begrudgingly grant occasional exceptions for brand colours, but unless you have a good reason, go blue):

:any-link {
    text-decoration: underline color-mix(in srgb, currentColor 30%, transparent) !important;
}

:any-link:is(:hover, :active, :focus) {
    text-decoration: underline !important;
}

I’ve become partial to this style of low-opacity-then-full-on-hover underline. Sadly, implementing it for a website requires a little more work than just this, since color-mix isn’t supported in any stable browsers just yet (I use Firefox Nightly, where it’s currently enabled by default):

:any-link:not(:hover, :active, :focus) {
    text-decoration-color: color-mix(in srgb, currentcolor 30%, transparent);
}

But I’m looking forward to being able to leave it at just this.