As a side note, designing well for disabilities often translates to better design as well. Those alternate text labels and better layout for screen readers can make your site easier for the googlebot to read. You can find navigation and flow issues. Buttons that are hard to click are harder for everyone to click, even if some can manage. Or those buttons are really hard for everyone on tablets to hit because they are too small.
This is a great, unfortunately under-appreciated point. In many ways it's similar to good responsive design – if you can't maintain the pretense that you can cram every control onto a screen, you're forced to actually think about what is most important to the person using your app.
(One bit of serendipity: sites which were designed to be accessible were ahead of the curve for touchscreens, too. Designers could fool themselves into thinking a 6px button was a good idea when they have a high-precision mouse but the first iPad made everyone appreciate how bad that assumption is)
This happens in the real world too, aka the sidewalk effect. The cutouts in the sidewalk for wheelchairs are now used by everyone else too for their: strollers, bikes, shopping carts, and anyone else who doesn't want to raise their foot an extra couple of inches.
There was a great TED talk about how cities which are well designed for the disabled (in the case of this talk, the blind) are well designed for all. http://www.ted.com/talks/chris_downey_design_with_the_blind_... Definitely a great concept to keep in mind.
I have seen thousands of wheelchair users. I have never seen a car that i) would have been stopped by a kerb and ii) would not have been stopped by a ramp.
Your point illustrates the subject line nicely. Very many people have a disability, yet you're suggesting very rare benefits of keeping kerbs that hamper people with disabilities.
Bear in mind that, if that really happens, it is a much, much less frequent occurrence than people being aided by the dropped kerbs and not stumbling/falling with pushchairs, wheelchairs or unsteady feet when mounting full height curbs . The proper fix for that also isn't making kerbs full height again.
In most cases you're more likely to be hit by a car if you're riding on the sidewalk. Last numbers I suggest that your risk of being killed by a car is about twice as high when you're on the sidewalk.
The reason is simple: Bikes move quickly, and bikes on the sidewalk are much harder for motorists to see than bikes on the street. That makes it extremely difficult - sometimes impossible - for drivers to see or anticipate when a bike is about to cross a street, alley, or driveway. Meanwhile, cyclists are relatively unaware of their surroundings compared to pedestrians, for the same reason that motorists are: They're moving faster. These two factors can easily combine to create a sudden use-of-space conflict that cyclists never win.
You're less visible on the sidewalk than in a lane, and you pose a threat to others. I'd almost go so far as to say, "Cycle where you're supposed to, or don't cycle." Moving in unexpected ways in unexpected places is what leads to collisions.
While your factual statements are true, and cyclists on sidewalks can certainly be a menace, I don't think it's really tenable to argue that cyclists should always be textbook road users unless you also ensure that everyone driving larger and motorised vehicles also plays by the rules.
I live in a city known for having many cyclists, and there are always tensions between the local cycling population and the authorities about the poor level of law enforcement against dangerous drivers. Of course, there is also a poor level of law enforcement against cyclists doing dumb and illegal things. The difference is that when something goes wrong, it's usually the cyclist who ends up injured or dead, not the motorist.
So while in an ideal world we'd all get along nicely and play by the rules, I don't tend to get angry at cyclists whose choices are illegal but obviously safer (as in, I've read the actual research and current law and/or public policy clearly doesn't promote the safest option, not just doing something that intuitively feels safer but maybe isn't really).
"The difference is that when something goes wrong, it's usually the cyclist who ends up injured or dead, not the motorist."
In the case of riding on sidewalks where it is inappropriate, it's also frequently a pedestrian.
"I don't tend to get angry at cyclists whose choices are illegal but obviously safer (as in, I've read the actual research and current law and/or public policy clearly doesn't promote the safest option, not just doing something that intuitively feels safer but maybe isn't really)."
In those cases, I agree that the cyclist should do what's safest (presuming it's safe enough - on balance - for everyone involved). So should drivers of vehicles, for that matter. My understanding is that taking the lane, where traffic is moving at a speed the cyclist can keep up with, is the best way of keeping everyone safe (I wouldn't be recommending it otherwise). You are right where everyone who might hit you can best see you. I say this as someone who cycles in a big city fairly regularly, with a spouse who bikes in a big city even more regularly, in the wake of biking safety classes. I'm not just an annoyed driver/pedestrian/whatever trying to keep the cyclist down.
Most big cities to me seem a lot safer for bicyclists than a lot of smaller cities and communities. The traffic is often slower, and accustomed to watching out for bicycles and pedestrians. In less populated areas, particularly those that have clearly provided no thought for the safety of anyone not in an automobile, or the occasional rare pedestrian, drivers can be very careless and accidentally or even intentionally run down a bicyclist at lethal speed. Nighttime is especially dangerous, not least for greatly reduced visibility, but also many more drunk drivers on the road.
A bicyclists safety is much more threatened by a multi-thousand pound vehicle traveling at 40 or more mph with a distracted driver on a seemingly deserted stretch of road, then a pedestrians is by a 150-200 lb body traveling at around 10-15 mph. The reaction time is also much greater, allowing more opportunity to prevent a collision on the part of the oncoming vehicle.
If bicycles are rare, you are still much more likely to be seen and avoided if you are where cars expect a car to be, then if you are where cars expect nothing to be.
Of course, there are still situations where riding in the street - either in a bike lane or taking the lane - is dangerous or otherwise impractical; the question is whether riding on the sidewalk is an improvement, or whether you should be forgoing cycling (perhaps walking your bike).
A lot of skaters and kids on scooters and have become injured thanks to the those rubber stoppers. You can't rely on them if you're disabled, because they're not on every corner. I've also read that it's cheaper to give disabled people a full time minder than to run these programmes.
Solutions that start with 'let's change the world' never, ever work. Let's fix screenreaders. And help the blind by analysing what;'s in front of them, rather than changing it.
"Solutions that start with 'let's change the world' never, ever work. Let's fix screenreaders. And help the blind by analysing what;'s in front of them, rather than changing it."
It's not screenreaders that are the problem, its the quality of the content (in terms of structure, perceivability, operability, usability and robustness). In short, GIGO. The garbage input is where the fix is needed, not the tool that's attempting to treat it as actual quality.
The "fix the screen readers" argument is a terribly terribly deep rabbit hole, requiring pretty much world-changing technologies: solving artificial intelligence, solving computer vision, teaching computers empathy, emotion, spatial relativity and context, cultural awareness, interpretation of imagery, spot and be able to translate visual cues... so many many deeply technical problems to solve.
In the choice between "fixing screenreaders" and web developers doing their jobs properly, the latter is a low hanging fruit in comparison. I assume teaching web developers basic skills is easier than teaching computers how to think and perceive (though, I recognise some people are beyond help). It takes a year to teach a web developer professional web development, it's been 60-odd years and they haven't seriously cracked artificial intelligence yet.
Responding to your 3rd paragraph. I think you are too pessimistic. Solving the general case probably is that hard.
But working "well enough", "most of the time" probably isn't. I'd think a clever selection of hacks, combined with a knowledge of the most common patterns in which websites are designed go a very long way.
Afaik googlebot does things like this already. It detects hidden elements to prevent blackhat seo for instance.
There was a period not too long ago where people were encouraged to build web apps without any behavior because screenreaders couldn't run JavaScript.
Now nearly all screenreaders can run JavaScript. The thousands of hours spent, for a 0.5% (grossly overestimating) solution, are completely and utterly wasted.
What specifically else is wrong? What wouldn't be solved better be actually fixing what screenreaders can't see, rather than trying to fix All Websites Ever Made?
"Now nearly all screenreaders can run JavaScript."
Saying all screen readers can run JavaScript is like saying all graphics cards can run JavaScript. Screenreaders don't run JavaScript. Screenreaders are not web browsers. A Screenreader is an audio interface on top of an operating system. It's the web browser that runs JavaScript, not the screenreader.
I know what you are attempting to convey, despite the factual incorrectness, and the way in which you describe it. But these are tougher problems to solve in a generic way - it requires expertise on the subject matter under discussion.
I took a sentence of words at their face value, recognised the incorrectness of your statement. Applied a context of accessibility to the statement, and discovered what your intended message was (which was quite different to the statement you used).
Human beings do this all the time. A computer would interpret your statement and say it is false. A human can divine the essence of the message without being blocked by an obviously false statement, a human can look past that and assess the statement in context.
I realise, as a human, your original statement is either intellectually lazy, or misinformed (perhaps you meant to say speech browser?). You either know how screen readers work and worded the statement badly. Or you have no idea how screen readers work, and don't actually realise your statement is factually incorrect.
So I can perceive the content of your statement: Screenreaders have the ability to deal with a dynamically updating DOM. That is a step forward, but minuscule in overcoming the typical accessibility problems present for screenreader users on the web.
"What specifically else is wrong?"
"What wouldn't be solved better be actually fixing what screenreaders can't see"
Your question is misleading. It assumes or implies that all serious accessibility issues can be fixed/addressed by a screenreader. Yes, it would be fantastic when every accessibility problem is thoroughly alleviated by a screenreader. But with today's technology it can't, not even in another 10 years. Many accessibility issues have to do with content gleaned indirectly or implied. It's a human trait of communication.
It's the difference between:
* "A red triangle"
* "Danger"
* "This side is up"
* "Go this way"
* "North"
The use of images is a serious accessibility barrier for blind people. It is not sufficient (or perhaps misleading) to just describe the image in isolation. An image conveys more information than the objects/concepts in the image. The meaningful content of an image can change as the context in which the image is used changes.
Perceiving contextually relevant content from an image - that is something blind people can't do because they are blind. It is also something that's awfully tough for a computer to do reliably. And it's something that a web developer can do in five minutes by authoring an appropriate text equivalent (in an alt attribute of an image).
The big accessibility issues aren't simple "let's parse the HTML, CSS and JavaScript", they come down to using context, visual cues, audio cues, spatial cues, implied meanings, intonation, cultural identification, localisation normalisation - a wide variety of human-based factors to extract the necessary contextual meaning.
Being able to extract the appropriate text-equivalents for an image is something that's trivial for a content writer to do - as the content creator. And exceedingly tough to do without a visual acuity, a visual acuity that computers are far from achieving.
And that's just one single accessibility issue: text-equivalents for images. If you fix that, you'll have the appreciation of millions of people instantly, a substantially accessibility barrier will disappear overnight. I strongly encourage you, if you think this is an easily solvable problem, to just solve it, or help the experts solve it. Seriously. Please.
Concrete molds for curbs are built in-situ to deal with the situation of that particular curb, and the rubber bits are at most $200, so the cost really is fairly negligible.
I can't imagine what "these programmes" you're referring to could be that could possibly be cheaper than providing full-time personal assistants to every visually impaired person in your area. The statement sounds pretty unlikely, and really demands a very reliable source, but you've provided none for support.
Beyond that though, even if this were true, the added expense alone is not enough to justify treating people with disabilities as second-class citizens, who have to be "minded" rather than allowed to freely navigate their own communities, "because it's a bit cheaper that way!"
"the added expense alone is not enough to justify treating people with disabilities as second-class citizens, who have to be "minded" rather than allowed to freely navigate their own communities, "because it's a bit cheaper that way!""
> I can't imagine what "these programmes" you're referring to could be that could possibly be cheaper than providing full-time personal assistants to every visually impaired person in your area.
Jackhammering, buying tactile surfaces, installing tactile surfaces, having a safety inspector, stopping traffic. I read this from a source, but it's my wedding anniversary and I'd rather not go into too much effort finding it right now.
For your second comment: having full time assistants is a first class experience and saves money: having inconsistent tactile surfaces is a second class experience and does not.
You are advocating for disabled people to have a second class experience, which is shameful.
This is such an important point for non-tech or non-design folks to understand. Accessible content-focused design is easy to use. It's also easy to code and easy to for search engines to crawl, making it easy to promote and share.
This website is even difficult to read on a regular desktop browser (too wide, downvoted comments increasingly impossible to read causing eye strain). I recommend using your own content script with Chrome. This may not help on your iPad but on Android you can use Firefox with your own userscript. It's the only way I can tolerate it.
It would probably take a competent someone a few hours to fix the readability issues of this site but they just never get around to it.
Edit:
Here's a link to what all comments look like for me, even if they're downvoted:
Hm, I’d be happy with some max-width:50em or so on the actual text. Now if only Firefox had a built-in way to apply custom user stylesheets to websites…
Sarcastic, yes, but mostly relating to Opera 12.x’s UserCSS features; I didn’t actually know about userContent.css. Thanks for the pointer, although it seems to be impossible to only apply it to certain sites?
Personally, I like the fact the traditional web design in which HN adjusts the line to screen width rather than imposing a width.
Its just that it ruins the experience on mobile devices because you can't resize the window and zooming doesn't reflow the text.
for what it's worth, I don't really have a problem with it. They provide an API and there are like 90 billion ycombinator mobile apps to choose from which do a better job.
The Original article seems to mis-quote browser marketshare. They have IE10 listed as 3% of the market and "Other" as 36%? And all the IE's combined for 19% market share? Everything I've seen (except the original article) list the IE's at a combined market share somewhere in the neighborhood of 50-70%., with IE8 still having a dominant 15-20%.
> Regarding HN being too wide, why don't you narrow your browser window?
Narrow my browser window because this one site makes it difficult to read? I could do that, or I could just use a content script and leave my browser at the width I prefer. I maximize my browser for distraction free reading.
Eight,I'm sure I'm going to resize my browser just to read HN and then maximize it again when I navigate away to a site which uses a sane content width. No need to be an apologist. I like the content here,but the design in many respects,is awful (expired links anyone?).
Oftentimes, narrowing HN below 1280px is still not enough as the content then scrolls sideways, so there is a very good argument for putting a width on content that doesn't adjust to the window size properly.
I just downloaded Opera for Android because of this, but no, it does not work as the old android browser did. Or do I need to adjust a setting for this somewhere?
I don't think a screen reader would pick up the down-voted comments as different from other comments. So, it's still broken from an accessibility standpoint.
Exactly, it sort of re-inforces my point that when I was designing that site I didn't really think about it.
I don't have to be an accessibility expert to discuss the fact that developers don't tend to create accessible sites!
I really liked the first font from a design standpoint and found it quite readable! It's ridiculous you're being attacked for voicing a very valid concern on your own blog, because of your preferred font choice. A lot of the comments both on your blog and on here seem to almost be mocking the idea that sites should be accessible, by making an unwarranted personal attack against you, when you clearly state you were never even introduced to accessibility programming through formal education, like lots and lots of developers weren't ( myself included ).
Forcing programmers to jump through extra hoops (trying /em to learn on their own, and making well-intentioned changes but not knowing if its right or enough or effective) is not the way to increase knowledge and uptake of accessibility-minded-design as the standard.
It would be nice if designers were still able to make stylistic choices with regards to fonts and website colors, that may be less readable for some, but have it degrade easily to something more readable with a simple command or click of a button. Besides some roundabout ways i can think of, or using readability, im not sure how to do that easily though.
That's an unfair criticism. The author (and I, and the rest of us) are not focussing our efforts logically. We can see browser stats in server logs, but measuring disabled or impaired visitors' traffic is easy to overlook - servers don't collect this data point.
She's now raised the issue for a wider audience and this could only be hypocrisy if she held herself up as an example of how to do things correctly. She isn't, and says so right at the top of the article.
I use this bookmarklet (taken from Stack Exchange [0]) on webpages that disable pinch-to-zoom to re-enable it on iOS devices. Some pages crash Safari after using it and zooming for unknown reasons.
I wouldn't consider this an impairment, but my eyesight is changing (it is getting harder for me to work on a screen when I'm wearing glasses). This font is very hard to read!!
I had a similar difficulty with reading the font. I opened the site in lynx and was surprised to discover that it was relatively well structured (easy to read/navigate).
StatCounter attempts to measure browsing volume, not people using a particular browser.
Net Applications attempts to measure people using a browser, so IE9's reported share is three times higher, around 9%.
As an analogy, take the toothpaste market with only two players. Lets say 30% of people use Colgate and 70% use Crest. But for some reason the first group uses more toothpaste, so 60% of toothpaste sold in the market is Colgate and 40% is Crest.
Now, which one has a higher "marketshare"? Crest or Colgate?
It's funny how everyone gets so confused about this.
Anyway, Net Applications is the more apt comparison here because she's attempting to compare people having a disability, not the amount of browsing done by such people.
> Now, which one has a higher "marketshare"? Crest or Colgate?
Trick question.
I can't answer that question until I've decided whether I want to be a Crest fan or a Colgate fan. Sort of like how I can't decide whether to measure smartphone market size by units shipped or dollars spent without first deciding whether I want to promote Android or iOS.
I think that in this case, it's fair to compare the number of people who have a disability instead of the amount of browsing they do, because it speaks to the potential market.
Suppose that there was no technology to help blind people use computers. Then blind people would have 0% of browsing, but they're not 0% of the population -- should we create technology to help them even though they do no browsing? (Yes.)
Regardless of if IE9 use is 3% or 9%, the point still stands. It's still an at least higher or comparable number of internet users that are ignored and marginalized by the workflows and decision-making of most internet app projects.
Did you read the article? There is no irony here, she immediately points out her lack of understanding of fundamental accessibility principles. That is why she wrote about how we as an industry allow that to happen (senior engineers who know nothing about catering to disability).
sure there is. it's like an investigative journalist learning nothing (or failing to apply lessons learned) about good investigative journalism while writing about it.
another comparison would be like a professional driver admitting he knows nothing about hand brakes, writing an essay about why he knows nothing about them, how he can learn and be more knowledgeable about them...and then proceeding to drive 1,000 miles with the hand brake engaged.
i wouldn't expect her to learn or apply all of WAI-ARIA, but you'd think after doing so much research on the subject, she could change a simple font-family tag to help her case.
And she was more pointing out how most developers are not ever taught or required to make their projects accessible (at least by company standards if not legally)
Probably because those 3% are homogeneous, while the 9% decompose into lots and lots of categories, all with specific needs, and all much smaller than 9%.
...although you can do a damn good job addressing most of them with a few simple things:
-Write good, semantic HTML, and use alt tags correctly
-Don't overwrite browser defaults for scrolling, tabbing, etc (even if it's "hot design")
-Don't rely purely on color to convey information
-Use ARIA attributes where you can if you're building an application
Some harder stuff that is really still worth it:
-Send your media out for subtitling/transcription (remarkably inexpensive)
-Actually test your site with some disabled individuals, or at least have a go yourself with the NoCoffee Chrome extension to simulate certain visual difficulties
A terrible example of relying on colour includes the braille at some Melbourne train stations[1]. It appears that someone directly translated the phrase "Press green button" rather than using left or right.
And it's not just blind people who can't differentiate between red and green. A significant percentage of the population has red-green color blindness.
Good you mention application and ARIA ... I've just come out of a project where the initial brief completely disregarded anything in terms of accessibility.
Full on angular app, no native forms or form elements (because they "look ugly" apparently).
Then the ultimate end client wants to go live but forgot to mention they had a mandatory accessibility audit.
So I've spent quite a bit of time working out how to make things work for screen readers using the ARIA specs. And it really worked quite well.
My takeaway from this is to make sure everything is working with the keyboard correctly, spend some time thinking about tabindex, labels etc, and where I can push back requests to get rid of native browser elements.
Out of interest, did you do any user testing for this site? I've worked on sites that have required a legal accessibility audit and in my experience a lot of screen readers don't even know what ARIA is, let alone use it. Like users that stick with older browsers a number of users use old screen reading tools.
Unfortunately there wasn't much budget for anything beyond the build. But the accessibility audit was lead by visually impaired people, and they did suggest what the benchmark was I had to meet and we iterated over that by me making changes and them flagging up what else needed to be done.
I also have the impression that there are quite a few people with older browsers out there because of the screen reader setup, and I don't think that's a good thing, but maybe it's a matter of doing what we're doing to older browsers in general: phase out support.
Yes. Off the top of my head, I know of at least four different types of color blindness (from red-green all the way down to total monochromatic vision), total blindness, significant visual impairment (listed separately from blindness due to different accommodations), deafness, significant motor impairment making navigation difficult, and dyslexia (which there are ways of accommodating).
Thinking about what it takes to make an IE7 user happy is easy; you just install IE7 and bash on your site until it works. Thinking about all those requirements... it's hard to look at that pile of requirements without recoiling in horror at the size of the task... at least, if you want to do anything else on your site, too. Something as simple as a single drop-down menu colored a bit "cleverly" and you've potentially whacked everyone on that list up there except the deaf. Consequently, I disagree entirely with the idea that it's just a matter of using simple HTML or something... it's actually a matter of choosing to give up on everything fancy, and that's a much harder sell.
Remember these people are cooperating with you. They are living with their disabilities full-time, and they might have found some remarkably clever ways to get along with it. I've seen blind people with iPhones (I have no idea), and a kid who used his wheelchair as a tractor to pull machinery around his parents' farm. You can work with these people, they're smart.
Whether you make your site fully screen-reader compatible is up to you, but enabling some simple hacks (e.g. custom stylesheets, browser zooming) really goes a long way. People are not homogenous anyway, so it's a good idea to not narrow down their path, impairment or not. Some people don't like to read as much, some are confused by complex looking graphics, some like animation while others are easily distracted. You need to provide different access paths anyways, at least in many of the more complex cases.
Personally I love reading large bunches of text, but I usually hate videos where I can't go at my own pace. I'd happily read transcripts if I could, but providing video only would lose you a visitor. Incidentally providing transcripts also helps with accessibility.
>
Whether you make your site fully screen-reader compatible is up to you, but enabling some simple hacks (e.g. custom stylesheets, browser zooming) really goes a long way.
Yes! It isn't as if "please don't use horrible fonts; please choose high contrast colours; please allow zooming" is some onerous difficult to follow arcane ruleset.
You don't have to give up on fancy stuff. You just have to ensure that you don't rely on fancy stuff. Which many of us think is a good idea anyway.
For example, it's fine to use color to convey information as long as that information can also be obtained in other ways. This approach not only makes your stuff usable to the colorblind, but makes it easier for regular folk too.
It should at least be standard for web programmers to develop with the most common disabilities in mind, like different types of hearing and visual impairment. In many cases it would often be trivial for a lot of sites to better accommodate screen readers, maintain usability at larger font sizes, zoom levels, etc. if it was a design consideration from the start. A lot of accommodations also improve the experience for users on different types of devices, in situations in which sound is inappropriate, etc. But because it's not a priority or a standard, things which could easily be accessible are not, and we are making modern life more difficult for others simply through carelessness and a lack of concern.
It's also easy to measure that 3% (and, by the way, it's way more than 3% on some of my sites). Hard to fix something that you don't have good metrics on.
That's a good point, but personally I'd rather cater to the people who don't have a choice in their capabilities rather than those purposely remain ignorant.
I don't agree that accessibility is a training issue and I certainly don't agree that it would take a month to become familiar with accessibility guidelines.
Rather, download a screen reader (for Windows I like Windows Eyes), learn to use it, shut off your monitor and spend one hour trying to use the web. That will give you all the context that you need. Once you're armed with this experience, make navigating through your site with your screen reader part of your regular QA process.
If you follow these steps you will:
- craft sites that are significantly easier for people with visual impairments to use.
- build sites that are easier for search engines to crawl.
- gain an understanding of WCAG that you can apply to everything you develop.
This method will not prevent usability nightmares like horrible font/icons, but it will get you most of the way to WCAG.
Or, you could start with the 4 principles of Accessibility (Perceivability, Operability, Usability, Robustness) and build a working knowledge set on that.
Screenreaders are complicated pieces of software, just an hour a day is not enough, you do need to fully immerse yourself as a blind person. Do your day job for a month using a screenreader and no monitor (from turning on the computer all the way to turning it off) - that will give you adequate platform in which to appreciate the blind people you want to serve.
But that's just one disability (though a large chunk). Visual impairments isn't just blind people. It's partially sighted, low vision, photosensitivity, tunnel vision, colour blindness - each have their own accessibility characteristics. And that's just sight-related accessibility issues... I haven't even started talking about motor-related disabilities, cognition related impairments.
Seriously, WCAG took absolutely ages to write, but it will give you a better perspective of a wider range of accessibility issues than using a screenreader for an hour a day.
So instead of having any sort of standards and accessibility best practices taught and adopted industry-wide, that take into account a much larger spectrum of disabilities, the programmers reading this should just go and spend an unspecified amount of time using a screen reader from now on?
Definitely not, but as the OP wrote, you don't start at the HTML5 spec if you want to learn to make web pages. Learning to use a screen reader and actually testing sites with it is not only a very important skill to have, but it will give developers more insight and perspective into accessibility. Standards can fill in the gaps, but I believe you still need a 'wow' moment when you feel completely lost on a website.
Does the ADA apply to the web? Yes. This has been supported in court, when the National Federation of the Blind successfully sued Target over their e-commerce site:
Speaking as a colour-blind person (protanopia) I welcome this kind of thoughts with open arms. There's actually not much you have to do in order to make a website at least readable if you just have some basic concepts in mind when designing.
The latest fad with soft pink and grey is really bad, almost unreadable for me. Luckily, I can usually just select the text and get blue/white contrast, which makes it more readable, but lately I've seen people override this too, or simply just hijack the ability to select text. I could open it in a screenreader or something similar, but usually I just close the tap and move along. Just keep that in mind if you decide to override how the browser behaves.
A funny side note, which was very clear on this website: When you're using pie charts, also know that it's almost impossible for colour-blind people to read them. The only two I could pick out was Chrome and IE11.
As a person without color-blindness, but is interested in making it easier for people with: there are a lot of different varieties of color blindness. Obviously you can (and usually should) do things like "use different brightnesses", but it seems to me that this is more solvable by e.g. an OS-level color filter. Something that allows you to compress colors into the range you can see.
Would that be even remotely useful? Are there major problems that I'm not seeing? Is that why I don't see OSes with features like that?
You can change contrast, brightness and such in most modern OSes, but I'd rather have people take it into account and choose colours wisely. The problem for most colour-blind people is contrast, not the colours them self.
I can't speak for all colour-blind people, but generally OSes have been really good at it, the problem is usually inside the browser window. And making everything look like a unicorn had puked rainbows all over your screen, while making it very readable, is not comfortable.
I imagine the main reason is that catering to disabilities is much much more expensive when you consider the variety of disabilities that there are and how much they differ in severity and how they will affect different individuals in different ways.
I also guess that people with more severe disabilities are less likely to control large corporate or personal budgets than the general population and those that do are either very good at working around their disability of simply have others to who do it for them.
It's also possible that making a site easier to use for somebody with one disability might have the effect of making it worse for a person with a different disability.
I'm sure it is quite expensive but then again, as we a web developer, my job is easily made 50% more difficult (thus VERY expensive) when I have to support IE.
The problem as I see it--and to your point--is that I work on enterprise web apps and my Fortune 500 customers have never said a word about accessibility for some reason. I'm sure they honor their Americans with Disabilities Act obligations and build ramps into their buildings. Do they then not care about employees (or customers and vendors for that matter) once they're at their desks?
I don't even think it's possible to make a website that caters to all disabilities. What is awful is that a lot of the most common disabilities (visual and hearing impairments, etc.), that affect a lot more people than you might think, could be accommodated pretty damn easily and cheaply if anyone was aware and cared in the least. But they aren't aware and they don't care, or they laugh it off like being a decent human being and giving a shit is a joke!
With this one weird trick, you can make the web better for up to 20% of your visitors! Let me tell you for free!
Please caption your videos, or make transcripts available.
Did you get that?
Please caption your videos, or make transcripts available.
Yes: 20% of people over the age of 12 have some degree of hearing loss[1]. That's 6% more (two IE9 marketshares!) than the total of vision and mobility disabilities. And if you caption, it's easy for you to see if you did it right!
[1] Google "percentage of people with hearing loss" to see multiple sources converging on this number
Also helps with search, and it will often save time to let people in general skim a transcript instead of watching a video to see if really covers the subject they need to know about.
I work at a small startup with a somewhat large user base (1M weekly users or so) and every time I bring up accessibility issues I get shot down. Just the other day I was told "You talk more about accessibility than anyone I've ever met."
Well, yeah, because apparently no one fucking cares. Including you. (I said this not out-loud, to be clear.)
Thing is, making accessible sites is usually not super difficult. It's mostly just about making sure your site follows semantic HTML standards and you're not doing funky javascripty bullshit that a screen reader can't figure out. (e.g., hover-over states on elements that pop up important help information, etc.)
Could you wrap the improvements you're trying to make as something other than accessibility? Making every dynamic control keyboard friendly for example could be sold to the business owner as "for power users", then go, refactor the bit with proper aria labels and you're 75% there?
Though advocating for fellow human beings who are treated all the time either like they're this giant burden, or like they don't exist, is pretty fucking awesome too. :-)
Well to be honest I can test my code in IE9 to see if it works. But I have no idea how a disabled person is experiencing my website, I do put all the "alt" attributes etc...but it's hard to imagine it.
Yes, that's a real issue. I've had to add JAWS Screen Reader support to an app, and even after you shell out for the thousand dollar license, it's very difficult for a casual user to use it in the same way that an actual blind user does. Ideally you test with an actual impaired user, but they have real jobs and don't want to spend all their time testing your apps.
Besides others mentioned, Sim Daltonism is a good OS X app for testing how an app or page's color choices will look with various forms of color blindness.
Color Oracle is a cross-platform app for the same purpose, though I haven't used it much, yet: http://colororacle.org It seems rather good in my limited testing.
Colour Contrast Analyzer is a Windows/Mac app for testing whether text/background contrast is sufficient. This is a matter of both color and brightness - a color combination that looks fine for a normally-sighted user may he completely unreadable for others for a variety of reason. (Part of why everyone's suggesting designers avoid the gray-on-gray or light-gray-on-white design hipster crap.)
I write sites for a government, and I most certainly write code to standards, then to aria, and finally pick apart any IE weirdness. This has been quite the fight over the years, but if we want to be considered professionals and called engineers, then we follow standards, and when an employer says "I want you to ignore standards because we don't need it" you have to say no, I'll do this right, or you can find someone else to do it. If we all did this from the start, we wouldn't be in the mess we are now.
Thank you, you made my day. Though in truth, I'm not very brave, I'm single, without wife, girlfriend, or kids, or anyone really depending upon me. And I work for government because I got tired of making rich men richer. I'm an idealist, and an idiot in truth. But thank you.
I'm no expert, but the process of using ARIA in HTML feels very much like trying to employ "semantic" HTML5 tags, except that ARIA provides a much richer vocabulary. It can be good inline documentation, too: when you come back later and wonder, "What is this div for?", seeing a role="presentation" attribute is a handy thing.
It starts to feel like ARIA takes over the responsibility of semantics and HTML becomes just a scaffold, even moreso than it has been in its relationship with CSS (tags that serve no purpose except as hooks for styling). Which I appreciate, because "semantic HTML" has always felt limited, awkward and a bit pointless, apart from the small part of the effort that has known SEO implications (h1 elements and so forth).
I think its a love/hate thing with my site theme. I've had a lot of comments that it looks fantastic. I think I'll have to increase the font size at least.
Don't increase the font size (it doesn't help). Even when they're larger, certain characters (ie - SQL) are completely unreadable. Script is always a bad idea on the front-end.
I also recommend choosing a more standard font. Personally, I left the site after trying to read the article and finding it a quite unpleasant experience to try to read.
There was a time when the web was content (or data) and it would look how the user wanted it to look, configurable via the user agent's preferences. In fact Firefox still lets me choose fonts (and tell websites that they cannot override the fonts). I use the feature for security as well as readability. I wonder how long it is until they decide to remove the feature because it breaks the web...
I am thankful you still had a choice to continue reading or not. I am thankful you had the choice to use a user-stylesheet to override both the font-family and the text colour into something more readable for you.
I am thankful that the ability to work around these shortcomings was in your control. (Chuck it through a readability bookmarklet, as an alternative to overriding CSS)
Spare a thought for people where the choice of whether or not to consume a piece of content is taken away from them because they are disabled, and they have no straightforward way of working around the barriers the website has placed before them.
These people don't have the choice you have, unfortunately. I wish they did.
If you want your site to be accesible, there are a number of things that are a good way to get started:
1. Contrast. Don't use gray text on gray background [1]
2. Keyboard accessibility. Avoid adding onclick handlers on elements that are not an <a> / <input> / <button> [2]; use tabindex to make certain page element focusable and CSS's :active, :focus pseudoselectors (adding border, outline, changing background color etc.) to clearly indicate where's the focus for the keyboard users so they can navigate the page easily.
3. Avoid quickly-disappearing menus and everything that requires precise mouse pointing (elderly people tend to have problems with that) and can't be triggered from keyboard.
There are lots of websites failing at those basic things. When you fix that, you can start going further and making site further accessible for certain minorities.
Where are those numbers from? 3% seems really low. I would guess the IE8 (being the highest version that can run on XP) population is much higher then that, but IE9 was chosen to make the number look better.
Pretty off topic, but why would anyone ever stay on IE9? It means you are on > XP which means you should be able to upgrade to at least 10 I believe, if not 11. Is it just a lack of permissions to upgrade the browser combined with lazy administrators?
I don't know. Nearly all the IE9 users are on Win7.
If I had to guess, it's simply because upgrades are such a hassle in heavily regulated industries. (Above and beyond the typical hassles of an upgrade in any large enterprise.) I see similar numbers in Healthcare, for example, but not Education or Construction.
I keep meaning to do a blog post about the tech trends in different industries.
IE8 was 6%, which I think still validates the point. I actually chose IE9 because a lot of companies have actually dropped support on IE8 but are still supporting IE9 (mine included).
Fair enough, I guess the usage is just lower then I thought which is great news. As another commenter mentioned though it is very dependent on industry, I wouldn't be surprised if some enterprise applications have much higher IE usage.
I agree with the OP that the reason most developers don't build accessible sites is because they don't use the accessibility tools and hence have no understanding of how they actually work and the experience they provide for their users. Reading the List Apart article I linked to was rather eye-opening to me (no pun intended) because I didn't realize that I could just use a Chrome plugin or my iPhone's voice-over as a screen reader to actually experience it myself. I am now wishing I could go back and change a lot of html structure on sites I've built in the past to make it easier to navigate via screenreaders!
First, these two groups may or may not be mutually exclusive. Catering for the former may take care of some of the latter too.
Second, this question is actually very easy to answer. Catering to disabilities makes almost no money. Catering to IE9 gets the customers that forgot or don't know how to upgrade. That's a wash when it comes to advertising.
Edit: Just to be clear, I'm not playing devil's advocate. I do my best to cater to people with poor vision for anything I write. That includes anything I use colour for. I'm simply answering the question as if I were the CEO of a company, where my goal is to make as much money as possible, and not care about anything else.
Too bad companies aren't people and can't have morals... oh except they're run by people, so that just means the CEOs running these companies are greedy unprincipled douchebags.
Making a web site or mobile application accessible is about making it parseable to the accessibility application that the user with disability has installed on their machine. A text to speech app needs to be able to access all the content. Put the right tags on fields. Add alt tags on images.
On Android, the Lint tool actually calls these things out. I have no idea what it feels like to use a screen reader, but I spent the time to actually put in those tags to enable it for the users of the app. It doesn't take long.
>> Making a web site or mobile application accessible is about making it parseable to the accessibility application that the user with disability has installed on their machine.
He wants access to a VM (or many VMs) with the accessibility application that the user with disability has installed
"But the inability to replicate the experience in full, I think , inhibits catering to that demographic."
That makes me think of trying to see what it feels like to be inaccessible user, I'm picturing a VM that makes the screen fuzzy or something.
If all you want is a VM with the tools installed - that's pretty simple. I imagine every developer can make a VM with an OS in it, and there are plenty of free accessibility tools available for the OS of your choice: http://usabilitygeek.com/10-free-screen-reader-blind-visuall...
Yes, outdated browsers is the devil that developers know.
We hackers are frequently solution driven, with a heavy focus on tools. This quickly tailspins into goals focused on incremental changes (load faster, show more info, integrate with this other thing) instead of stepping back and looking at the larger picture (who are my users and what do they want to do?)
Fighting for 3 hours to get your graph to load properly on IE7/8/9 is silly if a table displays the information more clearly and is more accessible.
Even if you had a virtual machine with accessibility tools on it, it wouldn't mean you'd end up using it like someone would if they've been using these tools for years. The article is just pointing out the exact sort of industry-wide ignorance of and ignoring of accessibility standards and best practices that you're experiencing, and calling for something to be done about it.
> So why do we think it is perfectly acceptable to spend time ensuring that our websites work in IE9, but not that you can navigate them with a keyboard?
Lack of empathy, basically. There's very little financial or technical incentive to supporting disabled users. People just don't give enough of a shit to help people who have a hard time using technology. Sadly it's going to take a strong push from an advocacy group for disabled users to be taken seriously, just like they were necessary to get ramps and rails as required for all businesses.
Because IE9 is the first browser by Microsoft that supports standards sort of reliable like more than 70% of the other browsers out in the wild. So we support it because doesn't take much effort to support it. The choice IE9 or better is because of the quality of that browser, not because we care a lot about the actual marketshare.
Furthermore I always try to optimize the "dry" HTML and use semantic HTML not because of the blind and disabled but because I like my documents be read by non-humans that apparently are blind and deaf and have bad JavaScript support in their browsers to boot.
Don't do it for the disabled.
Do it for the blind and deaf unstoppable corporate robots.
Accessibility is more than just Perceivability - a characteristic robots would appreciate. Accessibility includes Operability and Usability, these are more human focused, and less robot focused principles.
What's the point of having a perceivable interface without it being usable or operable? See this: https://news.ycombinator.com/item?id=7885113 -- for accessibility tips that have no relevance to spiders/bots, but is fundamental to accessibility.
That's where this "robots are like blind/deaf people" argument falls down.
Accessibility is about removing barriers for humans, with human related disabilities. That making those changes also makes content more consumable by a spider or crawler is a positive side-effect. A great positive side-effect, but not the primary aim.
According to WHO only about 4% have a visual impairment of any kind, and how exactly would one design for a dexterity impairment? Simpler to navigate menus?
And as wfjackson notes below, the browser statistics appear to also be in question.
Finally, I'm sure that someone would contest the claim, but it's far more difficult to design for blindness than browser idiosyncrasies. The entire UX has to be re-thought down to the last detail. When you consider the myriad interactions that could occur and the difficulty of building & testing for a small audience, it's no wonder that it's still the status quo.
I don't know that I agree that looking at this from a market share perspective is useful. If only 1% of your audience uses screen readers, should you use that fact to decide it's not worth supporting them?
I don't think she was looking at it from a market share angle as much as a "this is what percentage of internet users you don't even give the slightest thought to when making your website" angle. A lot of accessibility improvements are trivial and of negligible cost to support by giving this group the slightest consideration in your design. It makes sense because of human decency, or the pursuit of it at least.
I don't think it's necessarily cost-effective for many places to have accessible toilets. They do it because they've decided it's the right thing do to, or because society has decided this and made a law. Nor do I yield my seat to the elderly because it's somehow cost-effective.
While you and I may consider IE8 a handicap :) it's theoretically possible to upgrade. Barriers to upgrades are usually corporate policy, very old OS versions, or low tech knowledge. All are solvable, to some extent, by action on the users part (or their IT guy). There are exceptions, but it's a tool issue on the user's side, and other tools are generally available.
True disabilities are usually not within the users, or their companies, control. They can't use their own resources (time / money) to fix the problem, or lobby someone else.
Yes, it's a tough decision what to support. My point is that the percentages of disabled users are often far below what would make financial sense to support, but often there is a need or legal requirement to support them regardless.
"My point is that the percentages of disabled users are often far below what would make financial sense to support"
Yet every dollar spent focused on web accessibility further improves the usability of the site for your entire audience too.
I rebuilt the Legal & General's online home insurance purchase flow. That resulted in a doubling of the number of people completing an online purchase.
Are there stats on whether having a disability makes you more or less likely to make a purchase in a given product category? E.g. does having a disability correlate with not having a job, which correlates with having less disposable income, which correlates with making fewer purchases?
Or does a disability correlate with going out less which might correlate with spending more time and money online?
I've been wondering about this for a while. For my thesis project in college, my class created a web app for a school for the blind and visually impaired. We were greenhorns when it came to creating a production ready system, but we were able to meet the standards for usability by implementing them while the project was going, not as an after thought.
Indeed, the question in the title has long been overdue.
And, yes, bad — no, really BAD readability of web sites seems to be quite standard these days (including HN). And, on top of that, the worst offenders block the zooming functionality in mobile browsers. Mankind never had a shortage of torture specialists.
It's interesting to see so many developers demanding an easier way to test whether a website is accessible.
> Show me a virtual machine that I can test with, that puts me in the shoes of a user w/ a disability, and I'll develop with accessibility in mind.
> Well to be honest I can test my code in IE9 to see if it works. But I have no idea how a disabled person is experiencing my website, I do put all the "alt" attributes etc...but it's hard to imagine it.
Turn off your monitor. Turn your laptop brightness all the way down. That's what it's like to use your website while blind. Basic screenreaders for the web cost zero dollars and could not be easier to install [0]. A screenreader for Mac OS [1] costs zero dollars and is already installed on your machine.
Stop pretending that these tools are mysterious. You or someone you know might have no choice but to become an expert screenreader user tomorrow. Have a little bit of compassion.
Great all the comments are ignoring the (pretty damn interesting) point made in the article and rather just attacking the aesthetic of the blog. Way to go HN!
1) We don't cater to IE9, which is at 5.11% according to stat counter. IE9 is a bad choice point for this - it's the first IE that had auto-update. Everyone left. We're catering to IE8+; 8 is currently at 6.5%.
2) You don't count the version; you count the version and all its successors. That is, we're not catering to 8, we're catering to 8+. 8+ is at almost 35% and is still the dominant aggregate browser.
4) You can't cater to disabled users. They're not one thing. What you do for the colorblind isn't the same as what you do for the blind, which isn't the same as what you do for people who have specialty control systems, which isn't the same as what you do for micro-screens, which isn't the same as what you do for people who have motor control circumstances, et cetera.
5) The web solution for this is WAI-Aria, which began in mid-2012, and became a candidate recommendation three months ago.
6) Microsoft has been requiring WAI-Aria for store apps since late 2012.
7) Most people have never heard of WAI-Aria.
8) As far as I know, no single group of disabled users reaches 1% of the userbase.
9) Supporting old browsers is way, way easier than supporting disabled users. Old browsers mean installing a shim and fighting a couple bugs, and that level of effort leaves people writing angry blog posts for five years. Supporting disabled users means learning how (there's basically no tutorials, but ample angry blog posts with bad statistics) then finding someone who has the equipment to test it on, then learning that you have to re-order everything on the entire site because the reader software can't be told that the source order isn't the reading order, then adding several properties to every single tag on every single page, then having no way to audit.
10) Many of us /do/ cater to the disabled. Your site has no aria markup at all, is peppered with empty iframes (which will wreak havoc on older readers,) and is covered in images that have no reader equivalents. You are actually substantially less disability friendly than the average webpage.
11) Even people with full sight find a font and color scheme like that very difficult to read.
12) In short, because like you, most small web authors are more comfortable writing about the problem than being part of the solution.
" 1) We don't cater to IE9, which is at 5.11% according to stat counter. IE9 is a bad choice point for this - it's the first IE that had auto-update. Everyone left. We're catering to IE8+; 8 is currently at 6.5%."
Why bother? in a few months it will be 5.5%. Next year it will be 1%. Why invest any time or attention to a browser whose market share is low and continue downwards into nothingness?
"2) You don't count the version; you count the version and all its successors. That is, we're not catering to 8, we're catering to 8+. 8+ is at almost 35% and is still the dominant aggregate browser."
That's just a sleight-of-hand obfuscation. If 9+ is 30%, why quibble over the extra 5% (and only dropping over time) that IE8 will offer. It's a diminishing return adding an older browser to the browser support list.
"5) The web solution for this is WAI-Aria, which began in mid-2012, and became a candidate recommendation three months ago."
No, WAI-ARIA became a Recommendation in March, not a Candidate Recommendation. The distinction between the two is two independent implementations.
"8) As far as I know, no single group of disabled users reaches 1% of the user base."
* Colourblindness (8% of Caucasian Men)
* Dyslexia
"9) ... Your site has no aria markup at all"
The non-presence of ARIA does not make a site inaccessible.
"12) In short, because like you, most small web authors are more comfortable writing about the problem than being part of the solution."
Unfortunately, you are presenting the opposite side of the problem. So you have a little more knowledge about accessibility issues than the OP - but not enough to pass a quick scrutiny.
Perhaps, what is needed is for you and I to stop being part of the problem of disseminating half-truths, and spend that time quietly doing our jobs properly, and showing the results of these. Invest the time to teach someone else how to build accessible websites, and encourage them to also share what they know.
In all fairness, the poster of the blogpost has a fighting chance of improving her skills. She is worth teaching, for the scales of dogma have fallen from her eyes, and she is enlightened.
Because the stakes are high enough that 5% validates the engineering effort.
.
> 2) If 9+ is 30%, why quibble over the extra 5%
Same answer.
.
> 5) The distinction between the two is two independent implementations.
I didn't know that. Thank you for the information. :)
.
> 8 #1) Colourblindness (8% of Caucasian Men)
Jesus, really?
Luckily, my sites tend to be monochrome, so I get trapdoored on this.
.
> 8 #2) Dyslexia
I wouldn't even know where to begin making a website be dyslexia-sensitive. I don't know anyone affected and don't even know what's important there. Is there a resource about this?
.
> 9) The non-presence of ARIA does not make a site inaccessible.
In a question about why we invest no effort in accessibility, it is germane to point out the level of effort you have placed into accessibility.
And, respectfully, that markup.
.
> Unfortunately, you are presenting the opposite side of the problem.
I'm just explaining why it isn't gotten right.
.
> So you have a little more knowledge about accessibility issues than the OP - but not enough to pass a quick scrutiny.
Yeah, that was my point. My belief is that this limitation that you have correctly observed in me is the defacto case for nearly all web developers. I think it's just something most of us don't know.
Like, write a poignant guide or a learn you some consideration or something. Give people something to read, rather than to point out that they haven't read anything, you know what I mean?
.
> Perhaps, what is needed is for you and I to stop being part of the problem of disseminating half-truths
I don't believe that I have done this. I did make an error in naming the kind of recommendation though.
.
> spend that time quietly doing our jobs properly
I think that I actually do this. The world is full of a lot of hard, unfair choices, many of them outside my hands. I do my best to support as many people as I can within my time and budget constraints.
Perhaps we disagree on the choices, however.
.
> Invest the time to teach someone else how to build accessible websites
Yes, that was my point. Easy to say; too hard, apparently, for either of us to do.
The question was "Why do only cater to the former?" not whether or not it makes sense to do so. In fact the very question strongly implies that it doesn't make sense.
Non disabled persons using older browsers are used to things "just working" for them, so they have a lot of energy to expend being pissed off when things don't work.
Disabled persons are confronted with lots of things not "just working" for them, so the energy of being pissed off gets more spread out.
In the general case, this causes a positive feedback loop where minor issues for people without major problems get fixed, while more significant issues for people with even worse problems don't get fixed.
Because "a disability" is extremely broad, and covers such things as back injuries, diabetic neuropathy, and mental illnesses. I would expect that percentage to come down considerably when factoring specific disabilities that actually impede browsing.
xScope provides a great tool for testing common vision impairments. What I'd love is a well written overview for keyboard accessibility within websites.
it concerns me that you think you can call yourself a senior web developer without even once reading the w3c specification, because that would be crazy
I think we live in a time of pretentious graphic designers (not saying you are, saying its a huge trend) who all think they "have it right", which is way all modern websites are looking very samey.
It's a personal blog, it's not comic sans, so how bad can it be?
Wow, that's a terrible font, especially for an article talking about catering to those with disabilities. I found it hard to read, and I have perfect vision.
Apologies in advance for the poor (attempt at) humour, I don't mean to trivialise a real issue, only to ridicule IE9 users.
In all seriousness it's due to the complexity of catering for certain disabilities each of which require entirely different technical solutions, and some of which depending upon OS and various devices can be seamlessly provided for.
I would say a better question here is why isn't there more standardisation on the technology and approach to better serve the needs of people with a disability.
It's not a purely technological issue either, I've never seen a tender for website or application development with any provision for it. And I've seen a fair few.
If you've seen tenders for websites that ignore usability for disabled users you've seen companies that are, depending where they are, breaking or close to breaking the law.
Obviously you can't name and shame, but a blog post saying "I have seen X number of website tenders and none of them include any mention of usability for disabled users" would get some notice.
Speaking of name and shame. People sometimes bring a lot of intensity to bear on a single statement or campaign contribution. It would be great to see similar intensity for acts of omission. If someone leads an organization that hasn't made even a weak effort at improving accessibility or diversity, that deserves some gnashing of teeth.
I think what accessibility and diversity both have in common is that the problem can seem overwhelming. Progress needs to happen step by step, organization by organization. We should encourage and compliment people who are taking even small but meaningful steps -- and "shame" the ones who are making excuses for not even trying.
I don't use Windows so I can't comment on that, but OS X has a lot of support for disabled users. First, VoiceOver is a built-in screen reader and there are a variety of other options to adjust the contrast, cursor size, amongst other things. There's support for visual alerts, mono audio, and subtitles. One can also use switches to control the system if you have them connected.
Basically, Apple spends a lot of effort to make their products accessible. I know that iPhones are popular in the blind community as the VoiceOver support makes it easy to use.
I've found that OS X is far more usable now than the 10.1-10.4 years. So, while the form has improved, so has the function.
"3% browse with IE9 and 14% have a disability. Why do we only cater for the former?
So why do we think it is perfectly acceptable to spend time ensuring that our websites work in IE9, but not that you can navigate them with a keyboard?"
if she is so concerned about making websites accessible for those with impairments, why in the heck did she choose that font?!?
2nd, you are really twisting things. first you take ALL people with disabilities (term used generously), and use that to justify websites having to comply with an issue that effects less than 1% of the population. the vast majority of disabilities falls under visual impairment, and all websites should strive to make them readable.
Then you do the complete opposite to IE. you disregard all the IE versions and focus on just one. in short, you lumped all disabilities to validate your point about one specific part of it and bifurcated the IE market to make it seem smaller to prove your point.
The original Microsoft research paper she pulls the number "14%" from uses questions like "do you have a visual impairment?" to determine disability. So if you wear glasses or contacts, you're disabled apparently.
agree, and trying to act like the internet is unusable by 14% of the population (all because they have a disability and those programmers and designers are ignoring their plight) raises red flags. over 1/10 people? really?
she claimed she doesn't know much about the process. which makes me wonder why write an article critiquing it then. but i can attest, making web pages usable/readable/etc to as many people as possible is always a huge part of the process.
