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.

Search engines and humans are always looking for relevance. When we first open a document on the web (or in our mail), one of our first actions is frequently to determine whether this document is relevant to our needs. In the case of e-mail or physical mail, this is entirely a “push” experience — messages are sent to us, and we evaluate them for relevance. Spam survives largely on that obscure edge case where we identify their messages as relevant.

When it comes to web documents, the experience is more of an even exchange: we provide search engines with instructions about what we want to find and they send back a response which we both hope will meet our concept of relevance for the given instructions.

Sales and conversions are driven by relevance.

But humans and computers perceive information and relevance in very different ways. This is a challenge for search engines, which need to be tuned to fetch information which appears relevant to a human searcher on the basis of a computer’s understanding of the document. This is also a challenge for people with disabilities — while a person with a disability will generally have the human ability to perceive relevance, their perception of information on the web may be filtered through a computer. For a person who requires the use of a screen reader, this filtering amounts to receiving only the facets of information which are made available both by the author of the document and by the assistive technology they are using.

So, in any online search for information, a person with disabilities is encountering three primary barriers to finding relevant information:

• Did the author consider their needs when the document was created?
• Does their assistive technology offer the resources to transfer that information?
• Did the search engine return information which will be considered relevant to a human?

Everybody encounters the flaws in search engine results. Although searching is far more sophisticated than it was just a few years ago, it is still limited. (And appears to be getting more and more subject to the filter bubble effect — though that’s a different subject.)

Some words have multiple meanings, which are dependent on context. We all use context to guess these meanings: humans use tone of voice, facial gestures, body language, location, environment, and many other factors to assess what the probable meaning of a word may be. Search engines have limited access to this information — some information is mechanically detectable; such as location, and to some degree, environment. They know what words you used to search, and they may know what else you’ve recently searched for. They can use this information to try and better assess your intent and deliver the most relevant information to you.

When it comes down to what information is on a web document, search engines and screen readers have very similar information. As a result, search engines and users of screen readers have similar limitations in their ability to quickly identify relevance on those documents. In some ways, search engines have an advantage, since they can absorb all of the information on the page far more quickly than any human can.

Where a search engine might simply absorb an entire page and move on, humans scan. A visual user will quickly glance over the page, identifying images, headlines, navigation elements, and noticing a few key words along the way down the page. That quick scan of the page can frequently provide all the information the user needs to decide the document deserves another look, or is clearly irrelevant.

Users with disabilities also scan, when it’s an option. This is a place where the capabilities of assistive technology and the attentiveness of a web author really come into play.

For a screen reader user, it’s clear that there won’t be any quick scan of images. Although images may have supporting alt attributes, it wouldn’t be any real savings of effort to check. They can scan through descriptive link text, accessible navigation, and headings, however — if they’ve been provided in a useful fashion. Repetitive link text, headings replaced with images without alt attributes or an inaccessible font replacement method, any of the multitude of inaccessible navigation techniques: they may not prevent the user from getting at your content, but they will absolutely prevent the user from being able to get an overview of the content by scanning.

I mentioned above that search engines have some degree of advantage due to their speed of information absorption. The slower speed with which humans absorb information means that where a search engine might find great relevance caused by repetition of key phrases (or it might not — I would call that keyword stuffing, myself); a human will instead be overwhelmed by the same repetition.

This comes back to context. A human visitor to your web site doesn’t care at all how many times you’ve stated ‘blue widgets’, unless it’s less than once. From our perspective, if you said at the top of the page that you’re selling blue widgets, we understand that everything from that point on is in the context of a blue widget. If you actually say, over and over again, that we’re reading the blue widget specifications, and the pricing on blue widget shipping, and that your blue widget support is superlative — we’re just going to get overwhelmed. It’s unnecessary, and creates the sense of what I’m choosing to call “information blur” (the effect when information is lost due to excessive adjectival description).

What’s my point, again?

Relevance is a prime factor in converting a web visitor into a paying customer. However, humans and computers perceive relevance using very different factors. The best performing web site is going to be created according to the compromise rules which will provide the most relevant information to both humans and to search engines. Visitors with assistive technology, and particularly screen readers, are an interesting test case in this scenario, because the information they receive is filtered in a similar manner to that which a search engine will see.

Creating accessible content: it’s not just the right thing to do.

Jane Wells, the WordPress user interface lead, posted a call for accessibility reviewers for WordPress 3.2 and the new Twenty Eleven theme. I would dearly love to help with this, but in all practicality I don’t think I can commit to it right now. However, I hope that if there’s anybody out there with a good handle on accessibility issues and a little extra time they’ll volunteer to provide their thoughts!

WordPress has demonstrated an interest in accessibility, but they need your help!

If you’re interested, Jane has asked for names and information to sign up (although, so far, it seems like most people have just gone ahead and started making comments directly.)

Show your interest here: Make WordPress Accessible

Keep in mind, please, that the WordPress development team are asking for help, not criticism. They are asking for help because they know that they aren’t accessibility experts — keep the tone constructive! WordPress is a great application — and from the vantage point of making the web more accessible, making such a popular and widespread application as accessible as possible would be huge progress.

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.

I’ve always believed that web site accessibility depends on an understanding of accessibility issues — not on technical issues. Obviously, knowing the technical side of web site construction and how it impacts accessibility is very important. Some decisions are fundamentally technical, but a huge part of web site accessibility is purely visible — and just understanding accessibility issues will make a huge difference.

To that end, here are a few quick comments about color blindness. Color blindness (or color perception deficiency) is an issue for approximately 1 in 12 people, mostly men. However, color perception problems are not always very effectively diagnosed, so these numbers could be low.

Color blindness is an inability to see certain colors.

Color blindness is really a misnomer. People with various types of color blindness are better described as being color vision deficient: it’s an inability to distinguish colors, not an inability to see color. People at the furthest limits of color deficiency, however, may have such an extreme inability to discern colors that this can be a fairly accurate description.

Individuals with color vision deficiencies can’t see red.

Well, no. Assuming we’re discussing Protanopic or Deuteranopic color blindness, in which the individual is missing either the red or green sensitive cones, the actual problem is that they may not be able to distinguish the color red. The color isn’t readily differentiated from other hues of the same shade or tint. Red perception deficiency is certainly the most common type of color vision deficiency, but it’s certainly not true of all individuals with poor color vision.

You have normal color vision

Not really. In fact, color perception is a spectrum for all of us. What’s commonly referred to as color blindness is actually only the portion of that spectrum which is considered anomalous — where the ability to perceive color begins to impinge on normal interactions with the world. Having “normal” color vision simply means that you don’t generally experience problems because of your color vision. You may well still fail an Ishihara test.

Color perception deficiencies are inconvenient, but don’t pose any serious problems

Particularly in our modern, technological society, color perception is a critical part of comprehending the world around you. From LED indicators which blink red, green, or yellow; to weather maps which a spectrum from red to green indicating storm severity; to knowing what color a traffic signal is showing if you’re in a location with a different signal orientation than what you’re familiar with. Outside of technology, color deficiencies can impact recognizing that you’re developing a severe sunburn or knowing whether you’ve actually cooked that hamburger enough to be safe.

People with Color Perception Deficiency have better Night Vision

Actually, I couldn’t definitely verify this one way or the other. There are a number of claims that this is true, but the reasoning is highly variable and not particularly evidence-based. It’s possible that certain types of color perception deficiency may give people better night vision, but it’s also possible that since some types of color perception deficiencies cause people to be photosensitive, those people may feel like their night vision is better, simply because it’s much better than what they’re accustomed to. Regardless, any evidence which is reasonably definitive would be appreciated.

Additional Resources

• Vision Simulator
• Colour Blindness on the Web isn’t a big deal

Section 508 web accessibility standards were written as an amendment to the Rehabilitation Act in 1998. In web development terms, this isn’t short of an eternity — and in all practical sense defines an era. The web programming methods and styles of 1998 were radically different to what you see in normal use today. The Section 508 rules have been under revision recently, and were available for public comment until June 21, 2010. Unfortunately, my time didn’t allow me to take a look at these prior to the expiration of the public comment period — but that doesn’t lessen the importance of examining the revisions.

To help explain these changes in Federal web accessibility standards, I’m going to look at three specific questions. These questions will hopefully answer some of the questions concerning what’s coming up:

1. Has this changed anything about who must follow Section 508 guidelines?
2. What has been the primary reference for changes to Section 508 rules?
3. What are the specific changes to the Section 508 documents?

Has this changed anything about who must follow Section 508 guidelines?

No. The section 508 rules still exist under the same body of law — this is not a revision of the application of the law, it’s only a revision of the methods which are acceptable in following the law. Section 508 continues to apply only to Federal departments or agencies or entities providing services or products to Federal agencies. Further, it only applies to the specific services or products provided by those contracted entities, not to any external presence or non-Federally funded projects.

What has been the primary reference for changes to Section 508 rules?

Based on the document guidelines and on references made in the updated document, it seems that the primary reference was the Web Content Accessibility Guidelines, Version 2.0, as created by the World Wide Web Consortium. In fact, there is a specific section referring to WCAG harmonization, which indicates that web pages as defined under WCAG 2.0 which are conformant to Level AA will be considered to be in conformance with Section 508 (with a few elaborations on additional requirements.)

This is an excellent change, since it explicitly states a subset of requirements which need to be reviewed in addition to WCAG 2.0, Level AA requirements. From a consulting perspective, this simplifies the process: you can review WCAG 2.0 requirements, then check the additional requirements under Section 508.

The additional requirements are fairly straightforward. A significant percentage of them relate explicitly to video accessibility — an area which WCAG 2.0 frequently describes as Level AAA requirements. It seems clear that the Section 508 review group was concerned about the use of video in government communications, and wanted to be sure to avoid a situation where creating a video would allow Federal agencies to ignore Section 508 requirements — which is certainly a wise concern.

What are the specific changes to the Section 508 documents?

To work through all of the specific changes would be a Herculean labor — and I’m not prepared to undertake it right this moment. I’m not sure an article is the right place to do this, in fact. A permanent document demonstrating the changes may be more valuable, in the long run. Suffice it to say that the basic fundamentals of Section 508 have been updated to reflect the changes between versions 1.0 and 2.0 of the Web Content Accessibility Guidelines. The requirements which are beyond the specific conformance expectations of WCAG 2.0, Level AA are worth elaborating on, however!

Chapter 4, section 409: User Preferences. This section explicitly requires that applications allow users to set preferences for color, contrast, font type, size, and focus cursor. Thankfully, the rule is clearly written when it comes to development which is operated within a web browser: web browsers, as platforms which take some settings from an underlying platform, are expected to allow the underlying platform’s settings for these issues to take precedence.

To clarify this in simple terms: web browsers, or applications running within web browsers should not over-ride settings from the operating system.

Chapter 4, section 413: Authoring Tools. Essentially, this is an extension of the web authoring tool accessibility guidelines applied within Section 508. What it requires is that any tool which is used to author content or create documents — such as Microsoft Word, as a desktop application, or as WordPress, as a web-based content authoring tool — must allow the creation of accessible documents (such as by allowing the creation of alt attributes for images) and must not by default remove any accessibility feature — such as a video editing tool which would remove captions if editing a captioned video.

The section seems very reasonably written — it requires prompts for creating conforming documents, but also specifies that not every element should be prompted, as this can decrease usability.

Chapter 6, section 604, part 4: Real-Time Video. Live, streaming video must include real-time video description, with certain exceptions. This seems pretty explicit, and definitely is a valuable addition for people with disabilities. The exception provides for an exclusion for primarily visual and unattended situations. The example provided is a web camera overlooking a national park — it is purely visual, and there is little to no significant information to be gained from live video description.

Chapter 6, section 604, part 5: Multiple Visual Areas of Focus. When a video contains multiple areas of focus — such as a news program which also includes scrolling event notices beneath the main program — video description must be provided for all areas of focus. The provision suggests a couple of methods for accomplishing this, including divided audio tracks between left and right channels. It’s an interesting area to address. I can certainly see that this requirement can open up new areas of information availability to people with disabilities, but I can also see a number of potential problems in implementation. However, that is a question for another time!

Chapter 6, section 607: User Controls for Captions and Video Description. User controls must meet certain standards for accessibility functionality: in addition to the requirement that controls for closed captions or video description need to be present, they must also be present in the same context as other controls. It is not an acceptable option to hide controls for closed captions or video description in a corner — they should appear in contexts which have a similar prominence to other controls such as channel selection or volume adjustment.

Chapter 6, section 608: Audio Track and Volume Control. Essentially, media players must provide users an ability to isolate speech tracks and background sounds. This is obviously dependent on video production in order to function; as such, this section indicates that any videos produced must be produced with separate speech and background audio tracks, in addition to requiring that players must offer controls to separately adjust these tracks.

This clause seems to have some flaws to me — specifically, in the gross generality of “background audio” versus “speech.” Stating “speech” is very explicit, as it only refers to spoken text. However, in practical terms, there are actually three important bands of audio in synchonized media: background audio which is non-referential (music and some background sound effects), audio which is referential (some background sound effects: a knock at the door or other sound which is reacted to by the video), and speech. It can create a great deal of confusion to exclude those key sound effects from the speech track. The issue is closely related to issues with captioning and video description: it’s important to note certain sound events, since some conversations or events will lose meaning if the viewer is unaware of relevant background sounds.

On the whole, in my relatively brief examination of the updates to Section 508 standards, I’m happy with the results. Obviously, there’s always room for improvement — there’s still room for improvement in WCAG 2.0, which Section 508 could have changed — but I’d rather have a single set of base standards to reference than requirements which contradict each other! Working with standards isn’t the answer to every accessibility quandary, but you should never just ignore standards out of ignorance — instead, ignore them out of an educated disagreement.

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.