Somebody recently contacted me with a fundamental question: they were undertaking an accessibility audit, and didn’t know how to structure the process. They knew web accessibility well enough — but from the perspective of setting out to perform an audit, they weren’t sure where to go.

As a result, I’m putting together this article to talk a little about how to structure an accessibility review, in all the practical ways — how you address coming up with a quote or estimate, ways to structure your research and site inspection process, and dealing with long-term follow-up.

• Specify the scope of the audit
• Identify “show-stoppers”
• Estimate or quote the project
• Plan your audit process
• Schedule a follow-up

Figuring out scope

Although the ideal is to perform an accessibility review which identifies every problem on a site and specifies solutions, that’s not always practical. In fact, it’s sometimes utterly pointless — it depends on the ultimate goal of the review. The review process for a site which is considering a redesign is radically different than for a set of templates intended for a web site still in development.

Setting goals at the outset is key. Are we looking to identify key areas for improvement? What are the resources available for fixing problems? If an aspect of the site is rife with major problems, is it best to identify every problem within that area, or simply describe the general issues and recommend finding a new solution?

An initial review does not need to identify every problem. One route I’ve frequently used is to specify a multi-stage review process: an initial review, in which I note major issues and provide guidance on fundamental principles of web accessibility, and a follow-up in which I re-check the site and, if desired, provide further guidance and detail for continuing development.

Identifying “show-stoppers”

What’s a “show-stopper”? Essentially, that’s a function of the site which is so completely inaccessible that there is no value to identifying the problems — instead, you should just describe what would constitute a good solution and recommend replacement.

It’s not uncommon for this to arise at the very earliest stages of the review, when discussing scope. If a site is using a CMS or a framework which is fundamentally rendering it inaccessible, you may want to begin by recommending redesign of the site. However, due to the common usage of external resources to provide video, interactive widgets, or social media (to provide a few examples), it may be that there are elements in use which won’t stand out right from the beginning.

Rather than performing a detailed exhumation of a fundamentally broken aspect of the site, it may be in the best interest of all parties to simply flag it for replacement and discuss that possibility with the client.

Why is this section part of the business structure? Because spending hours reviewing replaceable services is a poor use of your time and your client’s money. You should be looking for ways to improve your client’s site without costing them an arm and a leg!

Coming up with a fair estimate

It’s difficult to provide a good estimate on what a large-scale accessibility review is going to require, in terms of hours or dollars. The larger the project, the harder it is to quote. Keep in mind, however, that what you’re quoting is not generally going to be based on the number of documents on the site — rather, it will be based on the number of unique templates, forms, and navigation structures found on the site.

It is entirely possible that the site you’re reviewing will have 12,000 pages, most with images containing improper alt attributes. However, as an accessibility consultant your time is better spent identifying one or two representative examples and explaining how to properly use the alt attribute than it is painstakingly identifying every single inappropriate attribute throughout the site.

For this reason, you should be looking at the site as a process, not as a collection of pages. The ideal process of the site can be described, greatly simplified, in four steps:

1. The visitor arrives at the web site, which can happen at any place in the site.
2. The visitor will attempt to move to another point on the site, which may be another part of the same document
3. The visitor will begin a goal, which may be a purchase, a form submission, or the acquisition of information
4. The visitor will successfully complete that goal, and be notified of the results.

This general outline describes any visitor to a web site — as a consultant, your job is to identify each barrier they may encounter while completing the process. You don’t need to look at every single page of the site in order to see the shape of the problems — if you can’t navigate using a keyboard on one page, you probably won’t be able to on any other page, either!

With this knowledge, it becomes readily apparent that a web site which has 12,000 pages but uses only one navigation structure, one template, and has only a single form will be much more quickly reviewed than a site with 120 pages which uses 5 templates, provides ecommerce, and has different navigation structures depending on what area of the site is being used.

A 100% complete audit must allow for the possibility that each page may exhibit different problems. After all, if you haven’t looked at a page, you have no way of knowing how different it may be from what you’ve already seen. However, in all probability, pages of a site will be at a fairly consistent level of accessibility. The pragmatic approach — mindful to your client’s budget needs — is going to be a selective audit, not a complete audit.

Plan your Accessibility Audit Process

Now, once you’ve done this a few times, you’ll probably have the basic approach down cold. Every web site is different, however, so that isn’t going to completely free you from doing some planning. You still need to decide what your approach will be. Two example starting approaches could be process-based testing or issue-based testing.

If you’re going with a process-based testing procedure, you’ll start by selecting a process – any process. The path to make a purchase; getting to the Privacy link in the footer; sending a contact message. Follow that process all the way through in painstaking detail, isolating the accessibility issues encountered along the way.

With issues-based testing, you’ll instead pick an issue – such as keyboard accessibility. Work your way through the entire site, noting keyboard-relevant issues as you go. Then move on to the next issue and start your hunt over.

It may seem like I’m describing a very pedantic way to thinking about conducting an audit — you know that you will ultimately do both of these in their entirety. However, the reason for having a plan is simple: you need to avoid the trap of the scatter-plot approach. If you don’t have a system, you’re far more likely to end up missing problems – either because you failed to consider keyboard accessibility over here; or because you forgot to check the contact form when you were reviewing contrast. Having a plan and a process will help you avoid these gaffs.

Schedule a Follow-up

It would be nice to believe that when you’ve written and sent your painstakingly thorough accessibility audit to the client you are done with the project. Sadly, we don’t always live in that pleasant fantasy world. (Although, to be honest, in my fantasy world an accessibility audit would consist of nothing more than a smiley sticker and the phrase “Good Job!”)

Unfortunately, no matter how detailed you made your report — the report doesn’t fix the web site. The client’s developers need to do that. Or, as is sometimes the case, the client’s developers will fail to absorb the principles of the document…and while fixing the problems you described, will create new accessibility issues. Or, they’ll implement a fix which shunts the problem somewhere else, rather than resolving it entirely.

This isn’t a guarantee – there are developers working out there who don’t know accessibility, but immediately catch on to the concept once the issues are presented to them. But there are also developers who…don’t.

Planning at least one follow-up review is important. You’ll also need to make yourself available to answer questions from the development team while they work through your suggestions.

The follow-up review should be a quicker task than the initial review. You can spot-check to see how the developers worked with your suggestions. If you like what you see, you can probably be fairly satisfied. If you see problems, you may need to keep going. If you see a lot of problems, you may need to give the client a call before continuing.

In Summary

Performing an accessibility audit requires many skills: an eye for detail, a strong sense for when an accessibility issue requires fixing, and when it requires replacement, and the ability to describe accessibility concepts in language developers can respond to. Join those skills with sound business planning and a personal investment in your clients’ success, and you’re ready to go!

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.