[bphogan]

If you haven't got the experience, then yes, it's going to seem like two times the work. But I am a low vision user who disables JavaScript often because developers don't understand that jut because I stopped moving my mouse doesn't mean I want to see a popup definition of the word I hovered on which obscures my viewport. (I'm zoomed in now as I type this).

I'm saddend (and a little angry) at the number of developers here who absolutely insist it's so much extra work to build a site that doesn't require JavaScript. If you follow best practices, it's not a big deal. Web apps create, retrieve, update, and delete records. No matter how fancy your new startup's idea is, you have to realize that it's all the same task over and over again, and you can do that with simple web forms that don't require AJAX. A little unobtrusive JS to capture clicks, hide boring interfaces, and transform your dull non-JS interface can go a LONG way. Plus you can test that the underlying functionality of your site works very early.

I'm required by law (Section 508) to build accessible web sites at my day job. It's much easier to make Section 508 compliant websites without JS. Then we put the icing on the cake to satisfy the other 98% of our users.

[andrewf]

(This is an academic point for me right now - I'm building an app in Facebook, and Facebook requires Javascript.)

It seems like your zoom software interacts badly with behaviour that's common on some websites. Disabling Javascript seems like a reasonable workaround, but not without cost. I'm curious - why are web developers the target of your aggravation, rather than the people who wrote your zoom software?

It seems to me that a lot of expensive accessibility software copes well with computing circa 1998. But then it hit a wall. Most of the advocacy and lobbying around this issue seems to focus on forcing most developers to adapt to the limitations of this accessibility software, rather than pressuring accessibility software vendors to provide software which (a) delivers innovation and utilizes advanced technology, as you'd expect in 2010 and (b) deals with common patterns in modern software development.

[bphogan]

I am aggravated by the developers because developers are the ones who confuse interactions (clicks) with invitations to interact (hovers). When I move my mouse, my viewport moves. That's by design, as the mouse pointer can be placed near words so I can see it. Keeping the mouse pointer visible is important when you can't see it well.

Now imagine I'm surfing as a blind user, and I follow a link from HN, and my screen reader starts reading the page, only to be interrupted by a "take this survey" modal DIV. After a couple of times I'm turning off the JS, cos that's really annoying.

The people who make my zoom software make OSX (it's built into the operating system and it works amazingly well for me except for applications which fire events when I hover.

Following the principles of UJS and web standards makes it infinitely easier, in my experience, to develop web sites that work with screen readers and still use that advanced technology that everyone's gaga over. But if you can't write JS easily that works across multiple browsers, how do you ever expect assistive technology to be able to interpret it correctly? :)

[andrewf]

The iPad doesn't have the concept of a hover, so websites pretty much have to work without it.

It'd be nice if Apple could turn around and kill the hover in Safari when somebody's using the zoom feature. It'd be even nicer if you could toggle this on and off right now (right Apple button, maybe?) because mouse hovering in the zoom application is obviously _not_ necessarily the same user action as mouse hovering without the zoom app.

"Take this survey" DIVs destroy usability for everybody :(

[bphogan]

eh, from my experience the iPad does have "tap-to-hover" support which is pretty nice actually. Many hover-only events do work, even ones that haven't been written to support iOS-specific events. So they're doing something.

[kls]

Just a note on this, you are taking issue with Javascript when in fact the issue is bad UX design.

[bphogan]

No, I don't think I ever said JS was bad. I said I'm saddened by developers who use hovers, and by developers who think it's too hard to do non-JS versions of sites. I personally love using JS to improve the user experience. I think it's pretty damned cool because of the way I can use it to transform a very dull, cumbersome postback interface into something wonderful without nearly the effort that people claim it takes.

[kls]

Yeah I am sorry, I was posting in response to the grandparent and somehow ended up replying to your post. This was in reference to the low vision individual who was arguing that hovers mess up their screen reader. I would delete the post but it would leave your comment hanging. So I will leave it, but it was not directed at you.

[araneae]

Speaking of webforms, how would you treat a webform that has a variable number of fields? The non-js way I've seen this treated is to have like 5 fields and then reload the page if they want more (i.e. multiple files uploads), but it seems like there's no non-icky way to do this sans JS.

I am open to suggestions :).

[bphogan]

Recently, I had to implement that, and it came down to this: The multiple file upload functionality is an "icing" feature. We just set up the UI to upload one file at a time. Accessibility doesn't have to mean "it works the same". Reasonable alternatives are fine.