A WCAG 2.0 Implementation Site

Posted March 11th, 2008 by Mike Cherim

Over the past month I made mention — twice — of a site I was creating that was specifically meant to serve as a practical example of what an accessible web site is supposed to be like and serve the needs of its owner. Since I don’t create anything but accessible sites as a rule, this project wasn’t really that different than any other project. Initially that was. At first it was a typical Web Content Accessibility Guidelines, WCAG 1.0 build, with a focus on meeting all of the priority 2 checkpoints, “AA,” but once word got out, the owner and some of those behind the WCAG 2.0 requested that I take it further.

I was asked to make the site officially conform to the WCAG 2.0 so it could be featured by the World Wide Web Consortium (W3C) as an exemplary implementation site conforming of the soon-to-be-finalized guidelines. I didn’t object; this would be great for my client, and it wouldn’t exactly hurt me either. Aside from the conformance protocols to be followed, it wasn’t much different than what existed up to that point. I just had a lot of reading to do to make sure nothing was missed and that I could write the optional claim according to the requirements.

Instead of meeting checkpoints I had “success criteria” to contend with, but accessibility is accessibility and the needs of users remain the same. I changed very little on the site (though I did make sure I applied extra polish). The biggest difference between the WCAG 1.0 (or the improved WCAG 1.0 Samurai Errata) and the WCAG 2.0 is how you achieve conformance. All have their limitations, none can guarantee accessibility to all users (regardless of conformance level), and all require the web developer to have a deeper understanding of web accessibility to really get in there and do it. It’s more than just meeting checkpoints.

That said, to the best of my knowledge this site meets all of the applicable success criteria required to bring it up to the “AAA” level — without having to fall back on any of the alternate themes. It isn’t stated as such on the site, though. It was decided to wait on this particular part of the claim until such a time, as determined by all investigating parties (you included), that the content still being added doesn’t break the any page’s conformance. This is your chance to comment on things you might find or have questions about (I can think of two things that might inspire a “find”). Your comments, in fact, will be welcome and read by some of the powers-that-be.

Okay, enough said, without further ado I would like to present the web site of The Law Office of Lainey Feingold, a Disability Rights Legal Advocacy. I hope you like it.

Special Thanks Goes To…

For the success of this project, special thanks goes to Jim Thatcher, Gregg Vanderheiden, Ben Caldwell, and Joshua Miele for their expert suggestions and insights, to Louis Libert for rolling up his sleeves when it came to adding content, and to Thierry Koblentz and Dave Woods for some CSS bug-tracking and screen shots, respectively.

I would also like to make mention that this site is built on the WordPress publishing platform and that with only a couple of core file modifications, it didn’t impede my ability to ensure the site’s accessibility. This is something the WordPress developers should be proud of. I do invite those developers to contact me should they have questions about what I found in need of attention. In addition to the platform itself, three visitor-side “plugins” were added and those creators should also be acknowledged: First there is Rich Pedley for his “Enhanced Pagination” plugin, Michael Wöhrer for his “Breadcrumb Navigation XT” plugin (modified), and me and Mike Jolley for our contact form plugin (also modified).

And last but not least, thank you, Lainey. I couldn’t have done it without you.

Added Note: According to Browsercam, the right-most of the upper block links drops below the list on Firefox 3.0b3 on various platforms like Windows 2000 and Mac OS 10.4 — also, on Internet Explorer 8b1, at an 800×600 resolution, the masthead overlaps the upper block links. Should I be concerned about either at this point?

Filed under Wicked Wild Web, Access Counts, WordPressing —

Bookmarking Links » del.icio.us | Digg | blogmarks | StumbleUpon | Technorati |

These posts may be related:
My WCAG 2.0 AAA Implementation »
The Best of the Beast in 2008 »
The Four Principles of Web Accessibility »

22 Responses to: “A WCAG 2.0 Implementation Site”

  1. Dan Schulz responds:
    Posted: March 11th, 2008 at 8:56 am →

    Mike, what changes to the plugins you mentioned (other than your GBCF of course) did you make?

  2. Mike Cherim responds:
    Posted: March 11th, 2008 at 9:35 am →

    Nothing significant, Dan. To the breadcrumb I just added some surrounding text and changed some of the fixed text within the plugin. Nothing that affected its accessibility, more or less just customization so it’d fit the site better. Example, if is_paged() AND is_home() OR is_archive() OR is_category() OR is_search() I added text after the current to show the user was exploring older entries. The form edits were significant (adding the stars, etc.). Most of the form changes have been added to the most recent build. One additional thing on the form was to compound the label for the anti-spam question to: 1) remove the second label; 2) put that text within the first label before the input.

  3. David Joseph responds:
    Posted: March 11th, 2008 at 5:29 pm →

    Mike, just to let you know in Firefox 3.0b4 on Win XP 1280×1024 (and 800×600) the whole page renders fine including alternate styles (I can screenshot if you like).

    ps. nice

  4. Mike Cherim responds:
    Posted: March 11th, 2008 at 6:00 pm →

    Thanks a bunch, David. That’s a relief. Guess that goes to show that Browsercam cannot be fully trusted. I did some screens on that site with a large monitor size and half the captures were in windows that weren’t maximized (making the captures completely irrelevant). Hopefully I’ll get the same feedback for IE8 [shudders at the thought]. Thanks again!

  5. Lea de Groot responds:
    Posted: March 11th, 2008 at 8:51 pm →

    Because IE8 is a pre-beta, I wouldn’t worry about making things work in it - what you ‘fix’ may change in the next version. :)
    Test to see if your site looks ok, feel good if it did and if you spot anything that you think means the browser is blowing it (check your markup and css to check its not an an… interesting implementation on the site first - easy to do :( ) , send in some feedback at http://blogs.msdn.com/ie/archive/2008/03/05/ie8-beta-feedback.aspx (I think)

  6. Mike Cherim responds:
    Posted: March 11th, 2008 at 9:27 pm →

    Because IE8 is a pre-beta, I wouldn’t worry about making things work in it - what you ‘fix’ may change in the next version.

    Thanks Lea. I made that mistake with IE7 and regretted it. Ended up having to do work that didn’t need attention because by the time the first release candidate came out the issues were no longer of concern anyway. Thanks for the link. Once I can get confirmation of the issue and a better handle of what is wrong I will definitely report it.

  7. John Faulds responds:
    Posted: March 12th, 2008 at 12:50 am →

    What does the tabindex=”0″ do?

  8. Mike Cherim responds:
    Posted: March 12th, 2008 at 1:50 am →

    What does the tabindex=”0″ do?

    Nothing. You’re seeing that in the form but I added tabindex attributes to the plugin so that it can be configured/specified by the plugin user, just in case. The default is zero which has no affect so it didn’t bother me. I should have done it differently: IF zero, remove the attribute.

  9. John Faulds responds:
    Posted: March 12th, 2008 at 2:43 am →

    Isn’t there a danger with letting plugin users (who may not be as fully aware of the issues) set tabindex on elements that they might actually create more problems than they solve? Is there any need for it at all in a form like the contact form on the site which is laid out as you’d want to move through it anyway?

  10. Robert Wellock responds:
    Posted: March 12th, 2008 at 8:11 am →

    Why does the “example” site make use of the presentational element SMALL; its use is discouraged, because the element has no semantic meaning.

  11. Mel Pedley responds:
    Posted: March 12th, 2008 at 8:37 am →

    @Mike: What (if any) areas of WCAG 2.0 gave you pause for thought? Technical or non-technical?

    From what you’ve already said, the final site may not vary greatly from a site that you’d designed to conform to most WCAG 1.0 AAA checkpoints. That bears out the general impression I’m getting with regard to WCAG 2.0. But I am interested in any real differences when trying to interpret the two documents. The former, presumably in an attempt to clarify areas, did tend to lend itself towards a “just tick the boxes” mentality - which wasn’t exactly helpful at times. WCAG 2.0 seems to be deliberately drafted to take developers away from such a binary approach - which could be a Good Thing(tm) but may inadvertently lead to even less developer enthusiasm and more inadvertent “mistakes”.

    Having now sat down and applied WCAG 2.0 to a practical project, what’s your take on this?

  12. Mike Cherim responds:
    Posted: March 12th, 2008 at 8:44 am →

    @John:

    Isn’t there a danger with letting plugin users (who may not be as fully aware of the issues) set tabindex on elements that they might actually create more problems than they solve?

    There is indeed. That’s why the version 3 of my form didn’t even go there. It caused more harm than good on some sites what with allowing users to set them.

    @Robert:

    Why does the “example” site make use of the presentational element SMALL; its use is discouraged, because the element has no semantic meaning.

    I don’t think of its use as something discouraged outside of a certain set of developers at least moving forward. It’s in HTML 5 so it’s not being deprecated, none of the inspectors at W3C brought it up as an issue, and its semantic value, again moving forward with HTML 5 thinking, is that it is meant for small print/side text (unlike a span and no longer a style element). Granted that’s not much of a value, but it does physically de-emphasize plain text (without removing emphasis or importance to text so-marked with those elements, though).

    When I use something like that I look with styles off and decide whether it should be smaller/by way of an automatic and permanent reduction in the percentage text size. In those cases I felt its use was appropriate.

  13. Mel Pedley responds:
    Posted: March 12th, 2008 at 8:55 am →

    @Robert Wellock : small is described in the specs in terms of font/text rendering but I’m not sure I completely agree that this is its only usage. I’ve always seen it has having a clear semantic meaning too - the markup equivalent of a play script’s “aside” or “extra comment” for want of a better description - that is definitely not limited to visual presentation. It reduces the semantic emphasis on the text it contains but only in relation to the enclosing block level element. So small text within an H1 block will have much greater emphasis/weight than normal text within a p block. But, equally importantly, the same text may not be a suitable candidate for H2 as it does not define or summarise the text that follows in the context of a sub-header.

    As I see it, it’s all about providing the potential for a richer experience irrespective of the user agent. Otherwise we might as well just stick to H and p tags all of the time - which would make for a valid but pretty boring user experience. In an ideal world, I’d like to see (hear?) screen readers implement small by a change in tone, voice or volume. However, if/how non-graphical user agents interpret small is beyond our control. All we can do is offer the potential.

  14. Mike Cherim responds:
    Posted: March 12th, 2008 at 9:39 am →

    @Mel:

    What (if any) areas of WCAG 2.0 gave you pause for thought? Technical or non-technical?

    I must admit I like the way its organized, seemingly convoluted at first, but once the order and structure is understood it’s not bad getting through it. The first run/first page is hardest, and it must be understood to properly claim it. Though I did make several suggestions to Gregg about issues I had reading the document. Some small changes, including a few CSS changes would make the thing easier to read and digest. Hopefully my suggestions will be implemented. After about 8 hours of reading (the original claim, stored by the owner presently, took me about 16 hours to create) I realized it is a more honest approach being that each page is taken unto itself, if done properly. In the distant future, the best, most accessible sites, probably won’t create the optional conformance statement — they’re just create a highly accessible site.

    Twice I emphasized “properly” in the paragraph above. That was intentional because the possibly of abuse and false or misleading claims seems like it might be higher or more prevalent with WCAG 2 (this remains to be seen). The part that makes it more honest (claiming a page at a time), is the part that might be abused the most. For example, a fictional Scumbag Corporation may create a 2,000 page, grossly inaccessible web site. If they add a conformance statement link to their footer as I did, and they can honestly claim one accessible page, it could be misleading to anyone who might come to the site. Unless the claim is done very honestly and very clearly, the blissfully unaware might come away with the impression the site is more accessible than it really is. The reason is the WCAG 2 allows developers to disclaim pages, series of pages, and whole sections if need be. That’s all fine and good if done on an accessible site, with maybe a page or two in a shop checkout series or something disclaimed (the whole series would have to be disclaimed if one page is off), but if done in the opposite manner, no good will come from it.

    But you know what, as I learned after discussing this with Gregg to some length, it’s not so much the fault of the spec, its really legislation and enforcement. If the law properly supports the WCAG 2, then it’ll be great. A nice, honest approach. As noted, conformance doesn’t guarantee accessibility to all, this information is what needs to be presented to and understood by both developer and visitor.

    I will say this: If someone is getting into accessibility by way of the WCAG 2 as their front door, who doesn’t already have a good handle on the WCAG 1 (or better, a firm grasp of UAs/ATs/Usability/Semantics), is in for a long ride. In other words, if someone’s introduction into accessibility is by way of the WCAG 2, they will have a lot of reading, too much perhaps, and it will be a long and bumpy journey. Thankfully blog articles will ease the transition/introduction to some of these folks.

    The biggest thing I walked away with on this project is all the feedback I got from blind users. Not to make a pun, but it was a real eye-opener for me. This topic will be a future article.

  15. John Faulds responds:
    Posted: March 12th, 2008 at 6:15 pm →

    Accessibility has a hard enough time being taken on as it is under WCAG 1.0. Surely raising the bar to entry even further is only going to discourage further take-up?

  16. Mike Cherim responds:
    Posted: March 12th, 2008 at 6:25 pm →

    Surely raising the bar to entry even further is only going to discourage further take-up?

    That could very well be an unwanted side-effect, John. We’ll have to see. The powers-that-be will be publishing a transition from WCAG 1 to WCAG 2 document pretty soon. Maybe that offer a concise boost to help ease adoption.

  17. Robert Wellock responds:
    Posted: March 13th, 2008 at 7:18 am →

    Well, I was just interested about the SMALL Inline Presentational element usage and making sure it wasn’t going cause confusion - to others - as I am are sure it often gets misused like the I although in rare cases they are justified like you mentioned.

    Aside it’ll be entertaining when HTML 5 actually appears since they have some widely-different interpretations of already previously defined elements.

    The only thing on casual inspection that some disagree with - not meaning myself - is the use of asterisk but overall it seems like a good job. :D

  18. Mike Cherim responds:
    Posted: March 13th, 2008 at 9:26 am →

    The only thing on casual inspection that some disagree with - not meaning myself - is the use of asterisk but overall it seems like a good job.

    Thanks Robert. You’ll be interested to note that the asterisks were added upon the request of Josh Miele, an experienced Jaws user. He said adding them to the form will make the form a lot more accessible to him. I learned an awful lot of things like that as it pertains to forms and other screen reader users. It will be the source of an up-and-coming article.

    As they say on TV: Don’t touch that remote, we’ll be right back after these messages :)

  19. Robert Wellock responds:
    Posted: March 13th, 2008 at 3:40 pm →

    Some camps say they are bad and that textual representation is a must due to internalization, etc. Though it is an in interesting one - I’ll let you rest now. ;)

  20. Gill responds:
    Posted: March 15th, 2008 at 9:43 pm →

    Very nice Mike. I haven’t even started to look at WCAG2 in any detail yet so you can be sure your brain will get well and truly picked.

    The only thing I could find that was a possible issue, and believe me I looked, is that the links are a little pale when run through Vischeck. The orangey colour comes out as pale grey.

  21. eharmonyblog responds:
    Posted: April 3rd, 2008 at 1:07 pm →

    You posted a note in the WordPress Support forum http://wordpress.org/support/topic/161126 inviting questions. So yes I have a question: are you sharing the theme files to the public?

  22. Mike Cherim responds:
    Posted: April 3rd, 2008 at 1:15 pm →

    I do offer two accessible themes (see my sidebar), but I don’t plan to release this one as a free theme. Too much work to give it away.

Sorry. Comments are closed.

Note: This is the end of the usable page. The image(s) below are preloaded for performance only.