Web Content Accessibility Guidelines, AA conformance issue...

[Skyzyx]

Oh my gosh...

I never thought that building a site (that doesn't suck) that can conform to the WCAG spec could be such a pain.

I've got all A and AAA issues resolved, but I need to get a AA issue worked out before I can fit the AAA conformity level.

Through Bobby, I'm getting this message:

Priority 2 Accessibility

This page does not meet the requirements for Bobby AA Approved status.
Below is a list of 1 Priority 2 accessibility error(s) found:

1. Make sure event handlers do not require use of a mouse. (1 instance)
Line 46


I've got an onclick event handler on a thumbnail image that opens a full screen image with Beetle's Popup Image Viewer (http://www.codingforums.com/showthread.php?s=&threadid=9836) script. Using onfocus is not the best for this situation, and onkeypress is also a bit erratic. Could anyone suggest a better non-mouse event handler?

The URL I'm testing is here:
http://www.goldenruleproduce.com/beta/items/avocados.php

(Brothercake, got any ideas?)

Thanks.

[scroots]

it is due to the onclick. you could do <a href="javascript:imgPop('myimage.jpg');">Click me</a>
or you could add a return false in there somewhere.

this may make the full image in accessable for some browsers with javascript disabled, where as the previos methods ment they would be redirected to the full image, if javascript was disabled.


scroots

[meow]

Nuh, that's totally unaccessible. JavaScript URLs are evil (don't work w/o JS). Try to add onkeydown or what's it called so the link responds to keyboard too.

[scroots]

i bet it wuldn't validate until you completely remove the onclick but i could be wrong.

scroots

[brothercake]

the trick is not to have any hard-coded event handlers at all - add them in external script as stuff like this:

refToObj.onclick = function() { ... stuff ... }

Then make sure that you handle the return from the redundent HREF ..

[meow]

Doesn't that require the use of mouse too? I think Bobby refers to that if JS is available but mouse is not the user will be BSODed. I think he (Bob) wants you to double with an event handler that responds to keyboard action.

[theabyss]

<a href="nojavascriptpage.htm" onclick="function(); return false;">Link Text</a>

:thumbsup:

[jkd]

I think you're all missing the point (except for meow, who's nailed it). Using the "onclick" even handler requires the use of a mouse. What is probably desired is for the link to execute some Javascript when activated, and not just when it is clicked.

A disabled user doesn't necessarily imply disabled Javascript.

What is desired is the DOM2 UI event, "DOMActivate":
http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/events.html#Events-UIEvent

Unfortunately, there is no attribute equivalent to my knowledge, let alone support in something other than Mozilla or Opera 7. (Not actually tested, but both claim support for UI events)

We do have XML Events:
http://www.w3.org/TR/xml-events/Overview.html#section-listener-observer

Which allows you to do this without DOM2 UI Events support, however nothing supports XML events.


So ultimately, it boils down to there not being a current, usable solution to your dilemma. The specs are there, you just have to wait for the browsers to catch up.

[meow]

I think you're all missing the point. Using the "onclick" even handler requires the use of a mouse. What is probably desired is for the link to execute some Javascript when activated, and not just when it is clicked.

Why thank you! I've said that 2 times already. :eek:
:D

[jkd]

Originally posted by meow
Why thank you! I've said that 2 times already. :eek:
:D

Umm, yeah.... I noticed that right after posting, and promptly edited it; but not before you could expose me as a fraud apparently ;) :D. (Of course, I definitely got a kick out of this seeing it right after I edited)

[meow]

We aim to please! :p

<ADDED>
You put your edit at top too! Oh, that's low! :D

<ADDED 2>
No one ever listens to me. :rolleyes: :( :p

[meow]

It's onkeypress. onclick + onkeypress and onmousedown + onkeydown.

[brothercake]

so given that the necessary "actuate" event handlers are not generally available, the practical solution is the one I posted - a redundent HREF so that focussing and then hitting enter will activate the link and take you to the picture, where clicking it is handled by an external javascript reference, to open the popup and then return false on the link.

Everyone can access the content, and the validator smiles :)

[Skyzyx]

Interestingly enough, when I tab down to the image, and press "enter", the script fires as if I'd clicked on it.

So, the event is accessible without a mouse, Bobby's just being overtly picky.

If this is the case, the next question is a moral one: should I still post WCAG-AAA compliance, even though Bobby won't validate it?

Originally posted by theabyss
<a href="nojavascriptpage.htm" onclick="function(); return false;">Link Text</a>

:thumbsup:

I've done that... if you look at my code:

<a href="../pixx/avocado.jpg" id="linkitem" onclick="imgPop(this.href); return false;">
<img src="../pixx/avocado_sm.jpg" alt="Image of a California Haas Avocado" longdesc="Image of a California Haas Avocado" title="Click here for a larger image" id="item" />
</a>


Even with JS turned off, users can still access the image.

[meow]

Enter on an onclick event doesn't work for everyone just because it does for you. :confused:

The button? There are too many buttons in this world already.

[Skyzyx]

Originally posted by meow
Enter on an onclick event doesn't work for everyone just because it does for you. :confused:

1.) The information is non-critical. It's just a larger version of the picture.

2.) It uses a standard link, which works in any HTML-capable user agent.

3.) The image uses ALT and LONGDESC attributes to describe the information.

4.) There is also the Bobby-recommended [d] link to an external TXT description.

5.) For computers and other user agents with no mouse, the larger image is completely accessible.

For all intents and purposes, this non-critcal information is completely accessible to all user agents. All the onclick event handler does is make a nicer popup than what would otherwise be offered through other methods.

Back to my question: Should I live by the letter of the law, or the spirit of the law. Should I say my site is WCAG-AAA compliant because the information is entirely accessible, or should I leave it as WCAG-A because Bobby doesn't like my event handler of choice?

[brothercake]

Yes I think you can claim compliance on this point if the content is accessible with or without a mouse, and with or without javascript.

I would still do it remotely though .. hard-coded event handlers are not good in my book, they look messy and their semantics are dubious.

[Skyzyx]

Fair enough.

Next question: Brothercake, you mentioned in an earlier post the following code:

refToObj.onclick = function() { ... stuff ... }


Would I be able to use a simple:
document.getElementById(refToObj).onclick=function()

... or would I have to delve into the DOM2 event model with window.attachEvent's and document.addEventListener's?

[brothercake]

Yeah that way will work, or you could do an attachEvent / addEventListener - either way works, but the former is the most x-browser, iirc.

btw - might like to add a TITLE attribute as well, if the link text itself isn't fully descriptive :)

And Bobby is not so great anyway - Cynthia Says is much better - http://www.contentquality.com

[Skyzyx]

I have added a TITLE attribute; and thank you for your feedback and help. I appreciate it. :D

[brothercake]

No worries - one more thing I noticed (:)) is the LONGDESC in your example - longdesc is not text, it's a URI to another, self-contained text-file or webpage, which itself contains the long description; the spec allows that to be as long as you want.

[meow]

I'm sorry guys, but I don't understand this discussion at all. If your site needs to conform to WCAG, what is so impossible with doing the recommended and make the script respond to both onclick and onkeypress either you keep the event handler or go with brothercake's method?

I assume your pop-up is worth seeing since you bothered to create it. So why can't I, just because I maybe use Opera and don't use a mouse? I think I would expect to be able to do that if the site sported a WAI button. Alternate content is a last resort, not the top choice. It isn't all about blind users.

http://www.w3.org/TR/WCAG10-HTML-TECHS/#directly-accessible-scripts

[brothercake]

In your example ... Opera has so many predefined shortcuts that keypress scripting is basically impossible; you can't even use accesskeys - because most of the keys do something else, and you can't prevent that.

Doesn't seem to work in Safari either ... dunno why ... as if the event isn't even supported... so I've come to the practical conclusion that keypress scripting is only viable in mozilla and IE5+.. and that's why I'd hesitate before recommending it - a redundent non-JS solution would still be necessary ...

[jkd]

Originally posted by brothercake
you can't even use accesskey assignments in Opera - because most of the keys do something else, and you can't prevent that.

Actually, Opera 7 at least simply moves accesskeys from ALT+key to SHIFT+ESC+key

[brothercake]

Yeah .. but .. hmmm ... accesskeys are supposed to be ALT+Key .. that's the de-facto convention ...

<edit .. after having talked with jkd about this over msn ... and tried a few things in Opera>

That Opera accesskey is a bit erratic .. it seems you have to be very careful and deliberate in the keystrokes .. and right-shift was more reliable for me than left-shift! But it does fundamentally work; this is the page we tested (http://www.morimarketdynamics.com/accesskeys.php).

But more to the point - ALT+key or COMMAND+key is probably better, because it can be actuated with only one hand, where Shift+Esc+Key requires two.

</edit>

[MotherNatrsSon]

Wonder what Cynthia says??
http://www.contentquality.com/

MNS

[Skyzyx]

Originally posted by meow
I'm sorry guys, but I don't understand this discussion at all. If your site needs to conform to WCAG, what is so impossible with doing the recommended and make the script respond to both onclick and onkeypress either you keep the event handler or go with brothercake's method?

I will definitely look into doing that. After reading that the WCAG's spec is pickier about the details of the event handler than about the purpose/reasoning itself, I may have no choice.

Using onkeypress, however, I was a bit irritated that shift-tabbing through the links would fire the popup. On the other hand, I use a mouse, so I guess it really wouldn't bother me all that much.

Originally posted by meow
I assume your pop-up is worth seeing since you bothered to create it. So why can't I, just because I maybe use Opera and don't use a mouse? I think I would expect to be able to do that if the site sported a WAI button. Alternate content is a last resort, not the top choice. It isn't all about blind users.

First of all, all it does is open a centered window that snugly fits the larger image. It's more for aesthetic purposes than anything. Technically, I could go completely without it, and the site would be fine. But it's all about the presentation. That's why it's so important to design good-looking websites... people like aesthetics.

Now, is this a matter of aesthetics at the cost of accessibility? I don't believe so. Modern desktop browsers (being 95%+ of my intended audience) can have the aesthetic effect. Others can still view the picture in a perfectly acceptable manner. Accessibility has not been affected... only aesthetics.

Now, the reason it doesn't work in Opera and IE5/Mac is due more to a wierd math bug that I'm still trying to figure out. I plan to fix it, it's not too big of a deal. If you use a keyboard+Opera you will be able to view the script as intended (just not yet).

Originally from http://www.w3.org/TR/WCAG10-HTML-TECHS/#directly-accessible-scripts
12.4 Directly accessible scripts

Checkpoints in this section:

* 6.4 For scripts and applets, ensure that event handlers are input device-independent. [Priority 2]


Silly for this particular script, but sure, I'll add a keyboard-based event handler (although the specs don't do a very good job of listing the "input device-independent" event handlers they recommend...)

* 6.3 Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page. [Priority 1]

Not a problem. All bases covered.

* 8.1 Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies [Priority 1 if functionality is important and not presented elsewhere, otherwise Priority 2.]

It's a popup window with an image. Any browsers that don't have the necessary ability to run this script get a basic new window (window.open()). Browsers that don't support JavaScript get a standard link to the image in the same window. It meets Priority 1 standards just fine. I would just like to have it meet Priority 3 standards and it can't because of this one insignificant thing.

* 9.3 For scripts, specify logical event handlers rather than device-dependent event handlers. [Priority 2]

Same as earlier, but the specs still don't do a very good job of listing the "input device-independent" event handlers they recommend...

[bcarl314]

Have you tried adding the accesskey attribute? That usually will get you past these types of things.


<a href="javascript:imgPop(myImg.jpg)" accesskey="I">Link Text</a>


This allows the user to access this link by hitting the Alt+I keys (or what ever letter you assign to the accesskey attribute)

Hope this helps

Gets me past 508 issues alot of the time.

[brothercake]

input device-independent events are not really available at the moment; check out jkd's first response - he summed up the situation there.

As for aesthetics vs accessibility - there shouldn't be any need to compromise one in favour of the other, or at least not very often. The thing to remember is that accessibility seeks equivalency, not equality - it doesn't matter that your script is not accessible as long as the purpose of it is fulfilled without script - in your case it is, because the picture is accessible with or without it.

[brothercake]

I got this reply from Opera (with permission to reproduce, natch ;)):

Tim Altman
You should be able to change this [the way accesskeys are activated] via the keyboard editor in Opera preferences. Go to Mouse and keyboard preferences, click edit under Keyboard setup, in the Quick Find field at the top, type "acc" (for accessibility :)), and you should find the entry for Accesskeys. Click edit to change your setting, then OK to save. You should get a new file called "Opera Standard(Modified)". Then, you should be all set.

I got it to work using "Esc" on its own as the accesskey trigger, and that seemed a lot more robust (working 90% of the time), but you have to let go off the Esc key each time; I'd love to hear of any other ideas for what to map the key to - alt isn't really practicable because Opera has so many predefined alt-combinations already.

[jkd]

How about SHIFT+CTRL+key?

Shift and Control are always right next to each other, say one finger for that; plus I don't think any shortcut uses that.

[meow]

Sorry, I realize that you have left this topic but I just wanted to comment.

Originally posted by Skyzyx
I will definitely look into doing that. After reading that the WCAG's spec is pickier about the details of the event handler than about the purpose/reasoning itself, I may have no choice.

Using onkeypress, however, I was a bit irritated that shift-tabbing through the links would fire the popup. On the other hand, I use a mouse, so I guess it really wouldn't bother me all that much.

Did you do that in Opera maybe? If so, that happens because Opera doesn't use Tab to jump through links it uses Ctrl + Arrow so the keys aren't reserved. Moz can be a little irritating because it responds to double tab. Can't say I've tried every browser around but I haven't seen any problems or heard of any. I think it's great because it's so simple. I'm no javascripter (yet!) so I've just trained my editor to turn all onlciks into this 'enhanced' version: :o

<a href="http://google.com" onclick="window.open(this.href,'popper'); return false;" onkeypress="window.open(this.href,'popper'); return false;">CLICK!</a>


First of all, all it does is open a centered window that snugly fits the larger image. It's more for aesthetic purposes than anything. Technically, I could go completely without it,
It's a popup window with an image. Any browsers that don't have the necessary ability to run this script get a basic new window (window.open()).

I know. It's just that I *think* the spirit of this all is that you should get as close to the optimal presentation as possible, and in this case it's possible to get it all. I mean, if someone chooses to surf with a fully featured browser with JavaScript on I guess they want the bells and whistles.

Accesskey seems to be BSODed on the other hand. Did you read the comments at ALA? I got a headache just from reading. :(

[brothercake]

If you're gonna use keypress like that, i'd say at least build a function to discriminate by event keyCode - so that only particular keys activate the script - that would prevent the TAB-by-shooting problem.

But the situation is not particularly good, no; keypress scripting is next to impossible outside IE and moz, and accesskeys across browsers are fraught with difficulty ... finding suitable keys ... IE doesn't even activate them automatically ...

One idea would be to have a sticky key - like you press "Shift-Esc" and let go, and then the next key you press activates the accesskey - that would solve keypress scripting and key-assignment conflicts.

[MotherNatrsSon]

I am stll curious about what Cynthia says about that page. Seems to me that if they are going to require something as difficult as this for thier "rating" that they should make a solution available or scrap the requirement until one is available.

MNS

[brothercake]

Huh? The validator is not there to give you solutions, it's there to show you the potential problems; and the "rating" is irrelevant - what matters is that you try your best to meet the WAI guidelines, and that's as much a judgement call as it is a process. The validator does little more than show you where your code might conflict with those guidelines.

You gotta realise that implementing good accessibity is not easy for anyone, and awareness of it is relatively new for most people, myself included. The technologies aren't built for it, and the techniques are new and largely unproven.

Basically we're all looking for ways of making it better; we need to stay positive man and not critisize the advocates just because they don't have all the answers :thumbsup:

[MotherNatrsSon]

Originally posted by brothercake
Huh? The validator is not there to give you solutions, it's there to show you the potential problems; and the "rating" is irrelevant - what matters is that you try your best to meet the WAI guidelines, and that's as much a judgement call as it is a process. The validator does little more than show you where your code might conflict with those guidelines.

You gotta realise that implementing good accessibity is not easy for anyone, and awareness of it is relatively new for most people, myself included. The technologies aren't built for it, and the techniques are new and largely unproven.

Basically we're all looking for ways of making it better; we need to stay positive man and not critisize the advocates just because they don't have all the answers :thumbsup:

I understand that it is "in the process". I also understand from reading threads here that if the people that have been participating in this thread are having as difficult a time figuring out a solution, that it must be damn near impossible.

On the other hand, if the requirements are insurmountable for the "experts"(which I would group most of the people that are participateing in this thread, excluding me) they are not going to have many people attempting to comply and the "ratings" are not going to be as visible as they might be. The visibility of the gif's for having passed the requirements are probably a very effective means of spreading the word. I have seen very few personally.

MNS

[Skyzyx]

Originally posted by MotherNatrsSon
On the other hand, if the requirements are insurmountable for the "experts"(which I would group most of the people that are participateing in this thread, excluding me) they are not going to have many people attempting to comply and the "ratings" are not going to be as visible as they might be. The visibility of the gif's for having passed the requirements are probably a very effective means of spreading the word. I have seen very few personally.

I wouldn't say they were insurmountable. I could just get rid of the script, and everything would be peachy. However, I would rather not. As a matter of fact, I think I've gotten the issue all worked out, I just need to re-validate to know for sure.

Although things like XHTML, CSS, and WCAG aren't perfect, I believe that they're better than HTML 3.2/4.01 with no CSS and absolutely not accessible. As Brothercake had said (more or less): Just because they're not perfect doesn't mean they're not better than they were before. We've just got to work with what we've got.

No, WCAG validation isn't easy. No, it's not for "Average Joe"... but nothing "good" ever is. Average Joe does/gets what's average. If Average Joe ever decides to put in the work to become "Awesome Joe", then Joe can do/get awesome things. You can't expect a HP Pavilion to perform like a PowerMac G5. You can't expect a Ford Focus to perform like an Astin-Martin V12 Vanquish. People who are awesome drive Vanquishes, while people who are average drive Fords (well, people with average bank accounts, anyways).

Design, coding, accessibility: They're something you get better at with more experience -- the same as anything else in life. That's why I'm not writing it off yet. I believe I'll figure out how to get it to work right. I've just gotta keep trying...

[MotherNatrsSon]

Originally posted by Skyzyx
I wouldn't say they were insurmountable. I could just get rid of the script, and everything would be peachy. However, I would rather not. As a matter of fact, I think I've gotten the issue all worked out, I just need to re-validate to know for sure.

Although things like XHTML, CSS, and WCAG aren't perfect, I believe that they're better than HTML 3.2/4.01 with no CSS and absolutely not accessible. As Brothercake had said (more or less): Just because they're not perfect doesn't mean they're not better than they were before. We've just got to work with what we've got.

No, WCAG validation isn't easy, but it's something you get better at with more experience -- the same as anything else in life. That's why I'm not writing it off yet. I believe I'll figure out how to get it to work right. I've just gotta keep trying...

How did you end up "solving" this? Did it validate?

I understand the "imperfection" of everything, especially man-made, in the world. Computers, and programming languages are definitely no exception.

I think that if the "bar" is too high to begin with, in the earlier stages it may scare off many that are genuinely attempting to comply. If it is anything like coding validation seems to be they will be raising the bar soon and not lowering it.

I am a critical thinker, and not scared to "speak" those thoughts, and somewhat of a skeptik, but push come to shove, I would say I am in support of the coding and accesibility standars for handicapped people.

Did you ever try the page at the "Cynthia" site?



MNS

[Skyzyx]

Yes, actually. It didn't give me any errors, which was rather pleasing. The only error from Bobby was that event handler.

[brothercake]

Originally posted by MotherNatrsSon
On the other hand, if the requirements are insurmountable for the "experts"(which I would group most of the people that are participateing in this thread, excluding me) they are not going to have many people attempting to comply and the "ratings" are not going to be as visible as they might be.
I think you have the wrong mindstate about it - "they" are actually "us", not personally in this case, but it's all "us". If you think the guidelines are wrong then you can get involved directly.

Anyway the guidelines are specifically setup to allow for gradual compliance, that's where the whole A-levels come in - if AAA is too much then aim for AA; if that's too much then aim for A; anything you do in this direction is good.

I'd suggest spending less time with validators, and more time going through the WCAG yourself, read them point by point with your own site in mind, and just think about each thing and how you might implement improvements. Ratings and grades are not important; what's important is that you want to do it :)

[theabyss]

Code by Meow:
<a href="http://google.com" onclick="window.open(this.href,'popper'); return false;" onkeypress="window.open(this.href,'popper'); return false;">CLICK!</a>

Thank you! I didn't know how to open new windows like that. I knew it was window.open, but I didn't know how to put the rest. I can have external sites have their own windows now! :D :thumbsup: