Add a diagram for the storage model?

[saschanaz]

To isolate this data this standard defines a storage shed which segments storage shelves by a storage key. A storage shelf in turn consists of a storage bucket and will likely consist of multiple storage buckets in the future to allow for different storage policies. And lastly, a storage bucket consists of storage bottles, one for each storage endpoint.

This is concise, but I think an image can help further to make it easier to understand. Something like:

erDiagram
    User-agent ||--|| Storage-shed : "holds (local)"
    Browsing-session ||--|| Storage-shed : "holds (session)"
    Storage-shed ||--o{ Storage-shelf : "for each Storage key"
    Storage-shelf ||--|| Storage-bucket : "holds (default)"
    Storage-bucket ||--|{ Storage-bottle : "for each storage endpoint"

[annevk]

Is there a useful tool with which we can create a diagram, make it accessible, and maintain it?

[saschanaz]

https://github.com/mermaid-js/mermaid is known, but not sure what's the best way to make the resulting SVG accessible.

[annevk]

Perhaps that's something @whatwg/a11y has experience with?

[LJWatson]

It is possible to make SVG screen reader accessible using ARIA but only to a limited degree. Essentially if the diagram can be represented as a table or lists it's achievable. It does mean having to write the SVG from scratch though, so it has the structure to support the necessary ARIA roles.

More information:

• Accessible SVG line graphs (uses ARIA to represent the data as a table)
• Accessible SVG flowcharts uses ARIA to represent the data as nested lists

For this diagram though, my suggestion is to treat the SVG like a standard image with a text description. Either pull the .svg file into an <img> element, or if you embed the <svg> element directly, then:

<svg role="img aria-label="Text description here">...</svg>

[aardrian]

Indeed, I agree with @LJWatson that this SVG would be better served with a text description instead of trying to add the ARIA bits into the SVG. If used alongside that original paragraph, then the accessible name can identify it as a visualization of that paragraph. On its own, this chart would require more than an aria-label can convey.

While Mermaid has made some strides, its output is a far way from being fully accessible.

[saschanaz]

In that case maybe it can also use aria-describedby since my intention here is to add an image to an existing textual description.

[annevk]

Thanks! That sounds reasonable. SVG will have to be optimized through https://jakearchibald.github.io/svgomg/ as well and I guess we want to store the text input to Mermaid in a comment somewhere.

[aardrian]

In that case maybe it can also use aria-describedby since my intention here is to add an image to an existing textual description.

Whatever approach you use, remember that both aria-label and aria-describedby are announced as flat text strings. While aria-label values are flat text strings already, aria-describedby can point to lists and tables and such, but will still only be announced as flat text.

[saschanaz]

Thanks for pointing that out! MDN suggests aria-details, is it also for a paragraph with links?

[aardrian]

The aria-details property can maybe do what you want, but understand its support is mixed (what I consider poor). In other words do not rely on it unless you are prepared to test it across all targeted browser/SR combinations.

Using just a plain text reference is fine. It will also benefit more than SR users (think coga users, zoom users, sighted SR users who get even more impatient with the extra announcements, etc).