4 ms·

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 develo

by bphogan 16y ago

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 16y ago
(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 16y ago
  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 16y ago
    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 16y ago
      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 16y ago
    Just a note on this, you are taking issue with Javascript when in fact the issue is bad UX design.
araneae 16y ago
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 16y ago
  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.

by bphogan 16y ago

andrewf 16y ago

(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 16y ago
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 16y ago
  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 16y ago
    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 16y ago
  Just a note on this, you are taking issue with Javascript when in fact the issue is bad UX design.

araneae 16y ago

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 16y ago
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.