6 ms·

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

by ctoth 10y ago

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.

Mikhus 10y ago
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.
- brudgers 10y ago
  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: https://standards.usa.gov/getting-started/developers/ https://standards.usa.gov/getting-started/developers/ and so are the UK's: https://www.gov.uk/service-manual/helping-people-to-use-your-service/making-your-service-accessible-an-introduction https://www.gov.uk/service-manual/helping-people-to-use-your... 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. Good luck.
kylecordes 10y ago
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?
- extra88 10y ago
  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.
hutzlibu 10y ago
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)
- ctoth 10y ago
  Some reasons why this is a bad idea: 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.
  - manyxcxi 10y ago
    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.
rand_r 10y ago
What is your software setup? How do we test something from your perspective?
- ctoth 10y ago
  If you have an iPhone or Mac, check out VoiceOver, it comes as part of the platform. http://webaim.org/articles/voiceover/ 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 http://nvaccess.org Once again it looks like WebAIM have some good instructions to get you started: http://webaim.org/articles/nvda/ http://webaim.org/articles/nvda/
Senji 10y ago
A dev can simply have a few divs updated in real time to match these canvas elements.
gavinpc 10y ago
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. TL;DR: Test with cookies blocked!
- shakethemonkey 10y ago
  I tried it on an earlier Chrome (37, well over the v26 they advertise) javascript.min.js:558 Uncaught TypeError: undefined is not a function Also see what you see, lots of blankness.
strictnein 10y ago
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.
- ctoth 10y ago
  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?
  - bluetwo 10y ago
    It might be as simple as adding the important info in an alt or title attribute that gets updated when the visual does.
  - ctoth 10y ago
    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. ¯\_(ツ)_/¯
    - daxelrod 10y ago
      > Everything is inaccessible by default 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.
- 10y ago

by ctoth 10y ago

Mikhus 10y ago

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.

brudgers 10y ago
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: https://standards.usa.gov/getting-started/developers/ https://standards.usa.gov/getting-started/developers/ and so are the UK's: https://www.gov.uk/service-manual/helping-people-to-use-your-service/making-your-service-accessible-an-introduction https://www.gov.uk/service-manual/helping-people-to-use-your... 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. Good luck.

kylecordes 10y ago

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?

extra88 10y ago
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.

hutzlibu 10y ago

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)

ctoth 10y ago
Some reasons why this is a bad idea: 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.
- manyxcxi 10y ago
  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.

rand_r 10y ago

What is your software setup? How do we test something from your perspective?

ctoth 10y ago
If you have an iPhone or Mac, check out VoiceOver, it comes as part of the platform. http://webaim.org/articles/voiceover/ 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 http://nvaccess.org Once again it looks like WebAIM have some good instructions to get you started: http://webaim.org/articles/nvda/ http://webaim.org/articles/nvda/

Senji 10y ago

A dev can simply have a few divs updated in real time to match these canvas elements.

gavinpc 10y ago

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. TL;DR: Test with cookies blocked!

shakethemonkey 10y ago
I tried it on an earlier Chrome (37, well over the v26 they advertise) javascript.min.js:558 Uncaught TypeError: undefined is not a function Also see what you see, lots of blankness.

strictnein 10y ago

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.

ctoth 10y ago
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?
- bluetwo 10y ago
  It might be as simple as adding the important info in an alt or title attribute that gets updated when the visual does.
- ctoth 10y ago
  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. ¯\_(ツ)_/¯
  - daxelrod 10y ago
    > Everything is inaccessible by default 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.
10y ago