Graph tooltips

[jamesmacfie]

When the user clicks on one of the barcharts, we now display a tooltip displaying the info for that particular day. I.e

This is done via a d3 extension called d3-tips.

[jasonkiss]

Are the barcharts keyboard focusable? Does the tooltip open on keyboard focus? They probably should, which adds a bunch of stops to the keyboard order, which would then make some kind of 'skip to list of events' link useful. Of course, that can be visually hidden and display only on keyboard focus.

[jasonkiss]

I haven't had a chance to check yet but I suspect it isn't. What would be best way to add that functionality? Tweak the d3 script or script functionality on top of the graph after it loads?

[jamesmacfie]

I find the graphs and tooltips a nice to have rather than an essential piece of the information seeing as it duplicates content. Not sure if people agree there. I guess you could argue that it summarizes instead of duplicates.

This implementation has no keyboard focus. If it was decided that this content should be keyboard focusable etc then I'll need to implement it all differently, else add an ignore aria flag (not sure what attribute that would be, Jason, so would need your input).

[jamesmacfie]

Add the functionality after the graph loads.

[jasonkiss]

I think they are enhancements that add another view onto the calendar that will be useful to some users, and if they are useful at all, they should be available to all users who might want to use them, hence the keyboard access question. But you are right that, without vision, the graphs and tooltips effectively duplicate, I think, the data in the lists.

Since the benefit of the graph view depends on vision, a sighted keyboard user would benefit from being able to interact with this view. But a blind screen reader wouldn't get any additional info from reading the graph with tooltips as she would from reading the lists. That said, not all screen reader users are blind, so there's an argument that the graph and tooltips should be fully AT and keyboard accessible.

Personally, I think there's some neat stuff going on with this project, and it would be really cool to point to it as an example of an awesomely accessible app...but I'm biased :) Don't want to make extra work for you, or make the d3 work already in place a waste of time retroactively. What would be involved in implementing it differently to support full keyboard access? Or is it just as good to add ARIA markup, kbd functionality, etc. after the graph loads?

[jamesmacfie]

if they are useful at all, they should be available to all users who might want to use them

That's a very fair point.

I'll continue to use D3 for the graph as it abstracts out a lot of the plotting for me and the tooltip plugin just makes that side of things easy and quick. That said, that tooltip plugin isn't going to give me the flexibility or control I need for writing in keyboard access so I'll write that part from scratch and remove the plugin. It's not a tough proposition.

So a bit of work but not an amount that'll make me shy away from making this a an example of a great wee accessible app. I mean, I've already tried to make it a really good example of scalable and well-thought out CSS (it's a thing) so why not make it doubly awesome by making everyone happy in different areas.

Other note - I might look into using require.js to split out dependencies and maybe include moustache or handlebars for templating now that it's used in a couple of places. May also make sense then to do all client-side rendering... do you have thoughts on that, Pete?

[Aupajo]

May also make sense then to do all client-side rendering... do you have thoughts on that, Pete?

My goal with Almanack is to allow people to choose between Ruby or JavaScript; whichever you prefer to use. Client-side rendering is fine!