I’ve long had an interest in the impact of search results on learning. In our search-driven information world, the results for a search can have a significant impact on what people will learn. To that end, I did a search on “accessible web design,” to find out what the most available resources on the subject are right now. Today, I’m going to go through the first 10 search results of the moment with an eye to see just what Google thinks the most important and relevant results are for that search.

Why is this important? Simply because the route for learning about accessible web design is likely to begin with a search. The resources that turn up will guide the way people new to web accessibility shape their work.

Because Google’s personalized results can make this tricky, I did two independent searches — one in Chrome, where I was currenty logged into my own Google account — and one on Opera, with a freshly deleted browser history and with the parameter ‘pws=0′ appended to the search, to disable personalized search.

The results were almost identical; just a minor reordering which was very clearly influenced by my own browsing habits. This listing reflects the order of items in my Chrome search, with the position of the item in the Opera search in parentheses. These searches were performed on September 16th, 2012. Although the degree of change over 4 years suggests there won’t be a lot of change if you’re seeing this next week, it is nevertheless just a snapshot.

I also did this exact same search in 2008 — 4 years ago — so I’m also making notes here as to how this has changed over the last 4 years.

#1 (#1) Resources on Accessible Web Design

This is a great list of specific resources on building accessible web sites. Maintained by Terrill Thompson, who does a lot of great work in accessibility. It’s hard to tell for sure just how up to date the resources are, but I did verify that there were no broken links, so that’s a good sign. This is a great result for somebody looking for an introduction to accessible web design.

Position in 2008: #1

#2 (#2) World Wide Access: Accessible Web Design

Where the #1 result was a broad set of resources, this document is a concise discussion of what accessible web design is. While brief, it’s a great overview of the issues and basic solutions. It’s also from the same organization as result #1. This is also a great result – better for the rote beginner, in many ways.

Position in 2008: #2

#3 (#3) Accessibility – W3C – World Wide Web Consortium

I’m relieved to see this page showing up in the results. When I ran this check in 2008, the W3C was only represented by this business case document, which even then cited itself as incomplete. The W3C’s own statement on web accessibility is a must for these results.

Position in 2008: Not in first page of results

#4 (#5) GAWDS – The Guild of Accessible Web Designers

I have mixed feelings about the presence of GAWDS in these results. The organization hasn’t been significantly active for some time, and although it’s a great group (and I’m a member), I don’t really feel like it offers a lot in terms of up to date web accessibility information.

Position in 2008: Not in first page of results

#5 (#9) Joe Dolson Accessible Web Design

The first page seems like an improbable location for my own web site. Position 9 is certainly more appropriate than #5, but neither are particularly sane. As much as I like the idea of having my own site appear this high in the results (and suspect that there may be personalization going on here beyond what I can disable), I can’t help but think that this is not an appropriate result for this search.

Position in 2008: #10

#6 (#4) An Introduction to Accessible Web Design

Some good, some bad. The article is good in principle. It does, however, date to 2002 — which means that a significant amount of the article is referencing the WCAG version 1.0 and the Bobby accessibility testing service — which is long, long gone. This is a great example of an article that could be truly evergreen if it were updated. As it is, it’s kind of 50/50.

Position in 2008: #5

#7 (#6) WebAIM: WebAIM : Web Accessibility for Designers

These results would not be complete without a resource from WebAIM. This specific result is a bit of a surprise, from a content perspective, but I’m sure that the rampant sharing of infographics has given it a significant boost. It’s a good resource — it doesn’t stand on its own easily, since it’s quite cursory, but it gives great information. And unlike most of the other results — it’s actually about design and accessibility, rather than being more focused on development.

Position in 2008: did not appear in top 10

#8 (#7) Web Accessibility – ADA Guidelines for Web Page Design

My immediate reaction on seeing any about.com page in search results is rarely positive, and this article is no exception. It’s filled with positively ancient resources and a few just plain errors. The opening statement is “ADA Guidelines for the web cover aspects of Web accessibility” — giving a definite impression that the Americans with Disabilities Act actually provides guidelines for the web. Even if you’re considering the Section 508 guidelines, you have to observe that Section 508 is an amendment to the Workforce Rehabilitation Act of 1973, not the Americans with Disabilities Act. To be fair, not every resource in the list is actually terrible — but it doesn’t start out well. Not something that would be in my top 10 resources.

Position in 2008: did not appear in top 10

#9 (#8) Basics of Website design for accessibility

This is a bad article. It includes woefully inaccurate information, misconceptions, and ambiguous statements. One of the keystones of the page is an inaccessible Flash-driven accessibility tutorial. Oh, the irony.

Position in 2008: did not appear in top 10

#10 (#10) An Idiot’s Guide to Accessible Website Design

This is neither a particularly good article nor a particularly bad one. It’s vague, includes some misconceptions — but mostly it just isn’t very meaty. You can pick up a few good tips here, but you may also walk away with entirely incorrect perceptions including that WCAG 2.0 “eliminates” the guesswork in accessibility requirements. Sorry – but accessibility doesn’t summarize that neatly.

Position in 2008: did not appear in top 10

Overall Thoughts

The top results are a definite improvement on what they were in 2008. The appearance of the W3C’s main accessibility page is definitely a great addition. Unfortunately, there are also a few truly not-so-great or just inappropriate results. However, the top five or six results (excluding the fact that my web site rises significantly to the top when results are personalized to me) include some great resources — and the very first result can get you even further.

This was, of course, a pretty generic search — it’s about as broad as you can get, and is just one example of search results about web accessibility.

Jennifer Sutton brought this interesting factoid to my attention today: the single most common HTML validation error is the missing alt attribute.

Of the 100 most common validation errors collected by W3C Love, a missing alt attribute comes it at number one — with almost double the occurrences of the next most common error.

It’s 2012, and the key mistakes in HTML seem to remain the same.

Now, one can’t help but hope — since these are the results of validation tests — that these numbers also reflect a large number of people who went “Oh! Whoops! Better get that information in there.” Of course, some of those people may have then gone on to write in “Spacer.gif. 600 bytes. White line.” as their alt attribute.

Obviously, this raw number of errors doesn’t demonstrate a lot of definitive information. However, the mere fact that this is literally the most common validation the error points to some serious problems in HTML education or in HTML generating tools.

I can understand people providing bad text alternatives. When you read over the guidelines for authoring alt attributes — either in the HTML 5 specs or Steve Faulkner’s slightly-more-easily-understood Techniques for useful text alternatives, it’s easy to get overwhelmed. The chains of instructions: this MUST be done, that MAY be done, this is REQUIRED, that is OPTIONAL…it can be a lot to digest.

But omitting the alt attribute entirely is kind of scary. Yes, it’s true that the HTML5 spec currently (and unfortunately) allows the alt attribute to be excluded in certain very limited situations — but the statement that alt attribute is optional in HTML 5 is far from accurate. It is definitely still required, and omitting the attribute is discouraged in no uncertain terms, as below:

Such cases are to be kept to an absolute minimum. If there is even the slightest possibility of the author having the ability to provide real alternative text, then it would not be acceptable to omit the alt attribute.

Even the most casual search of phrases like “alt attribute optional” brings up many, many results clearly indicating the importance of using the alt attribute without even a suggestion that the attribute is in fact optional, so it seems like somebody would have to work pretty hard to come away with the impression that it was optional.

Why is it left out so frequently?

We need better education. Ignorance is still the primary guiding factor in casual web development. When people are exercising barely-learned skills, they tend to go in the direction of the simplest possible set of instructions — leaving out any portion which doesn’t seem to have any impact. That means that images are included with a src attribute; possibly with width and height; and frequently with some kind of inline style or border instruction. Alt attribute? Why?

Any time you read up on an alt attribute, you’re likely to run smack into the TL;DR problem: explaining how to use alt attributes in any detail means a long, involved explanation. Even explaining the incredible difference between an empty alt attribute and an ommitted alt attribute is over the head of many layman content authors.

We need better decision making tools. It’s necessary to simplify. The experts need to work out the complex details of what, why, how, and when an alt attribute should be one thing or another. For the layman, it needs to be summed up as simply as possible.

Here’s my idea of a generalized alt attribute decision tree:

• Is this image a link or form control?
  • Yes: Alt attribute must communicate the destination of the link or action taken
  • No: Continue on!
• Does this image contain text?
  • Yes: Alt attribute should include the communicative text of the image (not text included for visual effect)
  • No: Continue on!
• Does the image contribute meaning to the current page or context?
  • Yes, and it’s a simple graphic or photograph: the alt attribute should briefly describe the image in a way that conveys that meaning.
  • Yes, and it’s a graph or complex piece of information: the information contained in the image must be included elsewhere on the page.
  • No: the alt attribute should be empty.
• Is the image something other than the above?
  • The alt attribute should be empty.

This very definitely does not cover all cases. But it’s much better than nothing; I hope that somebody is able to make use of it. If you have a quarrel with the wording or instructions, let me know in the comments!

It is incredibly hard to resist covering more and more issues here. But the purpose of this decision tree is to provide a simple and understandable tool to navigate the most common circumstances. This is not the place to explain the entire scope of alternative content.

May 9, 2012 is the first of what will hopefully be many Global Accessibility Awareness Days. The concept is simple, I hope: raising awareness of accessibility issues around the globe, so I’m going to neglect to spend a great deal of time explaining what it is.

The day was inspired by Joe Devon and has tirelessly been promoted by Joe and Jennison Asuncion — and all thanks to them for their work!

Why Global Accessibility Awareness

The biggest problem facing accessibility practitioners continues to be awareness. When the people responsible for creating content don’t fully (or even partially) comprehend the consequences of their actions, it is almost certain that what they produce will exhibit fundamental accessibility problems. It’s rarely malicious — there are certainly people out there who expressly decide that they are putting other priorities first, but I don’t believe it’s actually out of malice. It’s usually a lack of understanding.

The hope for an event like Global Accessibility Awareness Day is that the impact will be broad enough that it can successfully reach people who don’t already understand the issues — conferences rarely accomplish this, although they help, because those who attend are already involved, in some way, in accessibility issues.

A small change can make a large difference. Something as simple as providing keyboard focus can transform an online purchase from a frustrating and dissatisfying experience to an easy, pleasurable task. (At least, if you like shopping.)

But not everybody knows that.

What can you do to help?

First, talk about the issues. Tweet about them; post about them on Facebook; write a blog post. Get the word out. The more accessibility is talked about the more people will know about it. If you reach just one person who becomes curious and reads a little bit more than you have been successful. Awareness has increased. Cheerio.

Evangelize to your colleagues, if they haven’t bought in. Learn the most common business case arguments, and be ready to defend them. It’s a chronic problem that getting “the right look” commonly outweighs the importance of accessibility on many projects.

If you’re in a position to take part in a Global Accessibility Awareness Day event, please do — I’m not within a thousand miles of one, so I certainly won’t be there, but I’d love to hear about them from somebody who attends!

It’s not just a day

Promoting accessibility awareness needs to be a lifestyle, not just a day. One day of heavy promotion is a great thing — the sheer volume of information greatly increases the likelihood that those who need the information will receive it. But don’t let it go there!

Pulling the world forward to be truly welcoming on all accessibility fronts may be eternal and Herculean, but it isn’t Sisyphean. This is a task we can succeed at, if we keep moving.

At CSUN 12, I attended an interesting but somewhat disconcerting demonstration of Google’s progress on making their Google Docs suite accessible. The presentation was by Anne Taylor from the National Foundation of the Blind and Jeff Harris, the product manager for Google Docs.

They clearly agreed on one core point: that Google Docs was definitely not ready for users with disabilities. So, the demonstration was more a show of the range of changes which Google has been adding to make their Docs suite accessible.

On the surface, this is great: Google, a major web apps producer, is working very hard at making their products accessible.

But I’ll hope you’ll pardon me if I don’t consider this a reason to party.

What the demonstration really showed me was method of working with accessibility which seemed to amount to reinventing the wheel — doing whatever they wanted to implement a method for their software, then doubling their efforts so that they can use that method and make it accessible.

That Google is working to add essentially their own accessibility API layer between their apps and a screen reader is only mildly disturbing to me. They have the resources to do this, and I do believe, on the basis of the demonstration, that their cloud office suite will eventually be accessible.

What really concerns me is the example they’re setting.

In the CSUN session on Perfect Accessibility, Henny Swan raised a question about providing examples. The specific subject was in respect to organizations with an international reputation in accessibility, not an organization with a generally international reputation for web expertise; but I think that the point applies.

Google, while not particularly known for their accessibility expertise, is well known for pushing the envelope in web development. They build cloud software which can do some very cool things. What it does not do is follow anything apparently similar to standardized methodology — and because of that, as an example, their work is grossly problematic.

I worry that talented developers will look at Google’s methods and see them as a great example — when they may not also have the resources to build an entire accessibility abstraction layer between their ideas and assistive technology.

Now, there are some advantages to Google’s system, as well. Because they are devoting these kinds of resources to accessibility, they’re not only aiming at the possibility of using the Google Docs suite; they’re aiming at a great user experience for users with disabilities.

Nonetheless, a truly accessible interface with Google Docs is still a significant ways in the future. The best experiences currently are either using NVDA with Firefox or Chrome with ChromeVox and JAWS or VoiceOver.

These are my complete, unedited notes from the “Should Accessibility Be Perfect” session at CSUN12. Any errors are my own – if you would like to correct anything (say, spelling of your name, add your name if I failed to get it, or correct a gross misunderstanding I had in attempting to rapidly summarize your statements) please do let me know!

Comments in square brackets are my own comments while writing. I missed some names or don’t know enough information to identify people in some cases – if you can provide information, that would be helpful.

If you do not want your information personally identified in this document, let me know.

Panel: Kath Moonan, Lisa Herrod, Leonie Watson, Sarah Lewthwaite, Henny Swan

See also Henny’s post on the questions raised for discussion.

Legal:

Leonie: Development of the Equality Act, specifically mentions accessibility of disability services. Section 508 in process; Australia has targeted WCAG AA as achievement guideline. Cases: Budget Airline, Target, Sydney Olympics

Guidelines:

Lisa: Primary audience; can you cherry pick guidelines for your primary audience. Better to get something done than everything?

Education:

Sarah: Discrete skill sets with different pedagogies: hard code and symbolic code (perfectable); about people, and messy realities. Abstract vs. concrete. To what extent must a11y be a research-rich discipline involved with people with disabilities. Is a perfect education possible?

Users:

Kath: Lot of accessibility activity focuses on technical compliance, though starting in 2005 the DRC in UK stated that most issues were outside of WCAG 1 (at that time). Can one claim perfect accessibility without user testing? Should we classify people by impairment: medical model. Usability suggests 6 participants per type of user – how many users does this mean for user testing?

Development:

Henny: Perfect accessibility may not be possible. May not have been involved in scoping or user interface; given wireframes and have to code. If you have a global reputation, what’s your responsibility for your production, given it’s usage as an example? May have to sacrifice one small slice because of other needs. As consultant: when do you allow an exception. Where’s the cutoff? Working with imperfect assistive technology, browsers, technology — can we reach it anyway?

Disability:

Sarah: Can we reach a definition of perfect accessibility? Levels and types of disability vary widely. Medical model of disability vs. social understanding of technological mitigation. Awareness of stigma and cultural bias. Post-structural: other power relations besides economic — family, duties, religion, etc.

John Foliot: Question: We as content producers and developers have a social contract with the consumers of our products. How does that factor into the process. Do they also have a social contract to maintain their tools to access what we create?

Henny: Formula – users should be able to use their assistive technology. If it’s a small edge case, it might be let go – if it has a huge impact, then we need to take responsibility even though it may not be our problem. Creates risk that we perpetuate the problem by supporting low-quality solutions.

Leonie: From a user end, the assistive technology vendors, browser manufacturers, ourselves should all be experts — audience should not have to be. We all have a responsibility, but we may carry more (all three groups) due to the necessary expertise burden.

Jessi: Similar situation with web browsers in general; up to the consumers to stay up to date. If consumers are using too old technology, the user should take some responsibility to update.

Jimmy Chandler: tries to talk to managers/clients by describing usability as a continuum — usable by one person towards usable by all. Want to encourage participants to move as far as possible, and keep moving further. Government Section 508 very black/white — if they can’t achieve standards, sometimes won’t even try. [Note: person next to me nodding; she works with United States government organizations on 508 compliance]

Lisa? Can’t see: Cherry picking guidelines — how do we handle that? Talking about continuum and what impact we have on a project, we can narrow down to specific guidelines for specific stakeholders (content developer, designer, developer, etc.) Large impact on continuum by distributing burden.

Jimmy: Encourages picking small tasks to achieve so progress keeps moving.

Wendy Lawton? electronic document accessibility services: Raises the concept of perfection — no companies pursue it; most pursue “Best practice” Organizations must define best practice and deliver it. Service providers must define their best practices. Best practice is just as cost effective to achieve in most cases as “good enough” If SP won’t provide “Best in Class” they should disclose

Ryan Benson – Problem with statement is that content providers don’t know that (don’t know what best in class is), and user can’t teach a contractor how to do their job. Contractor doesn’t like to be told everything was wrong.

Wendy: Hears this all the time; procurement people (hiring professionals) need to know what to look for when hiring a contractor in order to achieve accessibility. They need to know what quality requires.

Kath: summarize – “Ryan – In real world, contractors don’t have any accessible practices let alone best, why should consultant have to train the contractors under a tight deadline?” Frequently accessibility is a line in the sand and where do we draw that. Is User testing part of best practice?

Steve Faulkner: Implicit social contract between developer, implementors, and implementation of accessibility support within sites. Developers and browsers are on board, but IT vendors are NOT. Need to have purchasers involved in the contract. AT vendors suck millions of dollars out of users, but can’t take time to involve selves in standards definition – NVDA devs are heavily involved, but are the exception

Sally Cain, Royal National Institute of Blind People — Lot of AT being developed for people who don’t want to learn Windows environment, but they aren’t being supported outside. People can’t do their shopping, because the AT vendor of the product hasn’t made changes to provide outside support. AT gives simpler experience, but doesn’t have sufficient support for real-world tasks.

Jim Henna? – Applauds Steve, but dislikes blame games. Came across inaccessible service, AT blamed browser manufacturer; browser blamed AT. It’s not clear enough – (could be because AT not involved in standards? JCD)

Kath: Subject Up to user to update; references Antonia Hyde? — strong points is that if onus goes on user, it can really exclude people with learning disabilities.

Derek – UK association for blind? Association arranged meeting of companies to sit down — nobody actually said anything.

Lainey Feingold: “Cherry Picking” should be called “Priorities” — from a legal perspective, Priorities indicates intent to continue – “picking” doesn’t come across well; more like a final decision. Legal doesn’t look for perfection, though they want it, they look for priorities in line with needs of user base.

Lisa: Is prioritization “perfect” accessibility — doesn’t believe there is such a thing.

Leonie: What happens if you don’t “nail” all of those issues? Is that a risk due to proscriptive legislation with exact definitions of accessibility.

Henny: At what point do you determine that you’ll launch despite some being unable to use it — but if you don’t launch, NOBODY can use it. The line is constantly shifting.

Glenda Sims: Has to deal with this a lot, always describes it as would be willing to stand with them in a court of law to defend their decisions — avoid that punch in the gut. If you’re willing to defend the decision, you can probably go ahead.

Ian Pouncey: Usability testing is a great way to tell whether it’s accessible or not — user testing a measure of access. From an engineering perspective, not very scalable! Not enough testers, too many things to test. Very few tests get tested in any way shape or form.

Henny: One strategy: BBC has had a brain drain; they are focusing on high profile, key products, and putting effort and training into testing those products — documenting everything, and pushing that knowledge back into the organization. Corporate needs to retain these skills and knowledges, eve, if people leave.

Kath: Vodafone — not currently best in class, but trying very hard. Some products will take a year to get out to market. Lots of user research and testing — strategy – trying to bake working with disabled users into their standard usability tests, from all stages — from product creation through end testing.

John Foliot: Disclaimer personal opinion — tag on to Glenda. When he’s doing evaluations, primarily thinks about everything as being task oriented. Perspective is a) can I do the task and b) how painful is it. At what point is it too painful, regardless of being compliant. Petty issues like heading order doesn’t really make a practical difference. Differentiate failure from annoyance.

Lisa: User testing – works as an independent consultant, many different orgs. Small web agencies, non profits, etc. Has been running compliance/technical audits up front, then looking at those results to conclude how to run user testing and evaluations. Every project includes user testing working with people with disabilities among others — seniors, etc. Audit gives developers some work, then user testing refines focus and can greatly improve usability of sites.

Henny: Notes #PerfectAlly tweet streams; couldn’t keep up. Notes should take the steps to file bugs, talk heavily with major vendors — they frequently are open to considered and constructive feedback.

Karl Groves: re Ian Pouncey — disagree that large scale doesn’t scale, requires good Project Management and great planning, but is possible.

Henny: Need to learn from reports and test results, same code across different products should be reusable.

{Unknown}: Consultant — teams have picked base platform which is fundamentally inaccessible — address this issue early rather than piling band-aids. Can be a major problem. What do you do if you’ve inherited fundamental problems?

Kevin Chao: In regards to accessibility in general; various products, services, standards, countries — difference between different national standards makes the issue complicated.

Sarah: Question of international standards is interesting — vast majority of disabled people in very low-income non-Western countries. Are we really talking about a technological elite among people with disabilities? What about mobile-first countries where access to people with disabilities may be very low? Are we exporting expectations about disability which may not be as useful to individuals in these different locales?

Shadi: Specific area is developing countries – this question is big. Lots of research gaps and open questions. Doesn’t think there’s a real export of expectations, but the issues are very diverse and different. Don’t get to talk about accessibility of systems; lucky to have systems. Distance education programs can have very beneficial use [where technology is available]

Leonie: Legacy technology is huge issue. Go back to the supplier of technology to get better accessibility – don’t underestimate the power as purchasers and procurers. Big strides have been made forward in last five years. Amount you can tackle in house can be intimidating but impressive. In house can give you fabulous front and back end products which you may not be able to get from a 3rd party product if that product doesn’t natively meet your needs.

Denis Boudreau: Believes that the very fact this is happening means that panel/environment believes that imperfect accessibility is acceptable. Probably a good thing, we’re moving out of accessibility [elitism]/perfection, which can slow down take up for accessibility. Getting all web sites a little accessible much better than 10 web sites which are perfect —

Kath – Trying to be perfect can make us pedantic

{unknown} – Lot of research in communication technologies in development/mobile telephony – information science. Doesn’t entirely address accessibility issues, but addresses barriers with simple technology as area of literature to look into.

Linda Dardarian — Law doesn’t require perfection if it creates undue burden.

We need to have a talk with marketing.

So, I’m sitting at CSUN 2012. It’s after the keynote, but before the first sessions of the conference – and some of the very key points of difference between the marketing and accessibility world are making themselves very clear. Most of the conferences I’ve attended in the past were marketing-oriented – and even where the subject of the conversations are similar, the overall impulse behind the issues is radically different.

The simple fact is that marketing is fundamentally business-oriented. It’s about moving your or your client’s business towards what counts as success for that business. Usually, that means greater profit: higher sales, better ROI, lower expenses.

The world of accessibility is oriented towards the success of the individual who uses your business. Instead of focusing on the profitability of business, accessibility pursues optimizing the experience of the user. This approach certainly can and should lead to improved ROI or higher sales — but it’s not how it’s advertised, and it’s not the goal.

The issues and needs may have a lot in common, but having a different core motivation makes for a radical difference in approach.

Great intentions, road to hell paved with

In marketing I have long observed a tendency to compromise the end-user’s experience for the opportunity to increase business opportunities. However great the intentions of a business owner, they can easily be swept away by the perceived opportunity to increase their business.

With a definite lack of available statistics which can reliably expose the real economic impact of users with disabilities on the web, this is a difficult argument. Is it a lack of empathy? Is it partially because the physical environment of a store forces the business owner to directly confront the visitor with disabilities whom they have disenfranchised, an experience which doesn’t exist online?

The disembodied user effect is well known in social media. The willingness to treat people online as objects rather than as people is damaging in many environments, and the arena of disabilities is almost certainly among them.

What can the accessibility world do to make this real for business owners? Improving empathy may be one path. Producing real, concrete statistics demonstrating the impact a lack of accessibility has on a web-based business may give additional working fodder.

But educating businesses may not be the best path. Educating marketers — possibly the class of service most heavily employed by businesses with a web presence — could have a truly inspiring impact. Where do business owners turn first when they’re looking to develop their web presence? Marketing. In the business world, a web site is fundamentally a marketing tool — so perhaps that’s where education and research needs to go.

Bringing the world of marketing to a point where it views a simple accessibility failure like inserting keywords into an alt attribute as a threat to the web site’s users, rather than as an opportunity for search engine optimization could have far-reaching impact.

An aspect of the problem for many web sites has to do with long-term business development. A business may hire an accessibility expert to review their web sites, make suggestions, or re-work their web site, but when they hire a marketing firm for long-term web site development, they can lose their accessibility very quickly if that marketing company doesn’t also have a firm grasp on accessibility.

Marketing is a necessary service for most businesses. Accessibility needs to be understood as an equally necessary partner to any marketing efforts.

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!