I’ve been writing WordPress plug-ins for a while now — I launched my first plug-in a little more than 3 years ago. I’ve been involved in web site accessibility for about seven years. Naturally, when I started writing WordPress plug-ins, making them accessible was part of my goal. But accessible software extensions have two aspects: the interface, and the output: and I don’t have complete control over either.

Is it possible to make a plug-in with accessible output, guaranteed, every time? Is that compatible with a desire to provide flexible software which developers can use for a wide variety of possible needs from a design and functionality perspective?

What I’ve found is that I can unquestionably make a plug-in which is capable of creating accessible content. However, I’ve also discovered that in order to really make a plug-in flexible, it can’t have too rigid of an output: it needs to allow the user to customize the structure and content at a pretty significant level.

As a web site developer, this is certainly something I always want: whenever I find myself using a plug-in which doesn’t have built-in templating for the output, I can be pretty certain that I’ll be making edits to the core plug-in files. The HTML produced is rarely what I really want. My conclusion from this is that if I want to create plug-ins which will be used by sophisticated developers, then they need to be very, very flexible.

The downside to this, of course, is clear: if you can change the output, you can break it. As a result, every one of my plug-ins which creates web site output has equal potential to be accessible or inaccessible: and I can’t guarantee the results. Additionally, the core content of the site can only be as accessible as the theme surrounding it — so even if the plug-in is configured with my defaults, that doesn’t guarantee any particular level of accessibility.

I’ve had to accept that. But it does mean that I’m constantly seeing implementations of my plug-ins which, while well-done in general principle, just don’t meet my ultimate wishes for accessibility.

But I wouldn’t turn back. I’d like very much to be able to enforce accessibility; but realistically, I can’t do it. There are too many factors.

My User’s Guide to My Calendar includes a short section on the principles of Accessibility; hopefully, a few people will gain from that fact. The fact is that accessibility requires education: you can’t force accessibility on somebody by providing accessible software unless you also take total control over the look, feel, and function of that software, and that’s not the way the web works. With education, you can help move people towards making their own decision to support accessibility in how they customize their software; so that’s what I’m hoping for.

So, what does it mean to write an accessible plug-in for WordPress? I can’t control the administrative interface entirely; because the fundamental interface is the WordPress core, and I can’t just evade that. I can’t control the output, in either structure or design; and even if I could control what exists within the parameters of the plug-in’s output, I can’t control what surrounds it.

So an accessible plug-in is just a plug-in which is able to used accessibly; a plug-in which doesn’t actually implement a specific lack of accessibility. Somehow, that’s a little depressing, but you take what you can get.

The overall lesson to take from this is that no plug-in is actually going to give you an accessible web site. But hopefully, it’ll give the possibility of an accessible web site.

I’m a firm believer that the first step to creating effective accessible web sites is to understand the nature of disability. Learning all the technological elements which can affect that accessibility is also necessary, but if you don’t understand why you’re employing the technology, you’re far more likely to make simple but costly mistakes.

My latest article, 10 Common Developer Mistakes, published at Ecommerce Developer, covers examples of some of those still-common mistakes which are fundamentally the result of a failure to understand how other people perceive and interact with your product.

What makes a web site inaccessible is your fault: your web site is not inaccessible because your visitor has a disability, it’s inaccessible because you have placed barriers on the site. These barriers are caused by a failure to understand how other people perceive or interact differently from yourself.

A self-focused perception of the world can be very damaging to accessibility or to usability. It’s not that you can’t build a great and even successful web site while primarily thinking of yourself as the user; but your site’s ability to cope with the needs and expectations of other users is greatly reduced if you aren’t able to understand how other people will interact with your web site.

Steve Faulkner, from The Paciello Group, just announced the beta release of their new Accessibility Viewer application aViewer. The purpose of the application is to give easy access to what information the browser is reporting back through Accessibility APIs. It’s an interesting application, and certainly has the potential to provide useful information in the future.

It is in beta, of course, so it may not function entirely perfectly — in my installation, I had trouble getting a few features to work properly. I couldn’t get the cursor view to do anything at all, for example, nor could I get the cursor tool to turn on using F5, as the documentation describes. The Code view only seemed to show the text values for links — and nothing elsewhere. (For reference, this is on Windows Vista using Firefox 3.6.3.)

Nonetheless, I can see the potential for this software as a helpful tool for exploring both the accessibility of an interface and the awareness of a browser concerning that information. It’s a good idea, and with feedback is likely to become a useful tool, as well!

Steve is asking for feedback, so be sure to install this in your environment and take a look.

Authoring forms is an important part of keeping the web fully accessible — not just providing access to information, but allowing users to fully interact with the web in all it’s glory. Interactivity is what makes the web powerful and persuasive.

As such, I can’t help but be frustrated when I run across basic form construction which is simply well below the standards I’ve come to expect. A form like this one, for example, is incredibly irritating to my sense of what the web should be:

  <form action="/store/add_event_to_cart/53" autocomplete="off" method="post">    <table>
  <tr>
    <td nowrap><span class="required">First Name:</span></td>
    <td><input id="attendee_first_name" name="attendee[first_name]" size="40" type="text" value="" /></td>
  </tr>
  <tr>
    <td nowrap><span class="required">Last Name:</span></td>
 
    <td><input id="attendee_last_name" name="attendee[last_name]" size="40" type="text" value="" /></td>
  </tr>
 
...[numerous similar fields deleted to avoid boring the hell out of you]...
 
  <tr>
    <td colspan="2">&nbsp;</td>
  </tr>
  <tr>
    <td colspan="2">
 
      <input name="attendee[sponsor_email]" type="hidden" value="0" /><input checked="checked" id="attendee_sponsor_email" name="attendee[sponsor_email]" style="vertical-align: top;" type="checkbox" value="1" />
      <p style="display: inline-block; width: 360px;">Please sign me up to get occasional information from select sponsors, partners, and other fun people.</p>
    </td>
  </tr>
    <tr>
    <td colspan="2">Discount code (if applicable): <input autocomplete="off" id="attendee_discount_code" name="attendee[discount_code]" size="10" type="text" /></td>
  </tr>
    </table>
 
    <input name="commit" type="submit" value="Add Attendee" />
  </form>

But in this case, it’s not just the nature of the form itself. There’s a lot wrong here — the use of table for layout is a big problem, but even if you’re accepting the table as logical (and there is a particular logic which would except tables for forms,) the lack of a summary or headings in that table and the use of empty table cells to provide spacing is a big problem. Then we look at the form itself — not a label element in sight; instead we have plain text using a span and class to indicate if a field is required. There’s no coded indication that a field is required; it’s a purely visual indicator.

My sense of accessibility hurts.

And do you want to know where this code came from? Here it is.

Here are a few good articles on high quality form construction – but don’t bother reading them. After all, they didn’t.

• Sensible Forms
• Pretty Accessible Forms
• Making Compact Forms more Accessible

This is something that pisses me off; but you can find it everywhere. Large organizations responsible for web publishing don’t always maintain the standards they talk about. Is it just talk, then? Does the fact that An Event Apart does what A List Apart condemns mean following standards and implementing accessibility doesn’t mean anything?

Thankfully, no. It does mean that web sites aren’t perfect; and the people doing the labor are frequently not the people who know best how it should be done. But it is a problem — as much as we can evangelize best practices, it doesn’t mean that they’ll be used.

There’s a lot of pressure in the web industry to produce fast results. Sometimes this means people take shortcuts; sometimes it means hiring people who may not be as fully trained or qualified as you really wish you had; and sometimes it means things just go wrong.

But I’m left with a definite feeling of frustration to find that a leading web standards event like An Event Apart should exhibit this kind of HTML on their web site.

How can this be avoided?

Ooh, that’s a tough one. Work processes, new employees, insufficient testing — all of these can allow inferior code onto a site. As a freelance designer, it’s positively rare that I have sole control over new content or template changes after the initial launch. As a member of a team, I can only imagine that it’s even more difficult — anybody with sufficient permissions to commit a change can change the overall level of competency exhibited on the site.

Application of a tool like Marco Battilani’s Big Red Angry Text technique can help, but it’s a little scary to put into a published site if you know that the editing won’t always be done by knowledgeable people. It may demonstrate mistakes, but can sometimes serve to do nothing more than piss off or frustrate your client or staff. It depends on the control and education you’ve been able to impose.

1. Educate. Teach the people who will be doing work on the site as much as you can – the what and the why.
2. Review the site. Review the work that’s been done; a 30 second glance at the code is likely to result in fixing at least some errors, and will hopefully prevent future errors of the same type.
3. Provide tools for self-checking. Not a first choice, since all automated tools are flawed by their very nature, but they can still be of use.

It’s not always practical; but if following these steps is at all an option, it’s really worthwhile.

The United Kingdom-based Royal National Institute for Deaf People (RNID) recently produced a nice mini-site entitled “10 Things You Should Know About Web Accessibility.” For the most part, it’s excellent — a friendly voice, a casual approach, elegant presentation, and good information.

It does, however, intimate one of my pet peeves in documents promoting web accessibility:

Hey good lookin’

“But accessibility always compromises the design, doesn’t it?”

Wrong. Your site can still look beautiful.

This doesn’t precisely say that compromise is not required for accessibility; but it’s certainly implied by the language chosen.

To suggest that compromise is not required is simply a mis-representation of the truth about accessible web design: you do have to make compromises. Whether they’re compromises concerning how information is presented, the color contrast between elements, the specific uses of language or technology, you have to make compromises.

The perception seems to be that making compromises for accessibility means that you create an unattractive web site or otherwise decrease the aesthetic value of your web creation. This is not true: but it’s inaccurate to say that you don’t make compromises.

Truth: Effective accessible design has requirements which will require compromise in many areas.

It’s important to educate all participants in a web design project on accessibility before any serious work is done, to help prevent problems. If the designer knows to check contrast levels before proposing a design, they’ll start by creating an aesthetically elegant design with the color palette available. If they aren’t aware of these problems, you’ll end up making compromises on colors — and, without extensive modifications, it is entirely possible that these compromises could have a damaging effect on the aesthetics of the site.

Compromise shouldn’t damage aesthetics or accessibility: but poor planning almost certainly will.

There are, of course, a lot of color contrast evaluation tools available on the web. Roger Johansson published a list of 10 color contrast checking tools last September, and there are undoubtedly more out there yet.

In fact, for a long time, I’ve primarily used the three tools by Gez Lemon which are on that list:

• Color Contrast Analyzer
• Luminosity Contrast Ratio
• Color Contrast Analyzer Firefox Extension

I certainly have no intention to stop using the Firefox Extension, but I’ve been irritated by the other two tools for a long time for two reasons. First, the simple fact that there are two tools. Obviously, the first was written long before the second, but given that they are testing the same pieces of information, it would be nice to be able to conduct the test with a single test. The second is that the tools have rather poor usability: the original color contrast analyzer, at any rate, gives a lot of information and it can be rather difficult to pick out the key bits: the actual contrast between the items and whether or not you’ve passed or failed.

This tool I’ve just placed on the web (“released” is far too glorified for this) is purely intended to combine these two functions into one tool and to provide more readable output.

I haven’t checked the output as thoroughly as I might have; there may well be bugs. Let me know if you notice one!

No legal definitions established today, I’m afraid to say. Although this is a victory on behalf of the claimants, who were awarded substantive damages on their claim, there was no establishment of any kind of legal precedent.

This is primarily due to one singular item in the settlement:

2. No Admission of Liability. By agreeing to and voluntarily entering into this Agreement, there is no admission or concession by Target, direct or indirect, express or implied, that Target.com is in any way inaccessible or that Target has violated the Unruh Civil Rights Act, California Civil Code §§ 51 et seq., the Disabled Persons Act, California Civil Code §§ 54 et seq., the Americans with Disabilities Act, 42 U.S.C. §§ 12181 et seq., or any other federal, state, or local law, regulation, order, or rule.

National Federation of the Blind vs. Target Corporation, Final Settlement

This statement clearly delineates a complete denial that there were any contradictions of law involved in the Target.com suit.

Ah, well. It is still a victory!