http://www.tothomweb.com/bloc/2011/12/les-5-etapes-de-laccessibilitat/

with the 5 stages translated into Catalan.

Excellent comment.

From my experience the Denial stage also includes ‘yes, we are very concerned about Accessibility – now, call our lawyers to make sure we do not have to do anything….’

BTW – really enjoyed your talk when you came to Perth earlier this year.

Justin

Vivienne – you may like to look at http://www.jisctechdis.ac.uk/techdis/userneeds/auditing/onlineassessmentservices. Please feel free to publicise as you see fit.

Lisa

Our website is graphically too rich to be made accessible;
Our stats show that blind users do not visit our website;
We’ll do it if someone sues us;
We don’t have to do it, we already pay the AGEFIPH fee (in France, it’s what orgs pay annually for not employing enough persons with disabilities;
If our website is made accessible, we take the risk of having disabled folks wanting to apply for jobs here.

I swear they are all true…
You might also like some of the tweets from @A11yFAIL. Again, in French, but there are some gems that are definitely worth the effort!

From our bargaining team ‘Why can’t we just include a plain text alternative in a Word doc?’ I’m always tempted to reply ‘Why can’t black people just sit at the back of the bus?’ but I don’t really think sarcasm is as persuasive as explanations, even if it’s accurate

Much love,
Marissa

Sorry for hijacking your blog, Derek. Your observations are absolutely on target based on our experience. But perhaps if we are more considerate in selecting the information we present to our audiences, we’ll make more progress.

This is an entirely separate blog post in itself, Cliff. I agree with you to an extent. You know my methods and my approach though. I teach a lot of how, and I use that to teach the why. The practical leads to people understanding the theoretical why better, because they’ve learned the why in context of how.

They feel it more deeply because they see real examples, and real solutions in action, and my hope with that is that people do just “get it” and move to acceptance. It isn’t always the case though, and depending on a person’s role at a company/organization, they may need more why than how.

Who knew you could have serious discussion on a blog on a light-hearted, Friday-afternoon blog post?

Lately I’ve heard a number of complaints that presentations about accessibility almost always begin with the justification of the cause: why accessibility matters, why people with disabilities shouldn’t be discounted, the business case for accessibility, and so forth. So imagine a person who attends a series of 90-minute presentations:
- the first might be on creating accessible forms
- the second, on creating Web templates that support accessibility
- the third, on using ARIA to create highly accessible interactions that also improve usability dramatically
In each of these presentations, they might hear 45 minutes to an hour of justification of the cause. In other words, they’ll hear the same 45 minutes to an hour of information three times. Two to three hours on “why.”

And the stuff they came to learn? You know, the “how” – the methods they can use when they get back to their desks to implement accessibility?

They get 30 to 45 minutes each on them.

We need to give our audiences more credit than we often do. When they come to learn how, we need to assume that they know enough of the “why” that we don’t need to cover it. Just pointing them to a resource where they can learn more on their own is likely enough. At this point, harping on “why” is likely to encourage folks who are already on board to jump ship.

We don’t need everyone to have a Ph.D. in accessibility engineering. We just need for everyone to know how to make the information and applications that they produce accessible.

Sorry for hijacking your blog, Derek. Your observations are absolutely on target based on our experience. But perhaps if we are more considerate in selecting the information we present to our audiences, we’ll make more progress.

If we help more people get a practical appreciation for accessibility faster, perhaps they will join us to convert those still in a stage of denial, anger, bargaining, or depression.

Anger and Denial seem to be the biggest hurdles. Once folks move beyond those stages, they’re already dabbling with Acceptance. They may still be Bargaining or Depressed but at least they’re looking at ways to implement accessibility … and that’s a good thing.

onclick="if (this.value!=this.defaultValue) this.value=''"

is definitely an improvement.

You could also use the @placeholder attribute available in HTML5, with a fallback for browsers that don’t yet support @placeholder.

I use the simple onclick js code mentioned above that is not good, I do not use onfocus here. We are supporting IE7 and IE8.

Not being an expert in javascript, is there a better way to code this? Thank you.

Also, I was baffled by the whole interview, so fully packed with solid knowledge and insights. I think I’ll actually have to cut it in chunks to bookmark it efficiently!

Many thanks for sharing so much – I definitely owe you!

Much love,
Marissa

I think some have slightly misunderstood my comments on the show interpreting me as being negative about accessibility. This is not at all true. I have just attempted to be honest about the struggles that we ALL face when considering how to make our sites accessible. It maybe painful at times and we may grumble about it but that doesn’t make it any less the right thing to do.

One issue some people will bring up is that with all those ARIA “errors” mixed in, it can be a lot harder to pick out the real errors, which is one of the purposes of validation. This is a good point, I think. But I still think the developer’s extra work of having to weed through ARIA errors is worth the users’ accessibility benefit of adding ARIA.

I know youtube is experimenting with HTML5 video, I’m guessing that native browser controls are going to be more accessible than flash.

They did this knowing that the standards are slow to keep up with the technology.

If a page validates except for the use of ARIA attributes, I read WCAG 2.0 to say that this is OK.

We’ve decided to launch our site with all three, simply because they work now and will be future compatible. Hopefully the validators will catch up, in the mean time I’ll post what work arounds I can find here in a Drupal discussion group.

Thanks for posting this article. I definitely concur that it’s time to break the rules with validation, at least for now.

Andrew

As you said, now it’s just a case of waiting for screen readers etc. to catch up, but it’s good to know that even the ones that fail now do so fairly gracefully.

Thanks again and keep up the good work!

Just wanted to see if you got the response we sent over to you? Hope you’re able to get the controls working.

Thanks,

etg

I was trying to use the code you highlighted. Not much of a techy or code guru, mostly rely on dreamweaver to do all the code work as I’m a musician and artist trying to help other artists with disabilities through our site, hence the need for access. I’m not sure what code to insert where on the script for the page to make the yt video accessible although I can see where the ty player comes up in the code when looking at code view. Thanks for getting back to me on this.

Derek

Just a quick question—are you trying to just use the code that I highlighted in the article or are you using the entire script? You’d need to use the entire script, but it will depend on the code that is in your page. You might need to make some adjustments to your HTML code.

Derek here. I’m trying to insert your code on to our website to make our yt embedded vids accessible. Our consumers are people and artists with disabilities. Where would I insert the accessible controls code in the code already backing up the page?

Thanks,

Derek

I also described my issues with JavaScript…mostly dealing with the fact that some people at my office have it turned off.

Not to repeat my second post if it is just stuck in cyber space somewhere before posting… I would like you to review my drop down CSS menu to see if it really is or is not accessible. IF you wouldn’t mind

I think a better solution would be one that works both in css (in case JavaScript is off) and JavaScript. The JavaScript version would override the CSS version since it makes for a better user experience.

That’s exactly what Option 2 does. With JavaScript on, you’ll get the optimized experience. Without JavaScript on, you don’t run into the issues that you have with a CSS only solution (like tabbing backwards through the navigation). Without JavaScript you have access to the top level elements and you get the sub-menus on the landing page for the section.

The best of both worlds!

I think a better solution would be one that works both in css (in case JavaScript is off) and JavaScript. The JavaScript version would override the CSS version since it makes for a better user experience.

If technology was perfect a CSS version would be optimal because it would require less bandwidth and coding…at least in my opinion. But of course there is no such thing

I noticed that for option #2 and #3 you are using javascript to pull off your keying events or tabbing through…but if javascript is turned off you have the same problem as what you mention in your article.

Yes, we use JavaScript. In option #2 with off-left positioning and JS off, you would have the same issue. Another case for not using off-left positioning. In option #3, with JS off you would only get the top level links and the sub-menus just wouldn’t appear.

Is there an option for someone to go through the drop down (if they want to …referring to Marco’s annoyance) using CSS alone without having to rely on some other language (javascript) or plug-in?

Hi George — there are significant problems with CSS only solutions — with CSS selectors you can only get at children, not parents so tabbing through links/menus backwards doesn’t provide you the ability to bring the entire sub-menu back on screen when you tab backwards onto a link, for example.

Is there a particular concern you have with JavaScript off? If coded correctly, and you have all the submenu content on appropriate landing pages, you should be just fine. Not optimal, but fine.

Is there an option for someone to go through the drop down (if they want to …referring to Marco’s annoyance) using CSS alone without having to rely on some other language (javascript) or plug-in?

Thanks.

Marco, thanks for stopping by and for leaving a comment. This is key:

This would be especially tiresome on sites with extensive sub-menus.

In this case, the menus aren’t that extensive or difficult to navigate. But, yes, you are correct, that setup would be optimal. That’s coming up in another article soon — we’ll walk through that scenario as well, and include ARIA for great compatability.