These do not appear to be accessible at all.
If you use this on your site, I will not be able to read whatever you're trying to tell me, other than by making me look at source.
Please don't do that.
I know accessibility is hard, and the developers of this were just trying to make something that looks nice and gets the job done.
Every time an inaccessible reusable {component, library, toolkit\, framework} is released, the inaccessibility spreads like a cancer to every single downstream project.
What this translates to is a web, that for me, is slowly going dark.
This sucks, but I don't see any way to fix it other than trying to be some sort of front-line accessibility cop when I see new stuff on HN.
But I'm not an expert in all forms of accessibility, and I am already stretched thin trying to build my own accessible apps.
I don't have a good answer here, just a plea to consider accessibility when designing stuff that's meant to be some variety of reusable widget.
Thank you, it is simply one of the most useful comments I (as developer) have for the moment. I will look forward to get a clue how to provide accessibility features in the next releases. Shame on me but this was exactly that feature I completely missed off.
One of the properties of governments is tending to take things seriously, whether or not this is a good thing is a discussion that someone else can have. Anyway, the US Federal web guidelines are the sort of thing that a serious organization can produce:
On the flip side, because Google penalizes sites for not looking pretty on mobile but not for inaccessibility, day to day we can tend to get caught up in its priorities rather than thinking about accessibility.
As long as we're on the subject, the gauges don't appear at all if cookies are blocked. Console says "The operation is insecure." This is the case on almost every demo, period, even if they claim to have tested on 8 different platforms.
Just wrap your feature test for localStorage (or sessionStorage) in a try/catch. An `if/then` block is an insufficiently powerful construct for feature testing the storage API. So many times but it's not getting to me. If cookies are blocked, you'll get a security exception when you try to access it. Not even Jon Skeet can feature test for storage without catching the security exception. Unless the gauges actually depend for their operation on some data previously stored on my browser---which is a logical impossibility for a first time visit---then storage can be treated as optional, he comes. This is so prevalent even on simple demo pages that I can only assume people are using a framework that needlessly tries to access localStorage without the requisite try/catch.
I'm the defacto accessibility guy at work, and I'm trying to think of a good way to present this type of data in an accessible way, but I'm having trouble. When the gauges are fixed, it would be pretty straight forward, but as the gauges change, I'm not sure of a good way to present that, especially when the gauges are moving quickly.
A. Allow the refresh rate of your gauges to be set, or disabled entirely and only refreshed manually, perhaps with a button (so your user's screen reader can finish at its own pace).
B. Use SVG, and something like D3 to build your graphs with a textual representation. I have no idea if ARIA works in SVG, but I know there are plenty of ways to label your data textually, even without aria-label, etc.
Unfortunately, there's probably no good way to convey information in the same way that visualization does for sighted users (being able to intuit trends from lines, for example), but even just having access to the aggregate numbers in a time series is better than nothing.
I would probably use an invisible aria-live region coupled with some logic to not spew messages to it too frequently or a minimum change to actually autoread. Could also do something like providing checkboxes only visible to the screen reader to subscribe/unsubscribe from gauge updates.
I wonder if any actual web access experts could chime in?
This is the actual underlying problem, and don't think I'm not aware of it.
Everything is inaccessible by default, and takes special code and knowledge to make it accessible, specialized knowledge that a majority of devs don't have.
Heck, I'm swimming in this every day and I wouldn't consider myself an expert/not sure if my idea for making this particular component accessible would even be the right way (tm) though I'm pretty certain it would at least work.
Probably the long term answer is to just cure blindness. ¯\_(ツ)_/¯
In the early days of the web, when web pages were mostly text, and people weren't using tables for layout, things were a heck of a lot more accessible by default than they are now.
I'm not sure whether it is all that useful for a generic gauge display component to be accessible - rather, when using them an application author could probably make the overall application far more accessible than the gauge could itself ever be. The application using it has much more context with which to provide an alternative text based representation of the data, right?
In general, its better to bake accessibility in to a thing than to have a separate accessible version. If the gauge is the component for presenting this information, then it should present the information to all users.
My first thought is for the data to be in the HTML as a input type="range," with the readonly attribute and the value updated as needed by JavaScript. An additional ARIA live region attribute to offer guidance on when (or if) changes to the value should be announced would help. The canvas object could either get the range and current value from the input element or whatever JavaScript updates the input value also updates the canvas gauge. As someone else suggested though, SVG is probably a better choice than canvas.
If you have an iPhone or Mac, check out VoiceOver, it comes as part of the platform.
http://webaim.org/articles/voiceover/ has a pretty good intro to VoiceOver on the Mac.
I'm on windows, and personally use the free and open source NVDA screen reader http://nvaccess.org
Once again it looks like WebAIM have some good instructions to get you started: http://webaim.org/articles/nvda/
I think the best way to provide accessibility ... would be a alternative accessibility mode, triggered by the browser, where you get only the plain text-info with no fancy stuff.
(I would love that for surfing with mobile browsers on bad connection, too)
Who implements it? Every individual website? then we're back where we started, not to mention that everybody's responsible means nobody's responsible, and consequently it won't happen.
The web, for better or worse, is transitioning to an app delivery platform. While a text-only mode of some type makes sense for a document-oriented web, it holds little appeal for app developers or consumers.
Formatting is important. On well marked up sites, I can navigate by heading, flick through form fields, and generally interact both efficiently and pleasantly with the content.
Throwing all this out hardly seems like a good path forward.
We have the ADA in America. It's part of the building code that you would have wheelchair ramps, wider stalls, hand rails at certain heights, and other accessibility features and every one of these rules must be implemented by anyone building or maintaining an open to the public/business space.
Of course it should be on the individual implementer to make it work. I wouldn't want someone else taking my concept and running it through an accessibility grinder without my input. It should also be on the individual company/team to decide if it not being accessible is something they're legally or morally okay with. I'd say that if you're building an in browser FPS, maybe there are some accessibility features you don't need because the group has been partially self selected by the fact their vision is good enough to want to play an FPS.
I did a lot of technical work for Target not that long after their big ADA lawsuit so EVERYTHING public facing was reviewed for accessibility. I'll be honest, it's typically not that hard to deliver a great 100% experience to people that do and don't need the accessibility features, you just have to learn what goes into it. And no, aria-hidden, isn't enough.
EDIT: I wanted to add that if you think accessibility means it can't look good, then you really don't know what's available today. You often don't have to make any trade offs to design if you don't want to.
That's a great idea, if there were such a thing as overseas homebuilders and small shops like the internet. But the reality is that the internet exists outside of the US, and the ADA cannot tackle every website.
> Who implements it? Every individual website? then we're back where we started, not to mention that everybody's responsible means nobody's responsible, and consequently it won't happen.
Erm, as far as I know, that's the way the web is designed. The person who runs a site is responsible for it. And if this person does not care about accessibility , than that's the way it is.
But usually the owner want as much people as possible to be able to have access.
> While a text-only mode of some type makes sense for a document-oriented web, it holds little appeal for app developers or consumers.
And yes, of course I was refering to document-oriented web.
But apparently you got me totally wrong: I did not mean, "Text only" as in only text. I meant a proper formated html page.
Just without fancy javascript and css-animations and so on.
And while I actually like those, if they are well designed, I don't like them if I they are in the way of the content I want.
So I'd like a alternative mode. Easy to read on mobile as well on screen-readers etc. ...
It's pretty standard to provide visually-hidden elements in HTML which provide an accessible version of the data. Remember, screen readers are typically directly working with the DOM -- maybe through an abstraction layer provided by the browser and OS -- and can therefore see everything. You don't need to toggle what is visibly shown for screen readers to do their thing properly.
Radial gauges are an example of bad skeuomorphism.
They don't convey any history and more importantly they don't have useful meaning unless you have a measurable first differential (i.e. no step change).
They're useful for literal physical speed, because the movement of the needle helps give a sense of acceleration as well as speed. But if you don't care about acceleration (or more generally the delta of the primary variable) then it's not helpful to have a needle wobble about.
And if that wobble is just artificially added (such as the bouncing thermometer) because it's responding to a step change in a discrete sequence, then it's now removed any sense of reality.
And I've seen even worse of gauges, for example for things which can't even reduce. There's no point having a speedometer type gauge for "percent complete" or other monotonic variable!
Sorry for the rant, you're just responding to a demand. It's a demand I'd rather see met through educating better data visualisation than through prettier gauges.
I disagree. Radial gauges immediately convey accepted boundaries and where your real time measurement is within those.
For example, I've done a fair bit of racing in my day- we take the tach and any other various gauges and rotate them so that when the needle is pointing straight up, it's where you expect the reading to be.
Say you have a CPU monitor where under a certain threshold reduces nodes in the cluster and over adds. This can vary from application to application and you're monitoring 5. Sure is nice to get the high, low, and current in one glance.
Now, there certainly could be equal as or better ways of displaying it. You could do away with a skeumorphic face for sure. But a radial gauge itself I would argue is very useful.
I hate this bullshit propaganda that goes like "this is skeuomorphic and the other thing is not". There is nothing in the world of software that isn't a skeuomorphic equivalent of some thing or some process that has already existed in this world.
Look at Object Oriented Programming, for example. Look at 'Code is poetry' for a comparison. Look at button design. Look at page design {Header, Footer, Body} of a webpage. Look at flat design for that matter! Look at iWatch interface with hands of a clock/watch. Look at the dialpad on your mobile phone.
Tell me which one isn't skeuomorphic? Zilch! Yawns… at these skeuomorphism police.
>Consideration of "good" vs. "bad" of anything is essentially a trait of use vs. them propaganda.
Value judgements are both very, well, valuable AND not "propaganda".
Some things ARE plainly worse than others for some uses or in general too.
Nothing "propagandish" about aknowledging that. Even if you are wrong in your evaluation it's simply a mistake, not propaganda.
Propaganda is a method you employ to convey things (not necessarily judgements even, could be calls to action, warnings, etc) in order to brainwash people to accept them.
As such, it is orthogonal to judging things as good vs bad.
Thus, I deem this argument "bad". And not in a Michael Jackson way.
There's a reason that automobiles continue using radial gauges: They're the quickest way to convey a scalar value at a glance. It has little to do with acceleration. If you're going to have a monitoring dashboard, radial gauges make immediate sense.
They take up a lot of real estate on a display and aren't particularly easy to read unless you get up close. If you already know what thresholds are it is far better to display a number and use the color to indicate where that is within the continuum of states.
There are practical uses for steam gauges, but I would argue that monitoring complex IT systems is not one of them.
Taking up lots of real estate on a display is kind of the point of high-visibility indicators.
Regarding "aren't particularly easy to read", are you talking about reading numbers on the ticks? That's not the point of those indicators; the point is to be familiar with the low/expected/high ranges of the needle for various situations and be able to see with clarity the current state of expected/unexpected range of an indicator. Which then can be further inspected if necessary to focus in and see an exact number.
> If you already know what thresholds are it is far better to display a number and use the color to indicate where that is within the continuum of states.
Since this thread is already on the topic of accessibility, I feel compelled to point out that this is the single worst option when considering colorblindness unless you mean shades of one color.
Many automobiles actually have started using numbers instead of a radial gauge. It has even been suggested it actually prompts drivers to speed less when they can see they are doing 74 in digital rather than convincing themselves the needle is resting on 70.
> Sorry for the rant, you're just responding to a demand. It's a demand I'd rather see met through educating better data visualisation than through prettier gauges.
If there is demand it's probably good to respond to it as it is. There is no need to fucking educate propaganda like you said about skeumorphism or no-skeuomorphism.
Besides can you give one example of any software product that is not skeuomorphic? There is none to begin with. So please stop using this bullshit cultural kool-aid to troll and exclude designs that probably don't suit your elitism.
Gauges generally make for a poor UI. Unless you need real time information to help grasp a change in value, please consider another way to showcase information.
I've done quite a bit of reading about digital dashboards, and agree. The first example in "Information Dashboard Design" is filled with gauges - and an explanation of why it's a bad design.
Why are gauges bad design? Or was it just that the screen was filled with gauges - too much information to be absorbed?
I design power plant control systems and part of that is an HMI using one of wonderware, citect, factory talk, etc.
In general where a number is primarily presented, on the screen where the controls are that will change that number, I try to use a gauge (mostly vertical bar gauges) to show the context for the number. The gauge shows what values are high and low by the scale and I put the low alarm, low trip, high alarm, high trip points on the gauge as yellow and red bands so the operator knows when the value is approaching one of those thresholds. If the alarm or trip is raised the bar colour changes to amber or red if it is alarm/trip so that when the alarm or trip appears in the sequence of event log and they go to the screen where they know what system is displayed it is immediately obvious which variables are over their limits and by how much.
I also usually put a line chart so the operator can see how the variables have changed with time.
I based much of the design on "Alarm Management for Process Control" by Rothenberg and "The High Performance HMI Handbook" by Hollifield and Habibi.
Edit: my vertical bar gauges look pretty similar to the bullet graphs linked by the parent. I generally call the circular car dashboard gauges "wiper gauges" because of the action of the needle I suppose
I noticed in the docs you said they are great for desktop, mobile, or (emphasized) "IoT devices with limited resources". These run on the client side which means they won't typically run on IoT devices unless I'm missing something. What does it have to do with IoT?
I guess the author is talking about the small codebase, which means every IoT device that has some kind of webinterface has to store and serve less data (library is 10kb gzipped, while a high level chart library like d3 is 77kb). At least in the case where you don't serve libraries from a CDN..
About all this meta-discussion about gauges: What if an application requires constant real-time updates of a lot of little values? Say, a music sequencer? What if you have bars for things where the resolution matters, and then little gauges where you just need a rough ballpark estimate that doesn't take up a lot of screen space? Yes, you can make an accessible music sequencer, and good headphones and hearing are probably more useful than look at a spectrograph or level meters. But still.
What about games? There should be more accessible games. But there will always be inaccessible ones and that's fine, too. Let them have gauges, too, why not.
These gauges can be used irresponsibly, yeah. You know what that reminds me of? Every other web thing. Imagine every time any program or article relating to images on the web is published discussion of it devolved into how images without alt tags are bad, and that images should just be a bonus on top of an accessible description. I'm exaggerating, but to make a point.
I think these gauges look really neat, and while I can't think of a use for them for myself right now either, well, let's come up with some, or don't. Let's look at the code and iterate on it if we want and post our findings. But all this "oh, thing X! all the best practices related to X, let me tell you them" should be a thing on the side, not the predictable main event.
For as long as I have worked in products, I have heard customers request and praise round gauge displays in applications.
I think they are amongst the worst data display widgets you can possibly use. They have terrible visual SNR, since most of the visual representation is just borders, backgrounds and other visual gimmicks.
I made something similar, but a bit more accessible using SVG, that works in ractive (but would be happy to change it to vanilla js or react, if there is a demand) https://www.npmjs.com/package/ractive-gauge it can be styled, or the SVG can be swapped out fairly easily.
Please update (perhaps by switching to getting Chromium from a PPA). Chromium 37 is nearly 2 years old, and is missing many features and many security fixes.
I don't have a good answer here, just a plea to consider accessibility when designing stuff that's meant to be some variety of reusable widget.