The language thing wasn’t actually anything to do with intelligence (tho yeah there are some diseases and genetic disorders that also come with deafness), it’s more from the previously institutionalised form of teaching language that prevented and discouraged signing at an early age. What this caused was whole generations of children having language difficulties the rest of their lives. Early signing is learning a language during that language-window, which allows easier learning of other languages (as goes for everyone).
While I don’t think they beat kids anymore or tie their hands to their chairs like a few decades ago in more civilised countries, we still have generations of adults who went through that.
it’s just that a hearing child can associate the letter forms with sounds, which makes it much easier to understand and remember the spelling.
Dozen seam two work four English, witch spels evry witchwey. Ann donut ferget the gerl neck store. Dutch isn’t so bad, until English and French words get in. Spanish is awesome, until you have people saying “el switche” for a light switch instead of conmutador or something.
Have you run across any good tools for simplifying captioning? I don’t have any video on my site and one reason is the dread of having to deal with captioning if I want to keep on saying my site is section 508 compliant. Any tools that generate synchronized text from sound input? Any tools that generate transcripts from sound input (but you have to synch it yourself)? Any editors that make it easier to caption (I had one where you included “titles” in the video, positioned them manually, and specified when to fade in and out; it was a nightmare for more than a few lines of captioning)?
See, a lot easier than coding for the Deaf/deaf or for SL (maybe this lies more with content/copy anyway) or anything completely unpredictable like emotional instability (how do you code for that?!?). Semantic and logical coding can save your butt on so many levels.
Oh god yes. I once made the mistake of taking a sign language course at a local school. The dictionaries in our library had some California book… filled with incomprehensible stuff like “BART”… the signs for simple daily stuff like “table” were so different from what was used in my region, I felt like I was learning Chinese using Russian textbooks : (
At the time I was in the medical profession and would get a signing patient every once in an while. I still ended up on them lip-reading me. : (
From my experience (my wife is a deaf/hard of hearing teacher), those numbers could be accurate. At the very least, there are challenges (reading/writing in a spoken is a second language)
Have to somewhat disagree with you on this one - there are too many regional variations/dialects in the various sign languages to make this truly plausible.
This one is true for all writing. Too often, people either a) write like they do for print (too wordy, too much legalese or trying to sound smart; or b) writing in the texting/l33t speak. Either of these create real difficulties, especially with older users.
I guess a follow-on question to this thread is, if catering to one disability negatively affects someone with another disability, how do you reconcile that?
Is the holy grail of accessibility for everyone actually possible and, even if it is, is it always practical?
Needlessly cryptic and slow as molasses is fun? Oh wait, I do still own a trash-80 Model 4p…
Better to install Perl on it then. Much faster than Ruby and the cryptic-ness that Ruby was trying to avoid comes in extra handy for Ob-Fu contests. Or, Acme::Bleach : )
This reminds me of the time I was in a Christian book shop looking at Bibles and found one entitled, “Bible for the Deaf”. Upon asking the proprietor why a deaf person would require a special bible, I received an explanation very similar to yours.
Rule 1 of scripting; On a normal website javascript should enhance functionality, not supplant it… and that right there is where it seems 99% of the people vomiting up scripts and slapping them on a site seem to fall flat on their face. See ALMOST EVERY bit of code over on Dynamic Drive.
That or the nimrods using javascript to do CSS’ job - see that stupid malfing mm_ library crap from Dreamweaver for image rollovers; Welcome to 1997. (ok, that’s redundant - don’t need to say crap when you say Dreamweaver, it’s a given)
I guess that’s what I don’t get about jquery, prototype, mootools or any of the rest of that garbage - not only is it fat, bloated, and slow - the ‘heavy lifting’ it allegedly does seems no more or less complex than just writing it PROPERLY in the first damned place, and usually results in scripts even LARGER than if you just wrote flat javascript! People say it’s easier, I find it the exact opposite… Kind of like Ruby.
I just don’t get the appeal of making javascript more cryptic, recreating half the existing functionality in an object framework (in an interpreted language at that - mein gott) and in general turning websites into giant bloated steaming piles of CRAP.
I have rarely if ever seen anything done using jquery or any other scripting framework that wasn’t 10K+ of code ON TOP OF the library to do what I’d normally do in 2-4k of procedural code or not even DO on a website in the first damned place due to needless complexity, lack of it actually enhancing the user experience of getting to the CONTENT, or on topic to this thread; accessibility grounds.
To a techy person yes who is bothering to look at the link destination, seeing it pointing to a .mid file will make them think “audio file”. But I bet if you surveyed the web-browsing population at large, only a very small proportion would know what .mid meant, and only a small proportion of those would think to look before clicking. Adding a title attribute will help, but a lot of people will click without reading it, or even noticing it is there. To significantly increase the chances of getting the message across to people, you should include an icon that signifies music/sound by the link.
This is important not just for deaf people, but also for people who don’t want their computer to start blasting out music unexpectedly, such as people working in an office or on a train - pages that start playing music or other audio clips without the user explicitly choosing to play something that is clearly marked as an audio clip are a really bad idea, and likely to annoy a lot of people.
Well, if you had bothered reading post #4 above you would have seen that it isn’t that easy.
People who have been deaf since birth, or became deaf before they learned how to read, have great difficulties learning how to read. Partially because it’s much harder to associate random squiggles with some sort of meaning when you can’t associate it with a known sound. But also because their native language isn’t English/Swedish/Urdu/whatever; it is sign language (in a national version). And sign language is very different from spoken/written language when it comes to grammar and syntax structures.
I’ve seen reports stating that the reading comprehension of a deaf person from one of the aforementioned categories, even if he or she has a university degree, rarely exceeds that of a hearing 12-year-old.
What does that mean for a web designer/developer/author? That we need to add sign language video to our sites if we want them to be friendly to deaf people. If that’s not possible, we must make sure that the text and language is readable and understandable at the level of 12-year-olds. This, of course, benefits other user groups with reading difficulties as well.
So … do you still think it’s a piece of cake to create web sites that work well for a deaf person?
@hairybob: I can see that you’re just trying to be offensive, but do you have any idea what it would entail to create a website that was friendly to spastics? Or was that just an attempt at humour of the sort that is so hilarious to rugby players and 11-year-olds?
Yes. I think you’re right. A specifically-spastic-friendly page would probably have to have a lot of JS to facilitate appropriate delays. The clickable areas would also need to be substantially larger in a specifically-spastic-friendly page. Good points.
I think the second part might be most relevant. Clickable areas would need to present a large target and they should be far apart to avoid accidentally hitting the wrong one (for mouse users). Making sure everything is usable without a mouse would also be important (not that it isn’t anyway).
My full sentence started with something like “[coding for] blindness would be the easiest, at least until you get to AJAX”, by which I meant I figured it’s a bit more work to make sure the AJAX works and works well also for the blind. I haven’t used any Hijax but I was indeed assuming it took at least some forethought… something I don’t really consider so much for building a website (because I guess the logical order and keeping text available etc I feel goes along with the building and code-writing all at the same time).
As far as JAWS, we’ve got a regular (and newer-version) JAWS user on the forums (devbanana) who uses FF3.x (so it must be JAWS 9 at the oldest, or 10 that he uses… I don’t think I ever asked him) and he’s done drag and drop on some sites.
However the ability to use a progressive browser like Firefox isn’t very doable in older copies of JAWS. The keyboard navigation (JAWS commands) doesn’t work very well in Mozilla with my version 7, works ok in my version 10 so I can use Firefox with JAWS10 pretty easily (and you can then also make use of WebVisum, which is unfortunately Mozilla-only).
Newer versions of the Big 2 commercial Windows readers can update their virtual buffers in response to AJAX, but I don’t know how well in which situations. So, still something to be careful of as a developer, and likely takes some testing. And I’m not sure how easy it is to go through as a novice user like most of us developers are (I get around in JAWS, but painfully).
So users of an older JAWS are getting the best results with IE6 really, and that means, no buffer updates. So, AJAX will be running, because they are likely to have Javascript on (like most IE6 users), but unable to know that the page has changed, which makes it a problem… another reason I still keep IE6 in mind regardless of stats (tho our stats show IE6 at a quite high rate… and a free-time client I have, his stats show IE6 as #3 after IE7 and then IE8 in popularity… Firefox is a very very distant 4th). In order for those folks to upgrade their browsers, they’ll have to upgrade their readers. And they may still either be unaware of free readers like NVDIA (which I also have never tried) or are too comfortable with how their commercial reader works.
@hairybob: I can see that you’re just trying to be offensive, but do you have any idea what it would entail to create a website that was friendly to spastics? Or was that just an attempt at humour of the sort that is so hilarious to rugby players and 11-year-olds?
Wouldn’t a specifically-spastic-friendly page have to have a lot of JS for delays? I’m not sure you could assume Slow-Keys is turned on in their computers. Avoid dropdowns, make clickable areas larger… not sure what else.
When people were referring outdated and the often considered ‘offensive term’, “spastic”, [reply #24]. I assume you actually meant people who suffer from ‘Cerebral Palsy’ (CP), which usually has nothing to do with their mental capacity - intellect.
Most people I have seen using PC’s that have CP basically have to had helper-people aid them when using the common input controls; mouse/keyboard, etc. or at the bare minimum Assistive machines set-up, e.g. large zoom display screens, as with partially-sited users.
Obviously people who have CP have it effect them to different degrees and there are slightly different “classifications”.
Very bad question to ask, that implies that one disability is of greater importance than another or that the implication is that stereotyping the lack of abilities as some value to it. I know you don’t mean it that way but picking which accessibility you should write code for is like picking which of your children you would like to survive an armed gunman. Anyone who “writes code for a disability” isn’t doing their audience any good (and is missing the point), accessibility is an aim to be objective and take the methods which affect peoples interaction into account, not just focus on testing for “color blindness” or “blindness” or “cataract surgery victims”. The whole question is worded in such a way that contradicts the most important lesson of accessibility, that any ignored disability is one too many.
Which is the most common? They all are VERY common… I come from a health background therefore I categorise web accessibility through the PIES medical needs model (Physical, Intellectual, Emotional, Social) adding mechanical (for device issues). Which out of those holds the most common issues?
Physical includes color blindness / short sighted / eye strain (very common sight issues), tinnitus / hard of hearing / no speakers (very common hearing issue), arthritis / lethargy / broken bones (very common motor issues), etc
Intellectual includes dyslexia, learning difficulties, lingual barriers, etc
Social includes chronic shyness, phobias and issues with communication, etc
Their all as equally prevalent each each other… I maintain that EVERYONE suffers a disability of some kind, whether chronic, short-term, or of varying degrees of severity. Proclaiming accessibility into nice neat little boxes you can tick against will leave your visitors worse off as you’re treating the symptoms not the cause.
I would say it’s wrong to even think of it in terms of the disability itself, as mentioned above I’m a firm believer in that we’re all affected by disability at some point in our lives (throughout) and classifying such lack of abilities based on named conditions or the item of impairment leaves the people suffering from the broad sense of inability in the dark. Consider your entire audience as disabled, actively seek out HOW the human body interacts (in as many ways as you can take the time to learn) and then consider those methods of input/output levels as your gauges for accessibility. Not WCAG or 508 (neither of which account for anything beyond the biased viewpoint of labelling and applying a “case by case” solution). Going through each disability one at a time or trying to broadly swipe at a whole bunch of issues like visual disabilities in “worst case scenarios” may inadvertently miss some issues or worsen others that affect the end user in a different way.
I’ll help with the shooting… of people with inaccessible sites!
Yep, exactly, this is one key health condition which goes beyond what most people consider, WCAG doesn’t account for emotional disabilities or social disabilities, it only accounts for a few physical and intellectual ones (which is why I don’t think WCAG is anything more than a good starting point).
Anything is easy if you’re ignorant enough. Or do you actually know what you are talking about? Could you show us a site you’ve done that shows consideration for deaf people?
Being visually impaired gives you firsthand experience with accessibilty issues. In your opinion, what is the number one problem you have with sites that aren’t accessible? What is the best thing someone can do to make their site accessible?
I would say the #1 Thing that is very frustrating for me is when a web site has image links, but does not include an alt attribute for each of them. When that happens, I only hear the path to the image file, which often times tells me nothing about the target of the link. I’ll often hear something like:
Link graphic images/button01.gif
Besides that, I think the next most important thing is to put an h1 tag before the content. It is semantically correct, and it enables those with screen readers to much more easily navigate to the main content.
If there’s an h# tag before the content, then I just have to press “h” to jump to the next heading, or “1” to jump specifically to the next h1. I can still navigate without that, but it is a lot easier when there’s a heading before the content.
On many sites which don’t use this, I can still learn the sequence of key combinations that lead to the content. For instance, on SitePoint, specifically on thread pages, there are at least 2-3 headings above the thread. The first is an h1 that says SitePoint.com, followed by a few headings in the advertisement, which seems to change based on the forum the thread is under. So once I become familiar with the site, I can navigate pretty easily to where I need to go.
that’s sort of what i had in mind with my response, except of course you would need to consider what to do when the web site has media which includes sound, in which case you’d need to provide a text transcript for deaf users
