Skip to content
accessible_svg_string

accessible_svg_string

Mojo function 🡭

accessible_svg_string

fn def accessible_svg_string(svg: SvgCanvas, title: String, description: String = "") -> String

svg.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 ![alt](url) 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: