People often perceive accessibility as a burdensome obligation that’s solely the responsibility of developers or an overwhelmed accessibility specialist. I’ve always wanted to change that mindset.

During a recent contract, I introduced a strategy to reframe accessibility as a shared responsibility. The ultimate goal is for accessibility to become part of business as usual by involving everyone, including designers, writers, quality assurance, business partners, and leadership.

The strategy targets cultural obstacles and promotes the discovery of opportunities throughout a project lifecycle when decisions could and should be made about accessibility.

It’s an alternative to the traditional approach of sending developers to the Web Content Accessibility Guidelines (WCAG) with instructions to “just make things accessible.”

Allow Everyone to Own Accessibility

This is inspired by the confusion I regularly encounter when I suggest that all team members can play a role in accessibility. Let’s change the way we think about accessibility, starting with the notion that it’s exclusively a code-based exercise for developers.

A lot of the guidance for developers about coding standards also includes recommendations for writing and design, activities in which the user experience team should be involved. This includes decisions about content hierarchy, using the right colors, writing alt text for images, etc.

Allowing everyone to own accessibility also makes it possible to catch errors earlier in a project when it is easier and less expensive to fix them.

Empower Everyone with Education

With education and greater awareness about accessibility, what needs to be done and how it impacts the user experience, all team members gain a greater understanding of the role they can play in creating inclusive websites and applications.

Talk with People to Figure Out Where to Start

We interviewed team members in order to understand their attitudes towards and knowledge about accessibility, how they believed different roles might contribute, as well as specific tasks or techniques they would employ. I also spoke to our accessibility consultant and researched the most common accessibility errors across projects.

We discovered through interviews with the content team, for example, that they were empathetic and appreciated the importance of accessibility. They were, however, unclear about different types of assistive technologies and how to approach writing for users. This helped us figure out a starting point for education.

Ensure Education is Relevant, Engaging and Ongoing

Information must be easy to find and available for everyone. It’s also important to broaden education beyond generic materials or references:

  • Use time during team meetings to discuss real examples, project problems and solutions.
  • Invite an expert to talk with the team at a lunch and learn.
  • Host a panel discussion with assistive technology users.

We developed an online training course that presented fundamental information for designers and the content team. Key is that we created exercises and provided examples relevant to their work. To further support them, we connected them to a curated list of resources and select tools (otherwise it’s just overwhelming).

Educate Leadership and Business Partners Too

I appreciate that leadership and management is often where we face the greatest challenge when it comes to accessibility. Too often, there is a lack of empathy, much less an understanding of the technical details.

But these are often the same people who write the business requirements for projects and manage the budgets. Among the many reasons I could list, mistakes in business documentation about accessibility cost time and money, and impact success.

I’ve heard plenty of stories about project requirements that actually directed people to do the wrong things for accessibility. Team members were frustrated and time was wasted going back and forth to resolve issues that could have been prevented with a shared understanding of accessibility.

I’m going to end this section with that statement as there are a great many articles and books with sound advice on how to build your case for unsympathetic leadership — read the foreword and opening in Luke’s new book to start.

Share a Vocabulary

I’m surprised at the pushback I get for this recommendation. I appreciate that different disciplines traditionally had their own lingo, but as technology allows us and requires us to work more closely together, we should explore opportunities to communicate more efficiently and effectively, and avoid misunderstandings.

One of the most relevant examples for accessibility is the confusion over alt text, what it means, what it should say and how it behaves (some still test its existence by rolling over an image). Across software, Content Management Systems and people’s preferences, I see it referred to as title text, image caption, image descriptions, text equivalent, etc. Can we at least cut it down to two references?

HTML5 is as an example of technology that can support a shared vocabulary and only make it easier for teams to get on the same page. For instance, with the placeholder attribute, it could be possible for writers, designers, and developers to share an understanding of placeholder text, what it is, where it goes and how it works for users.

Integrate Accessibility into the Brand

Along with guidelines on colors and fonts, rules on Oxford commas and bulleted lists, add design and writing guidelines and best practices for accessibility into your branding, design standards, style guides, and other team resources.

Among the topics addressed, our editorial style guide included guidance on writing descriptive links and being mindful of the need for visually hidden labels. The color palette described the WCAG standards for color contrast, linked to select online color contrast checkers, and provided several options for accessible and acceptable color combinations.

Institute Accessibility into the Culture

A critical piece of the strategy, accessibility has to be (or become) a corporate value — just part of what you do.

Leadership must communicate that accessibility is a priority not only in words, but also in action. They help team members find the time to learn, create opportunities for conversation, connect people with great resources and lead by example.

They empower all team members to question things and provide them with recourse to correct problems. I’ve heard too many stories about people who noticed accessibility errors, but could not or did not feel comfortable saying something to their supervisors.

And talk about it. We find time to talk about responsive and mobile; let’s talk about accessibility.

Build Accessibility into the Content Management System

Exactly what this looks like will vary across organizations of course, but the opportunity exists in every Content Management System (CMS) I’ve encountered.

Once designers, writers and publishers understand more about accessibility, they can leverage related features in your CMS beyond just the option to add alt text for images.

A great example, when your content specialists understand things like the fundamental HTML for structuring content, we can prevent some of the messy much less accessible code that’s generated from What You See Is What You Get (WYSIWYG) editors. Instead of using a bold font to create headings and dashes to create lists, when writers know how to structure content with clear, ordered headings and bulleted lists (in addition to using plain language), it’s a win for the code and consumers.

Evaluate Your Efforts

Identify criteria to measure the progress, effectiveness and success of your efforts. There are undoubtedly many opportunities to align your accessibility efforts with business goals, such as reducing customer service calls due to usability and accessibility errors with forms. Talk to your teams and speak with your users before, during and after launching elements of the strategy.

Plan for Change

Expect to revisit elements of the strategy as you write, design, develop or lead teams in the creation of a great experience for new technologies.


What’s Next?

To realize the full potential of the web, accessibility must become part of business as usual. We achieve this through greater engagement and collaboration across teams and disciplines, when we all contribute to creating an inclusive experience for everyone.

I recently started a new job, so my next step is to discover opportunities to employ and implement some elements of this strategy. I’ll report on how things go with my new colleagues.

I know what I have presented will not solve all accessibility problems, but I hope these ideas at least inspire discussions that may not have happened otherwise.

Please share your feedback and stories about efforts at your organization to involve everyone in accessibility. Sharing our knowledge and stories is how we make things better… for everyone.


Alt text is a description of an image that cannot be seen by a sighted user but is available to blind users via screen readers.

When it comes to the web accessibility principles, the inclusion of an alt attribute with an image in HTML code needs to be at the forefront of the developers’s mind. They provide for a rich user experience for every visitor to your site by offering the content of the image in a text-based format. If you don’t provide alt text, then a screen reader will only to say IMAGE or provide a useless file name.

How Long Is Too Long?

When creating alt text in your code, it is important to remember that these descriptions should be kept short. The longer the text, the more difficult it is for the screen reader and the browser to read it. I have on occasion found myself typing extremely long descriptions of images, including every artistic detail contained within it.

While this could be commended, it may not be helpful. Remember to provide a description that is useful in the context of the document and keep the word count short in the range of 5 to 15 words. You may be able to skip over purely decorative images, but those that have significant information need to have this information spelled out in the alt text.

Decorative Images

When it comes to images that have only been included for aesthetic purpose and which serve no purpose other than enhancing the mood of the page we still need to include an alt attribute. In this case the attribute can be empty (alt=””).

Long Descriptions

In general, alt text should be kept short. However, some images might be so complex that extra information needs to be provided. In these cases, it may be beneficial to repeat the description in a text-based format below the image so that all users benefit from the information.

To Conclude

If I could give any additional words of wisdom they would be not to overthink alt text. It should really just be a simple sentence that adds to the content of your website. By including it in your code, you are demonstrating that you are an inclusive developer, one who wants your content to be available to everyone.

Dog and cat

This is a real question asked everyday by Product Owners, Scrum Masters, Business Analysts, Managers Instructors creating course content, and yes, Disability Services Providers. It is a fair question when time and money are both in short supply. However, Accessibility Specialists understand that this question is not necessary when accessibility is included in every step from planning to delivery. Becoming accessibility aware will help every content creator become better at delivering the best quality information.


Working in web accessibility and helping developers with their websites, I’m often asked how a project gets certified as accessible. Few people know that there is no formal certification process that recognises the accessibility (or otherwise) of your website.

However, there are some optional steps you can take to make a claim about your website.

1. Choose your guidelines

Before you can think about certification, you need to decide which accessibility guidelines you will be judged against. There are two main standards:

  1. The Web Content Accessibility Guidelines (WCAG)
  2. Section 508 of The Rehabilitation Act

WCAG are the most popular guidelines and the ones I work to, so I will cover them here. You may need to meet Section 508 if you operate in America under some circumstances, but WCAG overlaps with Section 508, so can be used to certify both.

2. Choose your conformance level

Under WCAG, there are three levels of conformance you can claim. These run from least to most accessible:

  1. Level A
  2. Level AA
  3. Level AAA

I always recommend aiming for at least Level AA.

3. Make a conformance claim

Whilst you cannot be officially certified as “accessible at Level AA of the WCAG”, you can make an optional “conformance claim.”

To ensure you are making a valid claim you must:

  • Have fulfilled all the guidelines for the level you are claiming (including all of any lower level); and
  • Make sure that all parts of your website conform (for example, you’re not ignoring your footer or a few pages); and
  • Ensure that, if your website has a process (for example, buying a product), every page in that process conforms to the level you are claiming; and
  • Be sure that you are claiming success based on accessible technologies.

If you fulfil these criteria, you can add a conformance badge to your website. The W3C provides a range of badges at

You can also contact the W3C to inform them of your claim, but this is optional too. The only notice you’ll get from the W3C is if they believe you to be making an incorrect or fraudulent claim.

In summary

If you’ve spent a long time making your website accessible, it can feel frustrating there’s no official certification available. However, it’s important to remember that accessibility isn’t about certificates – it’s about making your site work for everyone.

Feel free to add the official badges to your website and talk about your work on an accessibility page – but don’t waste your time notifying the W3C. And, don;t forget that ever change you make to your website need to confirm to the same standard or you’ll need to change the badge you display.

Have you added conformance badges to your website? Add links in the comments!

Roman forum

Learning about web accessibility can be hard and quite lonely. Fortunately, there are some great people working in the sector, who are more than happy to help out when you need it. Today, I’m sharing some of my favourite forums for developers wanting to find out more.


The WebAIM Email Discussion List has been going a long time (since 1999!) and it’s a great resource for developers looking for answers and anyone with knowledge to share. Subscribers are helpful and friendly, so there’s no reason not to take part.

Top tip: Have a look through the archives to get a flavour of the discussions.

Accessify Forum

The Accessify Forum is a great introductory forum for developers new to accessibility. Questions can get very advanced, but I find it very welcoming for beginners.

The Forum is also a great place to stay up-to-date with the latest web accessibility news and announcements.

Stack Overflow

Did you know Stack Overflow has its own accessibility tag?

This is great for asking (or answering) specific accessibility questions. There’s a wealth of information already, but if you’re stuck, this is a perfect place to ask for help.

LinkedIn Groups

I’m a member and contributor to many LinkedIn accessibility groups, but here are three of my favourites. These are good for sharing resources and asking for feedback from peers on new projects.


This has been by no means an exhaustive list of forums, but I hope it gives you a few new places to go looking for advice. Of course, if you’re really stuck, you can always email me…

Where do you go to get answers to your web accessibility questions? Share your tips in the comments below and I’ll keep this blog updated with the very best forums, groups and resources for developers.


I was recently asked to explain the difference between web accessibility and usability. I struggled to come up with a clear answer, so took some time to research how others had answered the question. While there are some good explanations out there, there wasn’t one I was happy forwarding to the questioner.

Taking bits from a few sources and adding my take, here’s how I replied:

Web accessibility and usability are closely linked, it’s no surprise you could do with some help defining the two concepts. I wasn’t sure at first if I could do it justice, but I’m pleased with what I have written – hope it helps.

Web accessibility

Web accessibility is what I deal in, so let’s start there. It’s all about helping people with disabilities have an equivalent experience to everyone else when browsing the web. I’ve avoided saying “the same experience” as users with disabilities often see, hear or feel the world differently. To me “equivalent” means that they get the same information, options and enjoyment – it may just be presented differently.  

Things like the Web Content Accessibility Guidelines aim to make the web more accessible to people with disabilities.

Accessible websites benefit people with disabilities in particular.


Usability, on the other hand, is more to do with designing a user-friendly approach. It’s concerned with how people interact with a website’s interface – is it easy to do the things people want to do? Can people quickly find what they want without help? Do people make lots of mistakes using a website? Do people enjoy using the website?

Usable websites benefit everyone.

In summary

A useful way to think about the distinction is this:

A website must be accessible to be usable, but it doesn’t need to be usable to be accessible.

To do list

Someone asked me a brilliant and all-to-common question today: why do so many projects run through all their requirements and then tag on at the end “and it needs to be accessible”?

That’s like asking someone to plan a round-the-world holiday and then, just as you’re about to buy the ticket, asking if you can get everywhere by boat. You’ve just changed a core feature of your trip, now you need to start again and plan which countries have a coastline.

Yet, so often, people think accessibility is something you build on at the very end. As if you just need to make a few tweaks to what you’ve probably spend months planning and building.

But, I’ll tell you something – it’s not their fault.

Nope, you can’t blame someone who just wants to plan a new website for their business. You can’t blame a project manager tasked with delivering a flashy landing page for a new product. In fact, there are only two people you can blame: me and you.

We’re at fault because we haven’t educated enough people outside the accessibility community. We’re at fault because we don’t say in the first meeting, “lets build this website so as many people as possible can use it.” We wait until someone asks and that needs to change.

I’m not suggesting we become accessibility rioters, just good role models. Let’s make sure we talk openly about accessibility right off the bat. With the right attitude, we can help educate more and more people about the benefits of accessibility.

When you start talking (either because you we asked or because you volunteered), set your sights high. Work to the Web Content Accessibility Guidelines (WCAG). Start with WCAG Level A if you need to, but have a plan to get to Level AA. Tell people that these international standards are used to make a better and fairer internet and they can be part of that movement.

How do you make accessibility part of your work?

Google on MacBook

Placeholder text is often seen inside form fields as a hint to users how to complete the field or explaining what the field does. For example, placeholder text in an ’email’ field might demonstrate the required format for an email address. Often, the idea is to help users complete forms and increase conversion rates.

So what’s the problem? People seem to set placeholder text with the right intention, but there are better ways to achieve the same result. Plus, in some circumstances, placeholder text can be bad for accessibility.

It’s important to note at this point that placeholder text is different to a label, which sets up what a form field is for. However, some websites dispense with labels and use only placeholder text to signal the purpose of the field.

Bad colour contrast

Placeholder text is often a very light grey, which fails rules on colour contrast. It’s also difficult for users to change this as the text may not be styled with CSS or put under user control.


Placeholder text is most confusing when it is used to replace a field label. Users can easily miss the purpose of the field if they quickly click or tab into it. There’s often no way to get the placeholder text back either.

Users with cognitive disabilities can be under extra pressure if placeholder text disappears as they may struggle with memory and recall.

Placeholder text can also look as if a field is already filled in, causing users to miss out fields entirely.

Error identification

Placeholder text often makes error prevention and identification much harder for users as they cannot easily see what mistake they have made. This is compounded when websites remove labels in favour of placeholder text. Checking a submission is near impossible without labels on fields.

When users do make an error, a lack of field labels makes it extremely difficult to fix errors as no detail is available on the nature of the mistake.

When you’re designing forms, it’s best to keep away from using placeholder text. Label fields with good descriptions and add help text around a field, rather than inside it. That way, users can read and understand your form, as well as correct any mistakes they make.

Do you use placeholder text? How do you make it accessible? Let me know in the comments.


Last week, I talked about the thinking behind Level AAA of the Web Content Accessibility Guidelines (WCAG) and why it is important for users. The blog post sparked a lot of conversations on Twitter, many of which wanted firm examples of what Level AAA can look like.

Many people seem worried that a Level AAA website is, by definition, an ugly or boring website.

I’d like to use this blog post to highlight some great examples of Level AAA websites out in the wild, used by real visitors every single day. If you know of a Level AAA website, leave a comment and I’ll add it to the list.

I’ll update this list over time, so check back for inspiration whenever you need to.

Level AAA websites

Add yours in the comments!


I once worked with a small business who wanted to make their website accessible to as many users as possible. The business owner approached me directly, after reading my book and this blog, to help her reach more customers. She was an ideal client, well-informed and attacking web accessibility both because it made business sense and because it was the right thing to do.

Earlier in our discussions, I asked what level of accessibility was important for her. She told me that she wanted Level A to begin with and Level AA a little further down the line.

“Wonderful!” I said, delighted with her approach. “And what about Level AAA?”

“Why do we need that?” she asked.

It’s a question I’ve heard many times since. Very few people are interested in achieving Level AAA compliance with the Web Content Accessibility Guidelines (WCAG). One of the main problems I’ve found is that I often have to admit that although we can comply with some really useful Level AAA guidelines, we won’t actually get Level AAA compliance across the whole website.

Level AAA websites are rare because of a few guidelines that rule out a large number of websites. Unfortunately this creates a cultural problem where Level AAA isn’t considered a worthwhile investment. That’s a shame, there are some very useful Level AAA guidelines, but you have to sympathise with a business that must balance costs against benefits.

The impact of this is a sort of two-tier system, where Level A and Level AA are seen as the two important levels and Level AAA is for fanatics and government departments. This is further enforced by many laws that govern accessibility using Level AA as their benchmark.

How should we approach Level AAA?

My philosophy for complying with WCAG is always the same – aim for Level AA plus all Level AAA guidelines you can reasonably meet. Really, claiming a certain level is meaningless. What matters is your website is the best it can be for all your users.

The Level AAA guidelines are a mixture of essential elements and rare species. Here, I’ve ranked them in groups and described their impact

Achievable with impact

  • 1.2.8 – Media Alternative (Pre-recorded)
  • 1.4.6 – Contrast (Enhanced)
  • 1.4.7 – Low or no Background Audio
  • 1.4.8 – Visual Presentation
  • 1.4.9 – Images of Text (No Exception)
  • 2.2.3 – No Timing
  • 2.3.2 – Three flashes
  • 2.4.8 – Location
  • 2.4.9 – Link Purpose (Link Only)
  • 3.2.5 – Change on Request
  • 3.3.5 – Help
  • 3.3.6 – Error Prevention (All)

May not be realistic

  • 1.2.7 – Extended Audio Description (Pre-recorded)
  • 2.1.3 – Keyboard (No Exception)
  • 2.2.4 – Interruptions
  • 2.2.5 – Re-authenticating
  • 2.4.10 – Section headings
  • 3.1.3 – Unusual Words
  • 3.1.4 – Abbreviations
  • 3.1.5 – Reading Level
  • 3.1.6 – Pronunciation

Unlikely to be possible

  • 1.2.6 – Sign Language (Pre-recorded)
  • 1.2.9 – Audio Only (Live)

As you can see, most Level AAA guidelines are achievable and provide a clear benefit to users. Some may not be realistic depending on budget and technology. Only two are rarely achieved.

There have been huge strides in educating business owners, developers and project managers about web accessibility over the past decade. What we need to do now is knock down this artificial barrier that has crept into people’s minds over Level AAA. Yes, few websites can claim Level AAA compliance at the moment, but many Level AAA guidelines are realistic targets which help people.

Next week, I’d love to share a list of the best Level AAA websites out there – share your favourites in the comments.