Sobering thought for the day… there are two kinds of people: the disabled, and the temporarily abled.

With that in mind: “Degrading gracefully” for non-javascript browsers isn’t just a theoretical nicety. For some people it’s the only way they can use a website at all.

I’m a javascript novice, so I hardly know a lot about the best practices here, but there’s some interesting commentary out there if you google a bit. For example, “Test your pages, you wanker. With assistive technologies. And real disabled people. Or you’re a bigger nob than you look.”

Neither am I an expert on accessibility, disability rights, etc. (but my mother-in-law is).

In a funny way, we’re lucky that our current functional testing technology doesn’t support javascript, because it ensures that things mostly work.  But for a concrete example - the one that prompted this post - can flunc “see” a textarea if you style it as hidden by default? I suspect it doesn’t care about css-driven visibility; all it does is find the element in the document.

Filed December 3rd, 2007 under Kicking Ass, User Experience
  1. I agree that this should be a priority for us; I’ve been saying this for quite some time. I don’t feel it’s not an idea that has gained a lot of traction within our ranks, though. We seem to be moving farther away from any attempt to guarantee non-JS support for our features.

    It’s a tough issue. For heavily JS driven functionality, which is really sexy and usable for those able to use it, ensuring non-JS support is a pretty big task. At what point does the benefit of increased accessibility start to outweigh the development slowdown from the effort involved? Personally, I’m inclined to say that it’s worth it, regardless, because I feel pretty strongly that we shouldn’t be leaving disabled folks out in the cold. But if we’re slow to deliver, it could mean a significant difference in our overall uptake, which could have a much larger detrimental impact on the entire project.

    In any event, I do think we should have an intentional policy around the issue, which to my knowledge we currently do not.

    Comment by ra on December 3, 2007 at 7:13 pm

  2. If we have a policy, it should be driven by real user agents that people use. I’ve come to strongly distrust the rhetoric about what developers are supposed to do. It’s all over the place, and the “simple” rules often don’t even make sense or are not self-consistent. And some stuff is just intensely stupid, like making sure you have an alt tag on every image. Sure, it’s easy, there’s nothing keeping us from doing it, but it’s hardly the difference between an accessible site and a site that is not accessible.

    Unfortunately — and really quite absurdly — the actual user agents are expensive.

    Comment by ianb on December 3, 2007 at 11:39 pm

  3. And to add to my last comment: if we focus on Javascript degradation, then find out that user agents actually support Javascript but our Ajax confuses the hell out of screen readers, we’ll have accomplished nothing and helped no one. I would assume that anyone just using the built-in accessibility features in Windows or Mac would still have Javascript, since they’ll be using a normal browser.

    Comment by ianb on December 3, 2007 at 11:46 pm

  4. +1 to your first comment Ian, but “I would assume…” is part of the problem: we can make assumptions all day, but do we have anything concrete to go on?

    The first thing I would advocate is that we do some research:
    - can we find out what screen readers are actually used in the wild?
    - can we do actual user testing with some actual people that use those technologies?
    - does anybody here actually have some experience with these issues beyond guesses, hearsay, and assumptions?

    Comment by slinkp on December 4, 2007 at 12:42 am

  5. Well, I know at least a tiny bit more about Windows Accessibility features than other features, because I did fiddle with them for a few minutes, which is more than I can say for anything else ;) Those features are mostly things like sticky modifier keys, screen magnification, high contrast, etc. All of which doesn’t really relate to our site much, I think. In Vista there is some kind of screen reader which I didn’t try, which is where things actually start getting interesting. I’m not sure if it’s in XP?

    We could search our logs to get an idea of oddball UA’s, and track some down to see if they are accessibility-related in some fashion. I doubt that would show anything for normal browsers with accessibility added on, like generic screen readers. So really we have to find someone credible to ask. Your Mother-in-law? (Or she might be able to refer us to someone.)

    Comment by ianb on December 4, 2007 at 11:27 am

  6. a belated link: http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9077118&pageNumber=3

    Comment by slinkp on April 17, 2008 at 5:05 pm

Leave a comment