Actually, we should be doing both. The screen reader usage paradigm, even with good screen readers, requires a site to have considered that case. For instance, translating icons popups, and other graphic information is a very hard problem to do without hints from the site developer. Some types of layout are very nice from a visual view, but terrible from a textual/reading point of view. It is problem that needs to be approached from all angles.
To work it into an analogy: What is the point of having good, easily available wheelchairs, if there are no ramps (or equivalently wheelchair accessibility means) for people to use?
> To work it into an analogy: What is the point of having good, easily available wheelchairs, if there are no ramps (or equivalently wheelchair accessibility means) for people to use?
Because the millions of dollars spent adding rubberized material to some-but-not-all street corners sounds-based UIs for some-but-not-all intersection lamps could easily buy those who need it a vehicle to climb stairs?
Yeah, I'm sure you could engineer a wheelchair that fits into existing spaces reasonably AND climbs ALL stairs. </snark>
Also: perhaps you are forgetting a few very important benefits of those street corner ramps that have nothing to do with wheelchairs:
* People pushing strollers and carts now have an easier and safer way of getting out of the street.
* Old folks who can walk but not climb stairs very well can get across the street easier.
* Everyone has a non-0 probability of tripping as they cross the varied height curbs in cities - ramps reduces that significantly, saving society a lot of lawsuit and medical costs, this is a continuing benefit.
Not a benefit, but a solid argument:
* Since almost all of the money spent on putting these in is part of normal road/curb/sidewalk maintenance anyway, its probably not as expensive as you suggest, and since the tooling exists, why not do it right this time, rather than the old way?
* Since the government is building sidewalks, do you really want your government to actively exclude people from participating in basic "for everyone" stuff because of reasons like wheelchair bounding? I can understand if it is a result of choices they make (e.g. keep sex offenders out of parks), but telling someone "sorry life sucked for you, no more participation" is not a function of a democracy.
I have noticed that accessibility features often help usability even if not strictly needed, just like in your argument.
For example for restrooms, instead of a dime-sized button for soap, there can be an accessible button big as a palm that is easy to hit and light to push.
I was going to write most in my original post, but I figured most reasonable humans know that climbing stairs does not mean climbing all stairs in the world ever.
It seems like it's been a while since you read the HN guidelines. It might be good to read them again.
I'm not sure that it was at all obvious. You suggested that all ramp building and such accessibility activity should be replaced by a stair climbing chair. I, via a bit of snark, pointed out that such a suggestion is impractical.
You and I will have to disagree on whether or not my 1 line of snark (respectfully labeled as such) in an otherwise civil and respectful reply about the practicalities of ramps constitutes incivility. I personally would say that in a conversation face to face, and very few people find me offensive (and many of those who choose to be insulted by my views not my conversational style).
As someone who has worked extensively with JavaScript web apps specifically geared towards accessibility, I can say that without a doubt the two major screen readers work with JavaScript. There are some quarks that you have to deal with but they do work, the issue is that not many developers take the time to test with them and make the necessary tweaks to get them working correctly. The biggest one being ensuring that the tab orders on elements match the flow of the application dynamics.
Do you know of any good testing guides, checklists, or suites for ensuring your site, js or not, works with screenreaders? I'd like to do a more thorough job of supporting people with disabilities (blind, colorblind, etc.), and am compiling a list of resources.
wave is a good tool, though they do complain about scripts, which can pretty much be ignored now days. Run in on HN and it will give you an idea of what it does http://wave.webaim.org/http://www.webnauts.net/check.html also has some tools but their browser emulation is dated. That being said the automated tools are good for double checking your work but nothing will replace the need for downloading a reader like JAWS and going through your site. If you look at my other post in this story it gives some development type links. As for colorblind, I don't know, I am color blind so I get our free on that one, my sites are already accessible to the colorblind. The big offense on that one is always make sure you back up color coding with some other type of system such as a number or icon system.
That's a good idea about screenreaders, but a horrible example. Screen readers a easy to fix (with minor semantic improvements to markup, or providing an API) , since there is DOM. Ramps are trivial and more broadly applicable ("universally accessible" is the official term, since they help everyone, wheelchair or not) than permanent-need wheelchairs. Ramps are the JSON API of the physical world leader.
The web was built in a manner to separate content, presentation, and later logic. It is those who insist on adding requirements that break it. Which then have to be fixed (see css).
Shouldn't we fix the screen readers, rather than fixing every website?
Any solution to any problems that begins with 'first change the world' is not a valid solution as the project will never get past that stage.
The world would be a much better place if the effort and money spent on making ramps was spent on wheelchair provisioning and development.