A Little Book of Accessibility

Quips, tips, affirmations, and truths that have helped me shape organisational accessibility strategy and culture over the years.
Posted by Gareth Ford Williams, on .

If I had a TARDIS and could travel back in time to 2005, which is when I founded the BBC’s Digital Accessibility Team, what would I say to myself? What advice would I give me?

This is a little book of quips, tips, affirmations, and truths that have helped me shape the BBC’s strategy and embed accessibility into its culture.

BTW I have published this as an article, a presentation, a video and a set of posters only. There is no book… so please don’t go looking for one.

This article was originally designed as a deck of presentation slides for GAAD 2021, so for anyone using a screen reader to access the article, each of the images is one of the presentation slides, and the main quote is contained in the alt text. The copy after the image relates to that text.

There are many useful resources that I wish had been around in 2005. WCAG was a good starting point but you had to pick and choose what was relevant and add context and scaleability to the more subjective sections. This is why the BBC decided it would take WCAG and build its own guidelines that could be pertinent to what the BBC was building and researching at the time.

We also had the Nielsen Norman Heuristics to work with, they were written in the 1990s from a neurotypical perspective and although they are still relevant, they are not as complete as they once seemed.

I think it would be fair to say the resources at hand in 2005 were at best three years behind the industry requirements, were not developed for any organisation aiming to deliver at scale, and the advancement of user and production technology was quickening.

If I had one wish for a resource, it would have been having the Inclusive Design Principles to hand. We were feeling our way around most of the concepts included in them, but it was going to be several years before they were published.

So here’s the Little Book.

Words #

Everybody, anywhere, community, diversity, universality, usability and inclusion are all words that depend on accessibility

Finding the language of accessibility within any organisation is tricky. “Accessibility” is a loaded word which can work both to its benefit and detriment. It can help contextualise problems for particular user groups, but it also can foster the sense and culture of ‘otherness.’

The BBC’s organisational ethics were clear, but I still needed to explore the language to make sure accessibility wasn’t treated as additional to the mainstream, but discussed as part of the mainstream.

20% of the United Kingdom’s population has a disability, so the audience is significant size, and words like “Everyone”, “Diversity” and “Inclusion” were littered throughout the organisation’s policies, strategy, statements and executive speeches.

None of these words are caveated with “except them” when it comes to disability and as such none of the associated objectives could be realised without accessibility.

Games #

Games and media are social currency, so don’t actively leave anyone out of the conversation

People like to talk about their shared experiences and if a group of children or adults have all played the latest game or watched a programme, but that excluded someone because of their impairment, they will not only be left out of the fun but will also be left out of the conversation afterwards.

So if you are developing a content proposition, ensure that the approach is an inclusive experience that avoids socially excluding anyone.

Worthwhile #

Invest enough time to shift the conversation from ‘worthy’ to ‘worthwhile’

This is one of the hardest and most necessary cultural challenges for any organisation.

An epiphany comes when an organisation realises that instead of building things and trying to make things accessible, the most efficient and effective thing to do is to build accessible things. Accessible things take no more time and effort to build than inaccessible things, in fact they take less time as you don’t have to fix them afterwards.

Then there are the benefits.
There is a lot of research that proves accessible products and services increase audience reach & share, create more engagement opportunity, improve usability for everyone and increase customer loyalty.
Accessibility positively impacts on the robustness and universality of products, and improves overall brand perception.

All of these are not ‘nice to haves’ in business, they are worthwhile, and are all outcomes of accessibility if it is managed correctly. So why not invest in them?

Opinions #

If you cannot guarantee you have everyone’s opinion, you can’t make decisions that will benefit everyone

If any part of your audience is not able to participate in your research either because of the approach, platform or methodology then you are always going to have skewed data.

As disabled people make up at least 20% of any audience, that is a huge number of opinions and data lost that would otherwise be invaluable to your organisation, especially if it cares about informed decision making.

Demographics #

Marketing demographics are not useful for design research. Insight comes from focusing on human characteristics, contexts and barriers.

I am a 50 something-year-old white male, from the north of England with specific interests and habits. None of that has any bearing on how design choices impact on my experience of a product, yet this data is often gathered on projects where there is little information on user characteristics or barriers experienced.

Even when it comes to capturing data on medical conditions, this is still fairly useless as it tells researchers very little about the lived experiences, skills, coping strategies and capabilities of a user group.

As a result data that could have been full of rich intersectional insight, ends being disappointing when it comes to recommendations and outcomes.
So look for better ways of drawing out information about users that has relevance to behaviours, skills and traits.

Data #

Data is not the plural of anecdote

Stories and personal testimony are incredibly useful, but mostly for understanding potential barriers, coping strategies or forming hypotheses. One thing an anecdote will never give you is an answer.

Although there is always the caveat that 100s of independently sourced and verified anecdotes or interviews do provide evidence… but qualitative studies almost never run at a scale to be considered statistically significant.

And yet time and time again I hear anecdotes being presented as if they were data and irrefutable fact. They can even get upgraded to “conventional wisdom” and become very difficult to shake off.

Culture #

Accessibility culture eats WCAG compliance for breakfast

The simple underlying truth about accessibility is that it is all about organisational culture, and culture comes from the top.

As an accessibility manager one of the key responsibilities is to not just find the rhetoric, but also identify the willingness to believe in it, and nurture that into widespread cultural practice.

There are many ways to do this but one that can be especially effective is the establishment of an Accessibility Champions Network that amplifies your organisation’s ethics and mission.

Emotion #

“Accessibility is Emotional as much as it is Functional and Technical”

The ‘three components of accessibility’ that Bruno Maag talks about are something we can all understand. Everything has an emotional resonance, has to function because after all this is design, and needs to technically work.

This is something that is all too often missing from conversations as Accessibility works in lasting and meaningful ways when you find the balance between all three.

A couple of extra tips:

Mainstream #

Accessibility is already mainstream as it is both Environmental and Situational

Some of us have lifelong conditions or impairments which means we have certain dependencies on UX or technical approaches, but from a more universal perspective accessibility reaches beyond the user because impairment can be caused by environmental factors or situations.

Here are some examples to get you thinking:

I can’t take credit for thinking about this as Molly Ford-Williams got me thinking about this before she did her #ID24 presentation in 2017, Go Hack YourSelf.

So look at your research. Think about when and where people are using your products and services, and explore how this data can highlight transient mainstream accessibility issues.

Sin #

The one and only cardinal sin in (UX)design is not designing for the reality in which people live

This is probably my favourite quote from the product designer Dieter Rams. There are so many layers to this statement.

Understanding user contexts takes into consideration both the wide variation of users and the breadth of situations they find themselves in. This then should feed into the approach you take to your design research.

Recruit according to demographics, so if 20% of the population is disabled and 15% is neurodivergent then that should equally apply to your participant group.
Then run you research in real life situations and contexts focusing on human and environmentally specific barriers.

Exclusion #

Inaccessibility is proactive, so at the beginning of a project it is important to get the team to ask the question, “who are we willing to exclude?”

This is such a useful exercise when it comes to establishing ground rules at the start of a project and ensuring accessibility is not de-scoped or differed (which is essentially descoping).

The question seems loaded at first, but when you settle down with it you’ll find it’s rather useful, and can be helped along with both marketing and design research data.

For instance, if you were designing a news application you might not want to be actively include the under 5s. That’s not to say you will be actively excluding them, but the service might obviously not be for them, unless of course you are designing a children’s’ news service.
Other groups might be determined by geography, platform, language, situation… all sorts. What you will end up with is a very useful list.
Then all you have to do is to make sure that during the process of designing and developing the product, you don’t start adding to that list.

Do Not Disable #

Ensure your UX Design does not disable your customers

One key thing all UX Designers should understand is the Social Model of Disability. This is absolutely fundamental to being able to get UX accessibility right.

The social model points out that, “people are disabled by barriers in society, not by their impairment or difference. Barriers can be physical, like buildings not having accessible toilets. Or they can be caused by people’s attitudes to difference, like assuming disabled people can’t do certain things.”
As a designer, every decision you make either retains or excludes users. When a product is just a concept then everyone has equal access, but as soon as we start to shape the product that is when disability is either kept out or designed and engineered in.
This goes back to the point about inaccessibility being proactive and the “reality in which people live”, if designers aren’t mindful they simply filter out more and more users through their choices.

Accessibility simply isn’t something you add to a project, not unless you are planning to break the UX of your product as part of your product development process. So if you find your teams are regularly re-factoring designs after accessibility testing, then support them with better training to help them develop inclusive practice.

Alt Text #

The person writing the alt-text should be the person who chose the image in the first place

There are right ways and wrong ways to approach the production of image alt-text, but there is one desired outcome, for everyone to understand the purpose of its use.

Alt Text must convey the editorial intent of the use of an image.

I’ve paraphrased, but if you are designing comparative experiences for both sighted and vision impaired users then aim for equivalence of the information and outcome. So if the image is an infographic that conveys a key point, summarise that point, or if it is brand furniture, in other words it is just there for aesthetic purposes, then it can remain silent. But if it is a logo, then just say the name of the brand it represents, because that is what it conveys.

The production of the text then boils down to three groups:

Videos #

Script your videos as if there were no pictures, and then add pictures

There are four access services for AV media. Captioning, in-vision sign interpretation, audio description and the other one that no-one talks about… bi-media production. Never heard or it? That’s because it is invisible to all users.

Rather than bi-media being an additional programme asset, it is a production ethos that makes content accessible without Audio Description by scripting or presenting as if there are no pictures.

AD can then be added to content where there is action or image that can not be described within the narrative.

There is the common misconception that all AV content has to have Audio Description to be accessible, but if it’s scripted using the bi-media methodology, then most of the content will be perfectly accessible in its default state.

Certain content types such as reportage, interviews, panel shows, music programming and live events lend themselves nicely to this approach. BBC TV has been using this since the 1990s so it can be used for online AV production.

So next time you are scripting a video, write a radio script and then film it.

Captions #

Captions, mouths and information graphics need safe zones

It’s one thing to caption your content, it’s another to have a designed quality experience. The UX of captioning is really important as it is a reading experience that conveys more than just the words.

But beyond the choice of font and sticking to good typographic practices it also has to work in context of the core visual content.

There are 3 core hearing impaired caption user groups:

The lip readers will not appreciate captions covering mouths and all three groups need access to any onscreen graphical information which might give additional context to any spoken content.

Both of these considerations are key to comprehension, especially if the captions cannot be guaranteed to be 100% accurate. So think about how you compose your shots, making sure mouths are above where the captions will go, and also think about graphic layout that accommodates caption usage.

Common Knowledge #

Take the time to understand the reasons behind common knowledge and convention

This is something I learned the hard way early on in my accessibility career and I think my epiphany came when I started to investigate font accessibility. There is more misinformation about the readability and legibility of fonts than anything else I have come across.

The days I have wasted on projects based on “conventional truths” that subsequently fell apart is probably my biggest regret.

We all want to fix things and can all too easily go into solution mode before we have taken the time to ensure we are asking the right questions and thoroughly checked the sources that informed our decision making.

BBC GEL Tech Docs is a great example of this done well.

Affordances and Conventions #

Affordances and conventions are the cornerstones of cognitive accessibility

What are affordances and conventions?

An affordance is a perceived way in which an element will behave when interacted with. A web convention is an established design norm that users expect websites to follow.

Both conventions and affordances help create a user’s cognitive schema so that they know where to expect to find certain kinds of information, what the function of an elements is, and what they expect to happen when they interact with that element.

Not being mindful of this introduces risk and can negatively impact on the experiences of all users.

Something that is worth considering is to try and identify users with particular cognitive barriers in your research or user groups. What will be a poorer experience for most people could be a barrier for them. They are the canaries in the Design Research mine.

Fonts #

Font performance is the foundation to visual accessibility

This is such an obvious statement. There are lots of guidelines about what to do with a font when you have chosen it, and even more misinformation about how to choose one.

This one foundation of UX Design that has only recently been tackled but not choosing an optimal font and then trying to apply accessibility guidance to it is like putting “Accessibility Lipstick on a Usability Pig,” as Jared Smith said in 2014.

So take time to understand the fundamentals of font accessibility, research the options, test if possible and make the best choice available to you.

If you are a UI designer then understand more about the function of reading, which will enable you to make decisions that balance the needs of the user, the platform and the brand.


“HTML is screen reader UX” —Ian Pouncey

This is a very straightforward observation made by Ian Pouncey on “How to Make an Inaccessible Website”.

There is belief amongst many designers that they don’t need to know how websites are made because that is the responsibility of the Developers. That is like architects not understanding the fundamentals of structural engineering. Website designs need to be buildable, and the way the code behaves impacts on the UX, so UX needs to determine the behaviour of the code.

For screen reader users this is a particular issue as their UX is not a visual interaction manifestation of the code, but an audio one that exposes more of the structural design of the code itself.

This means that how a page is coded is both a UX and technical concern. There are decisions such as semantic structure, tabbing orders and the visual and audio behaviours of designed elements that should be designed experiences. Sophie Beaumont describes this nicely in her blog about BBC WebCore.

It’s also useful to think of HTML as having a moral code, this will enable you and your teams to frame any discussion about the ethics of a particular technical framework from the perspective of delivering an inclusive user experience.

Heydon Pickering highlighted the empathy gap by changing his Heydon Works homepage in 2021 to only work with JavaScript switched off. The indignation from a significant proportion of his Twitter followers, who are developers and didn’t know how to switch off JS in their browser. Many couldn’t make the simple connection between the technical choices they like to make and how those choices could be discriminatory.

So whether you are a designer, a developer or a software engineer, at the end of the day it is all UX to someone. The BBC’s Guide to Accessible HTML Documents is good resource to better understand what accessible HTML looks like.

Compliance #

“Compliant” is not an answer to any other question except “Is it compliant?” —Gareth Ford Williams

Without getting into the reasons why, compliance is good. Yes it is good because what it take to be compliant is pretty sensible stuff, but at the same time you have to recognise that compliance does not answer the question, “is my product accessible to disabled users?”

But it will keep your Compliance Officer, Policy Team and Lawyers happy. If you have compliance as an objective make sure you only look at it as compliance rather than thinking it is an answer to all your accessibility problems.


WCAG is:
A foundation
not an answer,
A benchmark
not an ambition,
A resource
not a tool,
A work in progress

In WCAG there are different levels, A, AA and AAA. It’s clever as everyone will go for AA as nobody wants to do the really difficult stuff in AAA and A is the equivalent of buying the house wine on the menu.

The problem comes when an organisation’s accessibility model matures. That is when guidelines should be something not to fall below rather than something to achieve. And the guidelines should evolve as more is achieved, otherwise your accessibility programme could stagnate.

WCAG is also not the easiest thing to use. Although that is something that really cant be avoided as it has to balance being as comprehensive as possible while remaining organisationally agnostic.

Auditing #

Auditing answers three questions only:
Where are we now?
How far have we come?
How consistent are we?

Health check audits are really useful as they give an idea of where deeper investigation is needed. They can tell you where you need greater consistency, so for instance an audit of labelling conventions is useful.

Pan-estate audits or monitoring can also help identify teams who are particularly struggling and need more support. Audits can also illustrate ongoing improvement over time to your executive committee, if done at annual intervals. But the one thing audits do not do well is being part of a product development process.

A product usually goes through three phases:

Shape → Build → Run

But adding auditing you get:

Shape → Build → Audit → Re-shape → Re-Factor → Run → Audit → Re-Re-Factor → Run Again…

Which isn’t efficient, effective or sensible, particularly in an agile environment.

By focusing on a more embedded approach to accessibility you can utilise your auditing resource in a way that makes it productive and progressive rather than disruptive.

Tools #

Build accessible sites from accessible components, and cut your workload in half

One of the core functions of any accessibility team is to make accessibility possible, scaleable and sustainable. The team needs to work with the business to provide resources that contextualise accessibility and make it easy.

If you have a UX component library then you need to ensure that everything in it can be built accessibly, then deliver technical documentation that takes the design library and expresses it in a way that was more meaningful to developers.

These documents should contain; reference implementations, research resources and test scripts that focus on defining the behaviour of the code rather than determining the code itself. They then need a community or guild to ensure they become living documentation that stay relevant.

Inspiration for this came from Heydon Pickering’s Inclusive Components. We liked these at the BBC so much we ended up working with Heydon on BBC GEL Technical Documentation, which is a resource that takes the BBC’s design guidelines in GEL and documents them from a technical perspective.

We tried to deliver an accessible JavaScript framework BBC Glow, but that was killed off through politics, ignorance and a light sprinkling of stupidity whilst I was on attachment to the YouView product team. This was the one that got away.

Machines #

Machines benefit from accessibility too

This is just a reminder to all product managers about what accessibility does beyond all the obvious user benefits.

So when you are considering the business case for accessibility, consider all the technical benefits as well as the user benefits, and if you take a component lead approach, then you’ll make it even easier to achieve.

Evidence #

Evidencing compliance is the concern of a vendor, whilst evidencing equivalence is the concern of an employer

Many organisations declare themselves as being inclusive employers to both disabled and neurodivergent people.

Fantastic organisations like Disability:In, Valuable 500 and The Business Disability Forum have memberships that are trying to make that commitment, however actually delivering inclusive employment in an effective way means a few considerations.

Actually delivering inclusive employment in an effective way means a few considerations. There are obvious ones like ensuring the employment processes and corporate communications are accessible, as well as making sure there are workplace adaptations and other such reasonable adjustments.

However there is one area that remains problematic and that is the digital environment.

Legislation in the EU and the UK is behind the US in this respect as it demands compliance whereas Section 508 also focuses on usability. Section 508 is exactly right. A procured system can be fully complaint and yet the experiences of its use between disabled and non-disabled users can be far from comparative.

For example if a taxi booking system could take a sighted member of staff 5 mins to complete a booking but an assistive technology user 20 mins, where are they expected to find the additional 15 mins?

Are they expected to work later, have less breaks or simply be less productive?

The compound affect of multiple unusable systems is that you’ll design and engineer people out of the jobs you have made available for them.

Policy and Statement #

Your accessibility policy captures how far you have come Whilst your accessibility statement sets out how far you intend to go

Accessibility policies and statements are often mixed up and become rather confusing to read, and it can become difficult to identify which is a commitment to maintain and what is an intention for improvement.

A statement is useful, especially if your are in the early stages of your organisation’s accessibility journey. It should build on and contextualise and existing mission statement and be self-aware of the improvements needed.

A policy however should not be an ambition but a reflection of everything that your organisation does and can continue to do in terms of accessibility.

It should be high-level but broad enough to benchmark all your core activities and values. Keep ambition out of your policy and say, ‘this is where we are today because this is what matters to us.”

Policies are also useful as they both tell teams what is expected of them and users what to expect. If the policy is clear, then product team’s output and audience expectation should align.

The BBC’s Digital Product Accessibility Policy is very clear whilst their BBC for Everyone video is more about intent.

Magic Wands #

There are no magic accessibility wands…
so be suspicious of strangers bearing gifts and big promises

To round the book off I’m finishing with a warning about anything that presents itself as too easy to be true.

If a wall has a big hole in it, putting paper over the hole might cover it but it does not make the hole go away. So if anyone tries to lean on it or hang a picture, you are back to having a hole again.

The same can be said for accessibility plugins. They are a brittle veneer to a problem that never provides a solution beyond something temporary and aesthetic.

Are they better than nothing? Maybe the effort and money invested in them spent on doing something more robust is a better approach then trying to sweep accessibility under the plug-in carpet.

Conclusion #

Accessibility is a broad subject. It positively impacts everyone. It is full of opportunity. It is as much about emotion as it is about function, and compliance alone will not give an organisation or its users what is needed.

But there is so much opportunity if you take the time to ask the right questions.

There is a set of posters to accompany this article. Perfect for outside elevators, kitchens, printing rooms, behind toilet doors and studios.

To help you on your accessibility journey, you might find the following resources useful too. All of which I or my team have had some involvement with over the years, except the first one which is a project I wish I had been involved with.

Resources #

Images in the article are courtesy of HeritageType.com and The British Library