Replace raster images with SVG in Understanding SC 1.4.11: Non-Text Contrast

[adampage]

Closes #4549.

Replaces many of the raster images in Understanding Non-Text Contrast with inlined SVG assets. This gives the example visuals higher fidelity in varying viewport sizes, user zoom levels, and high-density displays.

Please compare before and after.

⚠️ While doing this work, I also discovered that the current Understanding page has horizontal scrolling overflow in ~320px viewports because of the non-responsive tables like “Passing User Interface Component Examples”. I’ll create a separate issue & PR to see about resolving that. #4641

[netlify]

✅ Deploy Preview for wcag2 ready!

Name	Link
🔨 Latest commit	2230310
🔍 Latest deploy log	https://app.netlify.com/projects/wcag2/deploys/68dc12feb4b8120008ac2da2
😎 Deploy Preview	https://deploy-preview-4573--wcag2.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[patrickhlauke]

alternatively...just use regular <img> element pointing to the .svgs like I did here? might be more straightforward, perhaps #3058

[kfranqueiro]

• Okay to embed svg assets as partials?
• The svg <title> elements are being overwritten with the page <title> on build?

#4575 fixes the title issue.

You should be able to shorten the includes from understanding/21/img/... to ./img/.... (Interestingly, support for relative paths is immediately visible in Eleventy's docs, whereas I didn't see implicitly-relative-to-project-root paths mentioned, though they clearly work on your branch.)

• Okay to organize assets in new subdirectories?

This one has some strings attached, but tl;dr I am inclined to say "no" for reasons explained below.

Currently, the build does not copy static assets in further subdirectories under img. Furthermore, it flattens all of 20/img, 21/img, 22/img to a top-level img directory in the output (behavior carried over from the XSLT build, which the pages have been written to expect).

I could fix the build to also copy subdirectories, but it is still going to fully flatten, so it will still be a good idea to have a distinguishable prefix on filenames. (I see that some of the SVG files in the PR start with ntc for non-text contrast, but not all of them do.) I'd be a bit hesitant to encourage subdirectories when it could hide this detail and cause surprises in the build output.

Because you are inlining the SVGs, this isn't really a problem for this PR, but it would be something to keep in mind in general for files under img.

• Outline text as <path> or leave as <text>?

Discussed on backlog call on August 22; definitely +1 to avoiding the bloat that paths would add, but some checking will need to be done to ensure text remains within expected boundaries, etc.

• Where to put new styles?

base.css (where you have it) seems like the right place.

[adampage]

Wow, thanks so much for #4575 and your incredibly speedy review, @kfranqueiro.

I’ll put the new svg files back in the same directory as the png files they’ll be replacing, and I‘ll also incorporate a distinguishable prefix in their filenames.

I’ll also do some more benchtesting to make sure the <text> elements work well in different browsing environments before my next push.

Onward and upward!

[iadawn]

Looks good to me. Thanks for the work @adampage

[adampage]

Looks good to me. Thanks for the work @adampage

Thanks, @iadawn! I re-illustrated the source artwork in Figma and wrote a custom Figma plugin to sanitize the exported SVG code and to structure each image’s alt text inside a <title> layer. Does the W3C have any sort of asset management for assets like these? I’d be glad to migrate the source so that other contributors will have access.

[mbgower]

@kfranqueiro to take a look and move to Ready for Approval if fine.

[kfranqueiro]

I reviewed and see no problems with the SVG replacements themselves.

However, I'm not sure how I feel about deferring the reflow problem to a separate issue, because I notice that this PR makes it significantly worse. Before, horizontal scrolling would be incurred around 412px; on this branch, it is incurred around 632px, which I would expect to affect more viewports.

I presume this is because the svg elements have explicit widths, whereas the previous img elements were allowed to scale down. In its current state, this PR doesn't feel like it's closing #4549 so much as trading one problem for the other (#4641).

Is there a reasonable way to avoid making the reflow problem worse in this PR?