The Wcag Samurai Errata (joe Clark), NOT The Seven Samurai (Akira Kurosawa) Options

[iamlost]

Via Roger Johansson's blog, 456 Berea St, a post that Joe Clark et al have finally published their promised WCAG Samurai Errata.

Have skimmed it and am now settling in for in depth analysis.
My head hurts already

This post has been edited by iamlost: Jun 8 2007, 08:05 PM

[bragadocchio]

I have to make my way through it, too.

But I have to state that the idea of trying to use plain English is a mighty plus in favor of the Samurai Errata.

And I see that they also incorporated a liberal dose of common sense in a lot of these, too.

[joedolson]

I've already read through it and written up my thoughts.

The peer reviews are, if anything, even more worth reading than the original document. The clarity of the writing is something which I think is of a huge benefit to the accessibility community - hopefully, making interpretation of the WCAG 1 guidelines less of a burden to people first being introduced to the principles of accessibility.

On a related topic, Joe has also announced today that he's retiring from the web accessibility realm. Not sure exactly what that means for WCAG Samurai - presumably, he intends to help finish the Errata, but it's not clear whether the extensions to WCAG 1 which were originally part of the intent will also get done.

It is, of course, also completely unknown who is actually a member of WCAG Samurai - it may not at all require Joe's involvement to get finished.

[bwelford]

Joe, I have to take my hat off to you.


You really have mastered this area and like many other areas in website design it's very complex. Reading your post and the associated links was a real learning experience. Thanks for that.

[joedolson]

You really have mastered this area and like many other areas in website design it's very complex. Reading your post and the associated links was a real learning experience. Thanks for that.

Thanks! I don't know about "mastered"... "journeyman'ed," perhaps...

There's always more to learn!

[cre8pc]

Why do you suppose they'd want to not recommend consistency? I'm not understanding the logic of that.

[iamlost]

WCAG:

14.3 Create a style of presentation that is consistent across pages. [Priority 3]

Samurai:

Guideline 14.3: You may use any accessible "style" you wish, including styles that are not "consistent."

Note the flexibility of the Samurai "may use any accessible style" and the rigidity of WCAG 1.0 14 "create a style of presentation that is consistent".

Samurai are leaving open the option of varying design and page layout, the WCAG are not. Being consistent may be best, or not. Let the circumstance dictate best practice.

I see this as a major thrust of the errata:

We see no accessibility benefit in requiring only a certain markup among several viable choices.

[joedolson]

Samurai are leaving open the option of varying design and page layout, the WCAG are not. Being consistent may be best, or not. Let the circumstance dictate best practice.

I think that in general this is true. In general, the WCAG Samurai leaves many choices up to the developer and that's for the best. On this particular point, however, what they seem to have said (as separate from what they may have intended to say), is that a site does not need to be consistent in order to be considered accessible.

In short, it seems to be taking an pproach to accessibility where each element of a page on a site is judged on it's own independent merits. If you've marked up an acronym in a reasonably accessible manner in one place, and used a completely separate technique to mark it up accessibly elsewhere, that's fine.

Now, to a certain extent, I think that's true: you do not need to mark things up identically every time in order to achieve accessibility. However, the way the item is stated lit eaves your options open to using different markup and design decisions on every page. This will leave your pages individually accessible, but can leave your site practically unusable.

Perhaps they consider usability to be a separate issue, which is fair --- nonetheless, I think that although the intent may be reasonable, the specific wording is flawed.

[SEOigloo]

Do not provide a sitemap or table of contents unless the site cannot be understood or navigated without it.

What????



Can anyone shed some light on this one for me? It's in contrast to everything I've ever heard, learned, said, etc.

Worried...
Miriam

[yannis]

Miriam

I guess from an Accessibility point of view a long list of links, such as in an sitemap index is always a problem as you could imagine yourself listening to a an index (although a jump link could be ok). I also think the basic premise here is create such a compelling navigation structure that there is no need for a sitemap.


Yannis

[joedolson]

First, there's the aim of WCAG Samurai to enable web developers to make decisions about whether a site map is necessary, rather than simply requiring it. Small sites are not benefited from a site map: when there are only five content pages, adding a sixth simply to contain a site map is a waste of effort, and simply creates noise in the site navigation.

I think they want to force developers to think practically rather than thinking in a "checklist" format. Instead of saying to yourself "do I have a site map," you should be thinking "do I NEED a site map."

In many cases, it will be necessary. However, if it's not helpful; they suggest you should absolutely NOT incorporate it.

[iamlost]

joedolson: in your thoughts (nice commentary ) you make a passing reference to "there is sometimes a value" in <noscript>. Having read several similar comments and finding fence straddling rather painful I decided to research the logic behind no to <noscript>.

From my reading it appears Joe Clark believes (1) that scripting has evolved since WCAG 1.0 (05 May 1999) and (2) that developers need to interpret the intent of the guidelines within the current context.

He suggested a year or so ago: "use JavaScript correctly ... and ignore <noscript> the way you ignore <noframes>.", i.e. not use noscript as we do not use frames.

The point being, I believe, that a site should start with valid pages that work without JavaScript then, if desired, use the JS for enhancement you know will degrade well. Seems reasonable.

There appears to be growing support for non-scripting alternatives other than <noscript> due to user agents, including popular screenreaders, exhibiting greater support for 'progressive enhancement' than for <noscript>.

Remember that <noscript> only tests if scripting is available not what is supported, i.e. screenreaders that understand JS but fail to report dynamic change in an AJAX application will not get a <noscript> message.

The accessibility message being, as usual, to make the basic display the default and the jazzy interface an alternative enhancement. Rather than the usual razzle-dazzle needing half-assed 'hacks-for-gimps' tacked on as an after thought. Accessibility is such a back-asswards discipline compared to the marketing bandwagon.

Here is an iconoclastic idea: initially design your site, page, or application without JS then allow handlers and their enhanced functionalities to be added only as and when the user chooses.

Bumper sticker? Tee shirt?
NO <NOSCRIPT>

I think I fell off the fence.

[SEOigloo]

Thanks, Joe & Yannis, regarding the sitemap. This is interesting.
Miriam

[bwelford]

.. wakes up with a start ..

What! No site map. But I always encourage a small inconspicuous text link in the footer to the Sitemap page just for the search engines.

Wait a minute. Haven't I been uploading sitemap.xml.gz for all my websites since this is the way to get the search engines attention.

When I wake up, I'll have to do some pruning.

.. goes back to sleep.

[joedolson]

The point being, I believe, that a site should start with valid pages that work without JavaScript then, if desired, use the JS for enhancement you know will degrade well. Seems reasonable.

And I generally agree with him. However, the idea of completely banning the <noscript> element is not the ideal solution, in my opinion. What the <noscript> element is intended to do is deliver content when JavaScript is disabled. What is has commonly been used for is to deliver equivalent functionality or information when JavaScript is disabled.

I firmly believe that JavaScript should degrade gracefully; all functions should deliver the same capabilities with and without scripting. However, I _also_ believe that notification should be provided to the user when scripting is disabled. Not all users will be in control of whether JavaScript functionality is available; and some users may not be aware that they have scripting disabled. (Or, in my case, they may have forgotten they disabled it during testing...)

I know that <noscript> isn't infallible, since it can be stripped by some corporate firewalls, etc., but I still think that the means to easily provide notification that additional interface tools may be available with scripting enabled is valuable.

I'm not going to defend this to the death, however...

[sebastienbillard]

I am translating the introduction to WCAG Samurai Errata in french, but I have difficulties to understand "boilerplate content", what does that mean ? alternative content ? generic content like "u don't have javascript yada yada yada" ?

[projectphp]

Isn't the idea to NOT build sites to degrade, but to build them up? i.e. rather than build a site that doesn't work without JS, and hhacking on <noiscript> functionality, build something that works WITHOUT JS, and add in the JS at runtime for better browsers.

That is my take on the issue, anyway

[joedolson]

I am translating the introduction to WCAG Samurai Errata in french, but I have difficulties to understand "boilerplate content", what does that mean ? alternative content ? generic content like "u don't have javascript yada yada yada" ?

Yep, generic content - you've got it.

Isn't the idea to NOT build sites to degrade, but to build them up? i.e. rather than build a site that doesn't work without JS, and hhacking on <noiscript> functionality, build something that works WITHOUT JS, and add in the JS at runtime for better browsers.

That's certainly the preferred idea - progressive enhancement rather than graceful degradation.

However, if somebody had javascript off (unaware of this perhaps?) don't you think it would be reasonable to use the <noscript> element to provide some kind of notice that this is the case? It may not be a question of "pure" functionality: the core functions of the site may work just fine with JavaScript disabled, but there's still a question of ease of use, which can sometimes be improved with scripting. I don't think it's unreasonable to provide a method to deliver a basic piece of information like that. If you're in a controlled environment where you can't browse with scripting on, you will be made aware that your experience might be better (or at least different) if you try it at home. If you've unwittingly turned JavaScript off, you might be made aware of it.

I won't deny that I don't _actually_ use the <noscript> element very frequently (of course, I use javascript very infrequently, as well) - I'm simply opposed to the idea of banning the use of the element.

[iamlost]

Isn't the idea to NOT build sites to degrade, but to build them up?

Absolutely.

Kim recently blogged on How to Make AJAX Techniques Safe for Search Engines.

She naturally linked to this thread Cross pollination is a wonderful thing.

And via an intermediary link to Hijax: Progressive Enhancement with Ajax which, for those of you unfamiliar with Hijax, is really really worth reading.