As teachers, we are always on the hunt for more insight into what people want to know more about — in part, to see what the current state of industry understanding is about accessibility and how we might help everyone create more accessible sites and applications. What better way than to ask? Here’s the results of some recent research and a clear question–what do you want to know more about?


In July 2011, I put up a blog post on my own site titled “My Challenge to the Accessibility Community: We Need an Accessibility Body of Knowledge” in which I argued that there’s an unfortunate lack of cohesive and unified information out there about accessibility. At the time, many agreed but ultimately the idea gained little traction. The conversation was revitalized by Olivier Nourry with his blog post “How we could build a Body of Knowledge for Web Accessibility“. The subsequent conversation on Twitter heated up enough that I decided to start a mailing list which would allow interested parties to discuss the concept in more than 140 character increments.

The best part of the mailing list discussions that followed was the wide variety of people who participated. We had people who worked in government, people from the private sector, and people from higher education. We had people from both large and small organizations and people with and without disabilities. We had people who were new to accessibility and people who weren’t so new and people with varying level of technical knowledge. Finally, we had people who agreed that a Body of Knowledge is needed and those who said we did not. To address this question of whether a Body of Knowledge is even necessary, we began by attempting a Gap Analysis to determine the delta between what already exists and what does not. The first step: Figure out what people need to know.

What people should know

To gather this information, I moderated a Delphi-like effort to gather participant’s opinions on what was needed. Each interested participant was asked to send over a list of topics that they thought should be included. After the first round, we collated the answers and redistributed the list for a 2nd round in which participants would refine the list. Unfortunately, this is where the conversation sort of waned and participation in the process essentially ended. Regardless, we did gather a good amount of information on what people in the accessibility community think others should know about accessibility. Below, I’ve listed the findings from that first Delphi round.

Technical guidance

Accessibility is often regarded as nebulous by those without an intimate knowledge of the topic. Nowhere is this more true than in the case of the technical aspects of it. It is really no wonder, when you consider the complex dance between the operating system, browser, accessibility APIs and assistive technologies. Gaining a real understanding the technical aspects of accessibility requires a knowledge set that is both broad and deep. Therefore, accurate, relevant, and timely technical information would be vital in a Body of Knowledge. Here’s what participants in the Delphi said was needed:

  • Techniques/ Failures and best practices – specifically, what does it look like to develop accessibly? What are the best ways to develop an accessible system? The WCAG working group has developed Techniques for WCAG 2.0 but I guess participants felt the information hard to absorb or that it didn’t cover enough.
  • Usability/ Universal Design – Participants appeared to want information that extends beyond what people normally consider to be accessibility and more about universal design and its contribution toward a more equitable experience for all.
  • Plain languagePlain language is clear, succinct writing designed to ensure the reader understands as quickly and completely as possible. Many consider plain language to be vital for universal access and therefore many Delphi participants listed it in their topics list.
  • Platform support information – as mentioned above, the complex relationships between the operating system, browser, accessibility APIs and assistive technologies has a large role to play in accessibility. Participants felt that a Body of Knowledge should include detailed information on this topic.
  • Product/ Platform/ Framework specific information – There was a strong desire among participants for a Body of Knowledge that contained specific information regarding the accessibility of products, platforms, and frameworks. In some cases the argument was to have this information for procurement guidance while other times, it was recommended for design & development guidance for teams working with that specific type of product.

Managing accessibility

For organizations that are new to it, managing accessibility can be a challenge. Understanding how & where to spend time and money, who should be doing what and when contribute to the impression that accessibility is nebulous. Delphi participants shared a desire to have information on managing accessibility included in a Body of Knowledge. Specifically, they cited the following as things to be included:

  • SDLC/ Project management guidance – Participants felt it important to include information about how to include accessibility into the Software Development Life Cycle and common project management methodologies. They also mentioned including role-based guidance for project members.
  • Business case – When arguing internally for more accessibility in their organization, many accessibility advocates are asked to construct a business case. Delphi participants listed business case information and success stories as some things to include in a Body of Knowledge. They also included a need for methods of gathering metrics on the success of accessibility programs.
  • Procurement – Finally, when it comes to management of accessibility, was the need for procurement guidance. Many procurement officials don’t know about accessibility, what to look for, and how to construct requirement language into solicitations for accessibility when buying ICT (Information and Communications Technology) products and services. Therefore, participants felt a need to include procurement information as well, including sample documents, market research, and Independent Verification & Validation (IV&V) guidance.

Accessibility standards, laws, litigation

Related to the above is the need to understand the organizational compliance needs with respect to accessibility. The policy landscape for accessibility is a complex one to navigate, especially for multinational corporations. Many countries have laws and policies for accessibility, some of which also having their own specific technical standards. Some of these laws or policies may also have requirements for handling procurement of ICT products and services. In some countries, additional policies can also exist at the state/ province level. While there has been a lot of work done to harmonize standards, many disparities remain. Because of this, the Delphi participants felt a strong need for information on the various standards, laws, and policies, including mappings between each. They also expressed a desire to have information regarding past litigation regarding accessibility.

Accessibility testing

Because accessibility isn’t binary (i.e. either you’re accessible or not), performing accessibility testing involves a fair amount of subjectivity. This makes it difficult for even skilled Quality Assurance analysts to understand the tools and techniques necessary for proper accessibility testing. Delphi participants felt that a Body of Knowledge should include detailed information on techniques, methodologies, and tools for testing accessibility.

Assistive technologies

Without experiential knowledge of assistive technologies, understanding all their intricacies can be a bit of a challenge.

There are scores of different assistive technologies, each aimed at addressing a very specific need. Among software assistive technologies, there can be significant differences in quality and capabilities not only between different brands but also among different versions of the same assistive technology. As a consequence, the Delphi participants felt strongly that information – including tutorials – about assistive technologies was vital to a Body of Knowledge.

Disability information

At its core, accessibility is about people. At Simply Accessible, we tend to focus primarily on designing for all users—some of whom have accessibility needs. Regardless of your personal approach, accessible and usable design means understanding the needs of the user. In fact, gaining that understanding is often the “a-ha moment” that gets designers and developers on board with accessibility. When we can get designers, developers, content creators, project managers, and executives to understand the challenges faced by persons with disabilities, they’ll be more prepared to begin addressing the accessibility of ICT systems they build or procure. Therefore, the Delphi participants felt that a Body of Knowledge should include information on disability, including detailed descriptions of how people are impacted when using ICT products and services.

What would you like to know about?

That’s a lot of detail, but it mostly came from people that are already accessibility advocates. And while this process did a good job of getting at the root of what accessibility advocates feel others must know, what we didn’t gather is what other people want to know. People that aren’t already accessibility specialists.

Perhaps it is the same. Perhaps it is different. Either way, we want to know what YOU want to know more about.

Let us know by commenting below. Are you a developer? Designer? Manager? Something else? Or, feel free to shoot us a message and we’ll include your comments in a follow-up post.

9 thoughts on “What do YOU want to know about accessibility?”

Read comments

  1. Hi Karl,
    Thanks for citing my article!
    Your readers might be interested in knowing other places where this has been discussed or documented.
    One that comes to my mind immediately is this LinkedIn discussion:
    I also try to maintain alive a Quora board, collecting a list of examples of resources that could help define or inspire an a11ybok:
    Finally, it’s only fair to cite your own effort with a11ybuzz:


  2. Dan Pattenaude says:

    Why is it “accessibility” and not “accessability”, emphasis on ability?

  3. Karl Groves says:

    Dan, thanks for writing. Actually the suffixes “ible”, as in “accessible”, “audible”, and “convertible” and “able” as in “movable” both mean “capable of” or “suitable for”. See more at:

    1. Dan Pattenaude says:

      Hi, Karl,
      If both spellings are interchangeable, I choose the “able” version over the “ible” version.

      For me, it’s accessable, and thus accessability, the ability to access.

      I think the language police would approve, given our new social emphasis on equitable treatment of those with different needs.

      Spelling has changed a lot through the ages. No reason to stop it from evolving now. :-)

  4. Darren says:

    To answer your question, I’d like to know more about… Best practices or methods you could recommend for treating or converting non HTML content to be WCAG compliant. Word Docs, PDFs, PPT files and the like. newb, so apologies if this content exists.

  5. Iza Bartosiewicz says:

    Thanks Karl for another thoughtful article. In Australia, we have Access iQ, which was created to provide practical and up-to-date advice about web accessibility. This Body of Knowledge is still young (it was launched in July 2012), but it is already full of useful goodies, such as the Web Accessibility Wizard.

  6. Richard says:

    As an accessibility specialist myself, what I would really like to know is what level of complexity is reasonable/acceptable for a technically accesible data table?

  7. Accessibility testing is subjective unless the testers are trained in Section 508 and WCAG compliance criteria. It also helps when the testers live with a disability and have used their assisstive devices on a daily basis to navigate through the Internet. Add into the mix one or two individual testers from the four disability groups, vision, hearing, mobility and cognitive disabilities, and a subjective testing result turns into a quantifiable and usable document.

Comments are closed.