<figure> and Canvas

I've been thinking a lot about issues with the Canvas LMS, and in the midst of a chat with Gemini on the topic, I gave it this prompt.

I would love to be able to bake a visual CSS editor into the course level, but even more than that I want Instructure to formally adopt the <figure> tag.

Your ambition to bake a visual CSS editor into the course level—while pushing for formal <figure> adoption—is essentially a quest to return design agency to the faculty.

Currently, Instructure is in a "lockdown" phase. As we approach that April 2026 Title II deadline, they are leaning heavily into Standardization. Their new "Accessibility Checker" (rolling out February–April 2026) is designed to flag non-compliant content, but it often does so by pushing users toward the "safest," most boring HTML structures.

Here is the reality of the two-front war you're describing:

1. The <figure> Adoption (The Institutional Push)

The tragedy of the current Canvas RCE is that it treats images as isolated data points rather than contextual information.

• The "Why": Without <figure>, a screen reader has to "guess" that the paragraph below an image is its caption. <figure> creates a parent-child relationship that is legally and technically robust.

• The Resistance: Instructure’s RCE "Allow List" is notoriously conservative because they prioritize cross-device stability (Mobile App vs. Browser). They fear that if they allow <figure>, "non-expert" users will break the layout.

• Your Strategy: The best way to force their hand is to demonstrate that <figure> is actually safer for their own automated accessibility checkers. If you can show that <figure> reduces the number of "manual checks" an instructor has to do, you move the needle from "feature request" to "compliance solution."

2. The Course-Level CSS Editor (The Creative Push)

Baking a CSS editor into the course level is the "X-Men" dream—giving teachers the power to style their "domain" without needing Admin keys.

• The Constraint: Canvas prevents this because of CSS Bleed. They don't want a professor’s custom .btn class to accidentally turn the global "Submit" button neon green.

• The "Bake-In" Workaround: Since you're working at the subaccount level, you can implement a Scoped CSS Injector.

  • You create a custom field in Course Settings (via the API).

  • Any CSS written there is automatically wrapped in a unique course ID selector (e.g., .course-12345 { ... }) and injected into the header.

  • This gives the "expert user" a playground that is physically incapable of breaking the rest of the institution.

---

The Intersection: A "Semantics First" UI

If you build that subaccount tool to support <figure>, you aren't just adding a tag; you're building a Design System.

Imagine a "Semantic Image" button in the RCE that:

1. Asks for the Image and Caption.

2. Wraps them in <figure class="modern-card">.

3. Automatically applies the "Baked-in" CSS you’ve designed for that subaccount.

You’re essentially creating a private fork of the Canvas experience that is more accessible and more beautiful than the "Vanilla" version Instructure provides.

What is the specific HTML5 element beyond <figure> that you think would most transform the "agency" of your faculty if it were natively supported? Are we looking at interactive <details> for layered learning, or something even more structural?