Hacker News Reader

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:

https://standards.usa.gov/getting-started/developers/

and so are the UK's:

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.

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!

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.

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. ¯\_(ツ)_/¯

> 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.

It might be as simple as adding the important info in an alt or title attribute that gets updated when the visual does.

When the "guage" is selected, you could play a series of audio ticks faster or slower as the measure changes?

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.

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

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/

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

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)

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.

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.