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%.
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.
...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.
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.
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.
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.
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 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?
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.
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.
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.
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 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.
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...
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 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.
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).
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.
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.
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.
"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.
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 s...
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.
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.
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.
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 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.
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.
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...
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.
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.
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.
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.
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.
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?
> 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.
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.
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%.
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?
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.
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?).
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.
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!!
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!
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 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.
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).
posted by joblessjunkie... WHO ARE YOU KIDDING. A chick posts something on this useless site and it gets so many upvotes, oh awarness etc, am tired of all those hippies around.
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.
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)
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.
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.)
> 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.
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.
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.
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.
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.
> 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.
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.
"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.
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.
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:
249 comments
[ 2.8 ms ] story [ 305 ms ] thread-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
And, conversely, don't submit to the current fad of low-contrast grayscale.
[1] http://wongm.com/2014/06/asking-vision-impaired-to-push-gree...
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.
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.
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.
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.
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.
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.
Video demonstrating how blind people use iOS devices: https://www.youtube.com/watch?v=vIQWyp13beE
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.
http://www.w3.org/WAI/bcase/legal-and-general-case-study
There's a before/after graph in my presentation: http://isolani.co.uk/presentations/wsg/
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.
Both are easy and free.
There are probably many groups already doing this stuff. Perhaps they just need better organisation or SEO?
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 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.
Do your readers a favour and change your font!
It's a very frustrating experience when I'm interested in the article itself, but it's literally fighting me as I try to get information from it.
(Yes, riding on sidewalks is technically illegal. There are many places where it's much much safer and there are no pedestrians to bother.)
That differs by jurisdiction; in many places it's completely legal.
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.
It's far, far safer to be on the sidewalk where I live.
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).
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.
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.
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).
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.
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.
Also keep in mind scooters (which I added in edit) are also affected - a lot of young kids in big cities scoot rather than walk and they get hurt too.
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.
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?
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 s...
Afaik googlebot does things like this already. It detects hidden elements to prevent blackhat seo for instance.
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!"
Reminds me of a Better Off Ted episode resolution: http://www.tv.com/shows/better-off-ted/racial-sensitivity-12...
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.
http://en.m.wikipedia.org/wiki/Universal_design
(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)
*there are exceptions for some industries
But the inability to replicate the experience in full, I think , inhibits catering to that demographic.
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.
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
That doesn't sound like a straw man at all.
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...
1) Press apple+F5
2) Click 'Learn voiceover' and go through the short tutorial.
3) Open safari, go to your website, close eyes.
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.
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.
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 am seeing UIs that look nice but are difficult to use for a fully able user, let alone a user with some kind of disability.
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.
People should always run their own numbers. It can vary quite a bit from the internet-wide average.
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.
This website uses a herd-to-read font and disables pinch-to-zoom (an essential feature) on my iPad.
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:
http://dl.dropboxusercontent.com/s/v5zcn9n4vg4m3cn/2014-06-1...
I also disabled scores and voting because I dislike that stuff.
This is the home page:
http://dl.dropboxusercontent.com/s/sicqor50smsl4hx/2014-06-1...
Pinch-to-zoom works fine on HackerNews on an iPad, and the HackerNews font is nothing unusual.
Regarding HN being too wide, why don't you narrow your browser window?
Personally, I like the fact the traditional web design in which HN adjusts the line to screen width rather than imposing a width.
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.
I may not be understanding it, because I just maximized the window and I don't see any issue, really.
https://news.ycombinator.com/item?id=7883973
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.
Down voted comments are supposed to be hard for everyone to read.
http://en.wikipedia.org/wiki/Emacspeak
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'd like to start this post with a disclaimer: I don't know much about creating accessible websites.
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.
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.
The article has horrible fonts.
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.
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.
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.)
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.
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.
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.
You usually can't have a design that makes all of them happy at once.
For example, high contrast UI themes often leave large white areas on the screen that users with glaucoma find blinding, but other users like a lot.
http://www.nei.nih.gov/CanWeSee/
http://www.webexhibits.org/causesofcolor/2C.html
There was a talk at WWDC about improving accessibility and usability in web apps if anyone is interested in learning more: https://developer.apple.com/videos/wwdc/2014/#516
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.
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.
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.
Sadly it "died", it wasn't deemed important enough to be voted on and so languishes in a drawer or cabinet somewhere.
Or does a disability correlate with going out less which might correlate with spending more time and money online?
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.
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.
https://www.youtube.com/watch?v=6phwEoiqLTM
http://www.ada.gov/
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:
https://en.wikipedia.org/wiki/National_Federation_of_the_Bli...
The ADA is a great example of important legislation that protects the rights of a minority group that is regularly ignored by the market.