WCAG: test results vs real world reality

[adh32]

I have just had a go at testing an example page for WCAG compliance using "Cynthia Says" (found it via Google: no idea if it's good or not) and some of the requirements for levels 2 and 3 are strange. It gives warnings for the absence of:

• A keywords meta tag (which I wouldn't bother using, based on what I have read)
• A language meta tag (which is not valid HTML as far as I can see: it failed validation when I tried it)
• The need for a logical tab order. It is already logical, but it implies that I should add tabindex attributes to all elements in the tab order, which is surely not necessary in practice?
• Keyboard shortcuts. I have read articles that suggest that accesskeys are probably better not used. My gut feeling says not to use them.

I know that automated testing is not always 100% right, so I checked the WCAG guideline.

The first point seems to be a very strict/literal interpretation of 13.2 (Provide metadata to add semantic information). The guideline hints at the author metatag in its example, though the report didn't pick up on its absence from my test page. The second warning came up despite using the lang attribute on the html tag. This and the third warning is just indicative of a badly written automated test, isn't it? The fourth warning seems to be right by the guideline, but which view about accesskeys is more appropriate in the real world?

Anyway, the gist of my question comes down to me wanting to do the right things and I'd like to state that my site meets a level X of the WCAG, so I need to be sure what that level is.

[xhtmlcoder]

It's a robot and robots are stupid, when it comes to 'human judgement' they can only be used as a small indication and a lot of times they give false positives. In either case proper web accessibility is not a just a checklist and tick-a-box, it goes way beyond that, etc.

[adh32]

Yes, I can appreciate what you are saying, but it doesn't really answer my questions about what is really required to meet a certain level and how to be sure that said level is met if automated testing cannot do that.

[xhtmlcoder]

Humans is the answer; or specifically testing with people whom have disabilities, alongside reading the relevant literature on WCAG and it's supporting documents, and using good 'judgement calls', etc.

It's slightly subjective anyway it's not an exact science you can check for valid documents with machines and perhaps colour contrast. Plus a few other things but it demands that the web author properly understands web accessibility and semantics too.

It's an extremely complex subject and the more you learn about it, the less you realise you know...

There isn't a black and white answer the best you can do is study the subject in detail and then get a better idea of what the criteria means. I probably could determine if a site met certain WCAG 1.0 levels though my interpretation is a lot stricter than many peoples.

[rguy84]

I know the developer of Cynthia says, I believe he hasn't really touched it in years. Are you using the WCAG settings vs the Section 508 ones. WCAG is a bit more less structured than 508.

[Stomme poes]

Also, some things from WCAG1 are negated in WCAG2.

Examples: they're looser on scripting now with WCAG2.

Language meta used to be recommended in addition to the lang attribute on the html tag, because some UAs looked at just one or the other. However today, the W3C Internationalisation checker recommends strongly against the language meta. Maybe because of something Crusty said elsewhere: he said the sub-sections of the language codes weren't allowed there. If that's true, then it makes sense to stick with the lang attribute which I know accepts subs perfectly well (sub like, en-us, en-gb, es-es...). Modern AT looks at the lang attribute alone, or ignores it entirely, but I don't know of one that uses the language meta anymore. Plus, if you need that header, should be sent from the server.

I would try to use a more up-to-date checker for your automatic checking thingies. What about WebAIM's WAVE?

I ran one of my pages through and the only thing it complained about that I disagreed with is, it did not like negative tab indexes (which are also illegal with HTML4.01Strict anyway), even though as a human I can attest that I used it to reduce repetition in links as a sighted-keyboard-accessibility-plus (none of my screen readers seem to pay attention to negative tab index... they'll read it all out anyway).

It mentioned the "good" stuff I did: headers, alt text, etc. However it used symbols which I had to guess a bit on what they meant (there's prolly a page on the site that explains them).

[xhtmlcoder]

However it used symbols which I had to guess a bit on what they meant (there's prolly a page on the site that explains them).

It typically uses the alt and title attributes for explaining the icons on the results page. Plus: http://wave.webaim.org/icons I see the lazy cat is sleeping... };-)

[Stomme poes]

ZZZZzzzzzzzzz....

[adh32]

Are you using the WCAG settings vs the Section 508 ones. WCAG is a bit more less structured than 508.

Yes, I picked the WCAG 1,2,3 option.

...negative tab indexes (which are also illegal with HTML4.01Strict anyway)

Eh? Didn't know that. Presumably not a problem, though... Thanks very much for the rest of your info, too.

By the way: who's Crusty?

[deathshadow60]

[*]A keywords meta tag (which I wouldn't bother using, based on what I have read)

The keywords meta was greatly abused, so search engines silently put rules in place to ignore them in many cases... this led developers to believe that they are ignored outright -- my own experience with them tells me that the suggestion from SEOWorkers tool:

Professional Search Engine Optimization (SEO) Tools - SEO Workers

Is quite on the money in regards to keywords. 8 to 9 WORDS that have relevance to the actual content. It is NOT called "keyphrases", it is NOT called "keyparagraphs" -- it's Key WORDS. SINGLE WORDS that are in your CONTENT that are important. You keep it under 128 characters, using 9 or less words delimited by commas, with single words between those commas -- it still seems to be obeyed by most search engines. You vary from this, it might as well not even be in your code!

[*]A language meta tag (which is not valid HTML as far as I can see: it failed validation when I tried it)

This is one that pisses me off - and plays to the willy-nilly rules changes that seem to be going on for no good reason. There's no harm in including it (I'd be interested to see how a META, which has no rules about it's content, would fail to validate? Using that idiotic bloated half-assed HTML 5 nonsense or something?) and if I were to exclude it, I'd probably make sure I'm sending the HTML header value just to be sure. What 'harm' it does in including it is beyond me, and I had it drilled into me it was more reliable than the HTML lang / xml:lang bits. Now we're not supposed to use it? Whatever. A little consistency please? Since I'm NOT moving on to that bloated HTML 5 asshattery, I'll keep using the same heading that's worked JUST FINE for me over the past DECADE... thank you very much for nothing.

[*]The need for a logical tab order. It is already logical, but it implies that I should add tabindex attributes to all elements in the tab order, which is surely not necessary in practice?

Cynthia's a bit of a #DDD about that. I've never seen it say a single site has a "correct tab order". Frankly, if you have to resort to tabindex, there is probably something horrendously wrong with your source order.

[*]Keyboard shortcuts. I have read articles that suggest that accesskeys are probably better not used. My gut feeling says not to use them.

There's a lot of bad advice and mis-use of them -- this is why you get the dips out there saying "never use them" -- unfortunately that basically flushes keyboard navigation down the toilet, particularly on handhelds where it can make a huge difference in the usability of the page. After all, handheld is pretty much who it was made for. See Opera Mobile and Opera Mini's implementations!

I've gotten in the habit of making a "jumpto" menu, that is filled with accesskey links for internal navigation to the parts of my page. I hide it for my screen,projection,tv media targets, but allow it to be shown on handheld. (for the handful of handhelds that actually support it).

In Opera (desktop version is fine) open my crappy two year old and not updated personal page with the retrocomputing joke skin nobody gets the joke of...
Home - DEATHSHADOW PASCAL

... and hit shift-esc. Amazing what accesskeys and title attributes can do in browsers that actually try to support accessibility. Particularly handy if you enable the "small screen" rendering mode or strip away the CSS by switching style to "user mode".

IT's another of those "there's no harm in including it, and a lot of benefit" so I really fail to see the problem with it many so called "experts" out there kvetch about. Usually it's because they used them WRONG or had one minor conflict... At which point it ends up as bad as the "never ever use tables for anything" idiots. (see the people writing vBulletin 4 skins). Just because Trident, Gecko and Webkit based browsers are retards about supporting it, doesn't mean Opera, Blazer, SkyFire, Bolt, Teashark or any of the dozens of other mobile browsers are.... or that you shouldn't TRY.

Though really, those are minor points compared to the true accessibility bottlenecks of crappy undersized fixed metric (aka px) fonts, crappy fixed width layouts, illegible color contrasts, and a lack of semantic markup making things like screen readers harder to use. You address those issues and get a thumbs up on those, the rest is gravy.

[deathshadow60]

By the way: who's Crusty?

Hey, hey, hey...

She was referring to me.

[adh32]

Thanks, deathshadow. Lots of good no-nonsense info as usual.

I might have a go at adding accesskeys, then. Are there any good best-practice guides that you would trust?

[deathshadow60]

Thanks, deathshadow. Lots of good no-nonsense info as usual.

I might have a go at adding accesskeys, then. Are there any good best-practice guides that you would trust?

They're so simple to use, I don't believe any real 'guide' is neccessary. If it's something you think a user might want to navigate to quickly on your site (or in particular on your page) give it an accesskey. As a rule of thumb I like numbers for on-page and letters for on-site -- it's more useful on handhelds to have the numeric keypad navigate quickly to sections of the page.

It's also one of the few times I advocate using the title attribute -- since if you omit it on accesskeys the URL is shown on the menu instead of the anchor contents in Opera and the handheld browsers that support accesskeys menus.

See, usually the only reason to use the title attribute is if the content of the tag doesn't convey all the information needed -- at which point IMHO there's something wrong with the content of said tag. See why 99% of the time people use TITLE on anchors or images it's redundant/pointless.

There are some government agencies in various countries that have their own "standards" of using accesskeys -- I've generally found those standards to be useless/pointless... thankfully they're not official in any way shape or form outside said organizations.