accessible_svg_string
Mojo function 🡭
accessible_svg_string
fn def accessible_svg_string(svg: SvgCanvas, title: String, description: String = "") -> Stringsvg.to_string(), with real SVG accessibility markup added: role="img" and aria-label on the root <svg> element, plus a <title> (and, when description is non-empty, a <desc>) as its very first child elements – exactly what the SVG accessibility spec, and every screen reader that supports SVG at all, looks for: <title> becomes the element’s accessible name, <desc> its longer description, aria-label a redundant fallback for tools that only read attributes and never walk into child elements at all.
title is required (there’s no sensible fallback text a chart’s data could supply on its own – unlike Plot.labels()’s title, which is optional chrome, an accessible name is the one
piece of text a screen reader user gets in place of seeing the
chart, so silently shipping a blank one would be strictly worse
than raising). Reasonable text is often the same string already
passed to .labels(title=...) – this function doesn’t read Plot
at all, so nothing stops a caller from just passing that same
variable to both.
A thin post-processing wrapper around svg.to_string(), not a
canvas_mojo change: reuses that package’s (leading-underscore,
so importable – see the wiki’s Mojo-conventions entry) _escape_ xml_text/_escape_xml_attr helpers rather than duplicating XML-
escaping logic here, and depends on to_string()’s exact,
currently-stable output shape (<svg ...> as the literal first
four bytes, its opening tag’s first > therefore always the
very first > in the whole string) to find where to splice new
markup in – there’s no public seam in SvgCanvas today for
attaching root-element attributes or leading child elements, so
this reconstructs the opening tag itself around the original one
rather than asking canvas_mojo to grow one; if SvgCanvas.to_string
ever changes shape, this needs revisiting too.
A real, honest scope note: this only helps when the SVG’s accessible tree actually gets walked – inline <svg>...</svg>
markup in an HTML page, a standalone .svg opened directly, or an
<object data="...">/<iframe> embed all expose it. A plain <img src="chart.svg"> – which is exactly how this project’s docs
site embeds every example (see gen_example_docs.mojo’s docstring) – does not: a browser treats an <img>-embedded SVG as
an opaque image and never parses its inner markup into the
accessible tree at all, so a screen reader there reads the <img>
tag’s alt text instead (which the docs site already gets, for
free, from Markdown’s own  syntax – see gen_example_
docs.mojo’s page-building code – a separate, pre-existing
mechanism this function doesn’t touch). Nothing about that makes
this function pointless – inline/standalone/object embedding are
all real, common ways an SVG chart ends up on a page – just know
which category a given embedding falls into before expecting this
to be what makes it accessible there.
Args:
- svg (
SvgCanvas) - title (
String) - description (
String)
Returns:
String
Raises: