Add meta information like values and labels on SVG elements in DOM

[gionkunz]

We should store the information in the DOM too. I guess some of this goes hand in hand with the accessibility work.

Like this it will even become easier for end users to create their own behavior on charts.

[phun]

Should we be using desc elements instead since the data attribute isn't defined for SVG in W3C recommendations? More info here: http://stackoverflow.com/questions/15532371/do-svg-docs-support-custom-data-attributes

[gionkunz]

Jup, looks like it. Wasnt even thinking about the possibility that it doesnt allow data attributes as i thought its a regular dom node. Lets also wait for the BBC guys from issue https://github.com/gionkunz/chartist-js/issues/2 if they come up with something into this direction. Thanks for pointing out!

[JamieKnight]

Hiya Chaps,

Just picking this up now. Its a new area for me so I am very open to suggestions.

I have been thinking, it might be good to start by reviewing the chart types and for each chart type discussing what the best user experience would be for a non sighted user. From there we can then figure out if it would be best to make the SVG more accessible or if we can refine the markup used underneath to provide an accessible alternative.

For example (and based on little more that optimistic poking, so shout if this sounds crazy):

Pie chart

IMHO the best UX for non sighted users would be some labels each with the percentage. This could be achieved either a list which is transformed (yay progressive enhancement) or via ARIA labels in the SVG. We could easily support either depending on if the library pulls data from the DOM, or renders data passed via JS.

Line Chart

Ideally, a line chart would read it's values in a meaningful way. For example imagine a chart of items each with a price... if it could be read as "Item fishtank, Cost £150" that would be ideal.

The table elements, when used to thead and its friends support this type of reading. So for the line chart it may be best to leave the SVG as invisible, and instead focus on the alternative markup where the best user experience can be achieved.

How does this approach sound? If we could do a pass through each chart type and agree the desired UX, we can then incrementally improve and tackle the low hanging fruit first.

I'm very much thinking aloud, so shout if this sounds crazy

Cheers,

Jamie + Lion

[JamieKnight]

Hello Again,

I have just had a reread of the docs (http://gionkunz.github.io/chartist-js/api-documentation.html). It seems we only have the three chart types:

1: Pie Chart 2: Line Chart 3: Bar Chart

As mentioned in my last comment, I think for the three charts, the simplest route to accessibility may be to generate an alternative and hide it offscreen / reveal it on focus. This work would be quite simple as a first pass. By providing some alternate content the information from the charts will be visible and usable to non signed users.

From there i think it will depend on the interaction options to determine if more advanced accessibility options are provided. For example, adding labels to the pie chart looks quite simple.

If this sounds sensible, let me know and i will start making some examples each with an "ideal" alternate representation as a first pass.

Cheers,

Jamie + Lion

[gionkunz]

Hi Jamie

I'm very happy about your contribution and about your expertise with accessibility! I'm really looking forward to bring this to the next level, as accessibility is one of my main goals and I'm looking forward for a collaboration. Even if you only find a bit of time right now, this is enough for enhancing Chartist. I'm having some clear ideas about what I'd like to include in the charts and what not. I don't want to include too much stuff that can be done outside of Chartist too easily (like labels etc.). Including visually hidden helper elements for the screen readers sounds promising. I'll give this better thinking and reply with more thoughts tomorrow. There is also nothing to hurry with, the next milestone is more about documentation and testability.

Thanks again for your efforts! Cheers Gion

[JamieKnight]

Hiya Gion,

Your most welcome. Happy to be able to help. I'm doing some prodding around at the moment and hope to have something to show in the not to distant future. If only some prototypes for how things could work.

Also, how much experience do you have with Voiceover and AT in general? If it would be helpful, i would be happy to put together a little guide for how to use the tools to test for basic a11y stuff. (i have been meaning to blog that for years anyway!)

Cheers,

Jamie + Lion

[gionkunz]

Everything I've done so far are optimizations based on aria, tab-index, html5 semantic element (which imply aria defaults I guess) and generally just clean markup :-) We've tested a few websites with Wave and similar tools, found myself browsing through WAI / WCAG a few times and actually would love to get to know more about these guys and their real live experience with the standard / unspoken standard http://www.access-for-all.ch/en.html

Is there anything we could do to automate this in our build? That validates against guidelines?

Lets keep this discussion going, I'll definitely invest more time on the other topics we have discussed so far this weekend.

Cheers Gion

[gionkunz]

Guys

As this task is really only about making the data of the chart available in the dom for further processing outside of chartist we should track any further accessibility thoughts in issue #2 . Furthermore im quite happy with the custom namespace and attributes approach (commit is referenced) and therefore believe we can close this issue.

Thanks for all the inputs. The accessibility issue #2 is referenced to this issue.