A WCAG 2.0 Implementation Site

Posted March 11th, 2008 by Mike Cherim

Over the past month I made mentiontwice — 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?

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. 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

  3. 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)

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

    What does the tabindex=”0″ do?

  5. 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?

  6. 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.

  7. 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?

  8. 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.

  9. 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?

  10. 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

  11. 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. ;)

  12. 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.

  13. 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?

Sorry. Comments are closed.

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