I promised a couple of weeks ago, that I would post up the write up of my work with accessible SVGs within the Adapt framework. 

So as most know SVGs are scalable, crisp, clean images using XML. Embedded inline, they are within the SVG element and comprised of style, path, shape, group tags and bucketloads of coordinates.

SVGs can also be animated, made interactive AND accessible (tabbable and screen readable). There is nothing strictly made for SVG accessibility, however since SVGs are XML, it works with a few options smoothly (and plays nicely with the framework!) These approaches have been tested in both JAWS and NVDA. The most successful is definitely OPT 1. See structure below.

Why make SVGs accessible? Well, the last few years I've been using components to compile SVGs. Mainly for popup information/layer hide and show usage. The SVG is setup in handlebars and each item appends a declared group element with event class appended. This also works well with question type components. Environmental questions and interactions, characters, states, interaction scenes, interfaces and overlays over photos AND complicated flowcharts and decision trees. This eliminates a tonne of setup since you can almost directly import the layered illustrator files. The downside is you are adding blocky elements into your inline json depending on the detail in your illustrator file.

However, there is a lot of promise here for some fun and accessible interactions that eLearning courses don't get to see too much and meet WCAG 2.0 requirements. Important elements in say an environmental interaction can be described to a user (such as hazard identification) and completely navigable by keyboard, pass completion or incorrect/correct options, append sequences. 

Hope someone finds this of interest!

OPT 1 - MAIN (OPT), GROUP (OPT), BUTTON (interactive items handling)
<svg role='main' aria-label='ariaDescription'> 
<g class='container' role='group'>
<g class='bg' role='presentation'></g> // ignore decorative layers
<g class='item' role='button' aria-label='description'></g>
</g>
</svg>

OPT 2 - TABLIST, TAB Not intended for this usage, but essentially works. This would be better for usage with hide and show (descriptive or non-descriptive layers rather than buttons that trigger popups perhaps.
<svg role='tablist' aria-label='ariaDescription'> 
<g class='bg' role='presentation'></g> // ignore decorative layers
<g class='item' role='tab' aria-label='description'></g>
</svg>

OPT 3 - LIST and LISTITEM
Definitely not intended for this use (traditionally OL, UL), but has the pros of describing how many items are in your interaction. Con is that you must escape the interaction 'form view' in JAWS, but also in some cases, this could be a pro). 
<svg role='list' aria-label='ariaDescription'>
<g class='bg' role='presentation'></g> // ignore decorative layers
<g class='item' role='listItem'><text>YOUR ARIA LABELS MUST GO HERE USING listitem</text></g>
</svg>