Aiming for WAI AAA rating

[mindlessLemming]

Hi guys, I'm designing a site for school with which I want to demonstrate that a highly accessible site can also be attractive. (sounds absurd, doesn't it )
So far it's valid XHTML 1 Strict, CSS2, all elements are sized with 'em' allowing text increase, Section 508 is a good as done, but I want a WAI AAA rating. I have gone through the checklist multiple times and done almost everything necessary, but I would really like to here the opinions of some of the accessibility gurus round here.
Only the index page is up to scratch, the Queensland pages are up too, but are a generation behind

I haven't added the tabindex att as the links are already in the correct, logical order and tabbing through gives the desired result.
Any hints tips and views are welcome.
Esp. from brothercake, cause I've seen you have a AAA rating and your sites (well the few I've seen) always have accessibility in mind.

Here's the Link

Oh, by the way, the layout is only totally finished for Moz/FireAnimal/NN7 etc.... Still have to finish hacking margins and padding for IE

Thanks guys,
Andrew

*edit: I've given some pretty harsh reviews lately, so I'm expecting to get flamed

[oracleguy]

Here is what I thought.

• On the search thing, it is good that it says "Enter Search Term" but perhaps to make it easier to use is on the first click have it automatically clear that text out.
• Loads quickly, very good
• FYI, you accidently forgot the / on your link tag on line 8.
• Good choice of colors, makes it easy to read and the design scales well with changing the font size.

I like it. Good work. Although I'm not an expert on the accessiblity standards it looks like you did a pretty good job.

[mindlessLemming]

Originally posted by oracleguy
Here is what I thought.

• On the search thing, it is good that it says "Enter Search Term" but perhaps to make it easier to use is on the first click have it automatically clear that text out.
• FYI, you accidently forgot the / on your link tag on line 8.

Exactly the kind of response I was after
So to make the text dissappear, I would use something like
onClick="getElementByClass(textField).value="" ".
I don't really know any JS, so if someone could provide proper syntax that would be great!

That <link> tag shouldn't even be there, I was experimenting with providing an optional plain text style sheet but it conflicted too heavily w/ my @import: commands

Thanks a lot for that,
Andrew

[jkd]

I don't quite understand this:

	<div id="compass">

		   <h1 class="hide">Navigate Australia</h1>
		</div> 
		<div id="logoBorder"> <div id="logoIMG">
			<p class="hide">The Premier Resource for Travellers in Australia</p>
			</div> 
		</div>

Looks as though you are doing image-replacement? If .hide sets display to none, then screenreaders will see nothing, not even the header and paragraph. If directly embedding the images through <img/> is out of question (that is perfectly fine, btw, if they are not decorative), then look into various IR techniques (FIR, LIR, my own GIR, whatever) and use them.

Next thing of concern:

			<dl class="lftImage"> 
					<dt><img src="images/nt/uluru.jpg" alt="Uluru, also know as Ayres Rock, in the Northern Territory" /></dt> 
					<dd>Uluru, also know as Ayres Rock, in the Northern Territory</dd>
				</dl> 
				<dl class="lftImage"> 
					<dt><img src="images/nsw/operaHse.jpg" alt="The Sydney Opera House" /></dt> 
					<dd>The Sydney Opera House</dd>
				</dl>

The ALT text is simply duplicated in the following definition. If images are disabled, the user is presented with the same thing twice. That's kind of iffy. My CSS recommendation:
img[alt]:after {
content: attr(alt);
}

But that leaves out IE. You could use a modified expression() to inject the markup for IE if you wanted to pursue this route. Otherwise, I recommend using different text... maybe more descriptive. Or use less descriptive text in the alt attribute, such as "Uluru" instead of the entire splurb.

Going through the source some more, I see more use of .hide to hide navigational aids. Don't use display: none on them. If you must hide them, use something like text-indent: -1000em instead. Also, you don't have any skip nav links that I could see. Those are really convenient, and aid screenreader navigation.

Other than that, everything seems to be rather well done. Accesskeys can actually hurt accessibility though, believe it or not (or simply not work). See:

http://www.accessifyforum.com/viewtopic.php?t=615&highlight=accesskeys

and

http://www.accessifyforum.com/viewtopic.php?t=22&highlight=accesskeys

for some good discussions.

[mindlessLemming]

Holy WOW man, that's awesome
I'll sort this stuff out tonight and post again when it's done.

p.s. I've never seen anything like this b4! Is it CSS3? or just the outer limits of 2?

img[alt]:after {
content: attr(alt);
}

Thanks so much guys, both of these responses have been incredibly helpful


Andrew

[mindlessLemming]

Oh dear, I just read the threads you linked to, and the articles that those threads linked to...
And now I'm totally stumped as to what approach I should take RE: accesskeys..

I do know one thing however,
Everyone should read the threads jkd linked to above.

//wanders off with fresh confusion brewing.....

[Nightfire]

Looks good

I never seen the
img[alt]:after {
content: attr(alt);
}

before, so I done some looking up on google

http://www.w3schools.com/css/pr_gen_content.asp

This shows what the content: attr(alt); means and this

http://www.meryl.net/articles/archives/001132.php

shows what the img[alt] does

[Paul Jr]

Originally posted by mindlessLemming
Exactly the kind of response I was after
So to make the text dissappear, I would use something like
onClick="getElementByClass(textField).value="" ".
I don't really know any JS, so if someone could provide proper syntax that would be great!

***Okay, last edit***

You can do this two ways (well more, but I think these two are most practicle)

<script type="text/javascript">
function clearsearch() {
var theinput = document.getElementById('search');
	theinput.value=(theinput.value == "Enter Search Term") ? "" : theinput.value;
}
</script>
...
<input class="txtField" name="search" type="text"value="Enter Search Term" id="search" onfocus="clearsearch();" />

Or some inline JS

<input type="text" name="search" id="search" value="Enter Search Term" onfocus="this.value=(this.value=='Enter Search Term') ? '' : this.value;" />

Hope that helps a bit.

[brothercake]

Regarding the <dl> images - the CSS jkd suggested is not suppored in IE, unfortunately. I would recommend using the image ALT for a basic description, and the <dd> for a fuller description, as per his other suggestion, something like this:

<dt><img src="images/nt/uluru.jpg" alt="Ayres Rock" /></dt> 
<dd>Uluru, also know as Ayres Rock, in the Northern Territory</dd>

Try taking out the SRC temporarily, or disabling images, and look at it like that - does it makes sense as a <dt>-<dd> pair?

Interestingly, I recently wanted to caption two pictures, and I did it with a definition list as well http://www.udm4.com/manual/customisi...-list-overflow




Clearing the search box - well, I personally think that it's not a good idea to do that - it's not the normal behavior of text boxes to auto-clear their default content, so it's arguably counter-usability. It comes back to the default placeholder text - you don't really need it - the guidelines says "until user agents ..." [don't have a problem with empty text boxes] but the only user agent that does have a problem is Netscape 2, and nobody uses Netscape 2. I think the "until" of this guideline is well satisfied - you don't need to include placeholding text at all. What you do need is a <label> for the text box.





Accesskeys - I don't use them at all anymore, because whatever you choose, it may conflict with alt-key combinations that a person already uses. My opinion is just leave them out.

I've also come to the conclusion recently that if you do use them, you shouldn't indicate them with underline. "alt+key" is just arbitrary really - there's nothing in the semantics of accesskeys that says it should be alt, that's just what some vendors have used - mozilla and IE. Opera uses a completely different combination - something ridiculous like "shift-control-escape+key". In any case, in IE accesskeys don't actuate a link, they just focus it - that's not the same behavior as other alt+key strokes in windows, so the semantics are contradictory.

In addition to that, Home Page Reader pauses before inline elements, so if you have something like this:

N<span class="u">o</span>rthern Territory

HPR will say: "N - O - rthern territory" - broken up into three. Inline element usually surround whole words, so it usually doesn't matter, but if they surround a single letter it's very weird - with several links in a row like that, it becomes utterly confusing to listen to .. no integrity to the words.

So how to indicate accesskeys? I don't know ... that's just more weight to the argument for not using them in my mind.




Tabindex - there's a hidden danger with tabindex - if you use them, Opera 7 will *only* allow tab access to elements that have them. This means that if even one of your links or form elements has a tabindex, every single one must have one.

But you don't need to give every element a unique tabindex - you can do it groups - like "10" for all header links, "20" for links in the main content area, "30" for navigation bar links, or whatever.





You need a "skip navigation" link - an internal page anchor that jumps past your navigation bar, for the benefit of screenreaders. It's nice to have a "skip to content" link as well. What I do is have a list of accesslinks at the very top, something like:

<ul class="accessLinks">
	<li><a href="#content" tabindex="10">Skip to content</a></li>
	<li><a href="#navigation" tabindex="10">Skip to navigation</a></li>	
	<li><a href="/accessibility/" tabindex="10">Accessibility information</a></li>	
	<li><a href="/" tabindex="10">Home</a></li>
</ul>

But that asumes the navbar is at the end of the source code - since yours is relatively positioned in the flow, you'll need a link immediately before it, that jumps to immediately after it.

Remember you can't hide it with display, visibility, overflow or clip, because that will hide it from screenreaders as well. But you can use the "off left" technique that jkd described to make it invisible to graphical browsers. (or you could keep it visible and make a design feature of it )




Have you tried spltting your CSS into color and non color? If you arrange your stylesheets like this:

<link rel="stylesheet" href="main.css" ...
<link rel="stylesheet" title="Default" href="colors.css" ...

Then mozilla's switcher will give you normal style for "Default" and no CSS for "no page style", but the middle option "Basic page style" will now give you the same physical layout, but with the user's default foreground, background and links colors




In the left navigation list - the icon disappears in Firefox when you hover over the link text, rather than the containing box. That's not accessibility - but I thought you'd want to know



That "back to top" animation is very cute ... but ... you know what I'm gonna say .... I think it's counter usability, because it isn't what people expect is going to happen. I won't swear by that though .. maybe i'm just being fuddy duddy ...

[mindlessLemming]

What a response
You guys are too good, thank you all for helping me out.

Nightfire: Cheers for the links, I could see what function the CSS was performing, but as you said, had never actually seen it used before.

Paul: That's just what I'm after And your use of onFocus remindeed me that I can't assume users have a mouse to click with

Brothercake: I agree with the point you and Jason made about the alt tags...I just can't get near my computer to fix anything till tomorrow at the earliest. I got the idea for the <dl> from SimpleBits, as I'm guessing you may have also
You've convinced me, the accesskeys are good as gone. Shame though, they were worth good brownie points at college...
I haven't actually declared any tabindex attributes, as I'm happy with the order they tab in already. Thankyou <ul> navigation, you make life so simple!

Ok, checklist;
1. Less confusing alt text.
2. Leave instructions in text ield (maybe )
3. Remove all display:none and replace it with text-indent:-1000em ??
4. Skip Nav links (I did have those in an earlier version... whoops )

So after these points, I should be safe in claiming a WAI AAA rating.
Any other points to be made?
This has easily been the best response to any thread I've made here, I'm really over the moon with gratitude.

Later guys
Andrew

[brothercake]

Originally posted by mindlessLemming
I got the idea for the <dl> from SimpleBits, as I'm guessing you may have also

No I just thought of it one day. Great minds think alike, it seems I'm a big fan of definition lists - use them for all kinds of things.

Originally posted by mindlessLemming
So after these points, I should be safe in claiming a WAI AAA rating.

Well .. no after that, you should go through the WAI guidelines yourself - point by point - and ask yourself if you satisfy each one. If you can honestly answer yes to everything that applies, with an acceptable threshold of ambiguity, then you can reasonably claim AAA conformance.

But you'll never be completely free of ambiguity .. it comes with the territory ..

[mindlessLemming]

Originally posted by brothercake

Well .. no after that, you should go through the WAI guidelines yourself - point by point - and ask yourself if you satisfy each one. If you can honestly answer yes to everything that applies, with an acceptable threshold of ambiguity, then you can reasonably claim AAA conformance.

But you'll never be completely free of ambiguity .. it comes with the territory ..

I went through the guidlines point by point before starting this thread. I knew it didn't meet the criteria yet, but due to the massive ambiguity involved in AA and AAA ratings, I wanted to get some opinions from you guys first....and boy am I glad I did
I have no intention of cutting any corners though, rest assured.

Last thing - On the Queensland pages, there are two graphs in the left coloumn, displaying average temperature and rainfall. These are going to have full text alternatives linked to them (obviously in well labeled tables, being tabular data...)
My question is, should I link the long description with the poorly supported longdesc attribute, should I use the <dd> text as a link to the tables, with the title attrib. instructing the user that there is a text version, or both?

Getting there... now I just need to get back home so I can fix this stuff
Andrew

[mindlessLemming]

Originally posted by brothercake

That "back to top" animation is very cute ... but ... you know what I'm gonna say .... I think it's counter usability, because it isn't what people expect is going to happen. I won't swear by that though .. maybe i'm just being fuddy duddy ...

You really think so? I figured it was actually PRO-usability, and here's why;
The JS is not relied upon for any functionality;
Other sections of the site make heavy use of internal links (same page), and the few alpha testers I used all said they liked the fact that their page didn't suddenly skip to another section, that instead they could tell that a) They were on the same page, and b) They could tell where they were in relation to nav. and other content.

Interesting point, but I think it's going to stay