A quest to make inclusive web practices ubiquitous

The start of this quest begins by the admission that I am ashamed. I have been for some time. In the 20-plus years I have been creating websites I have treated accessibility as an “if requested” requirement. I have taken the attitude that it is OK to focus on the majority of users. I was willing to accept that it is too hard and too expensive to get it right.

For the last few years I have been determined to make this a priority for all of our work. It is my ethical obligation to take an inclusive approach to my work. I still have a long way to go, but it is worth it.

I’m not alone. The majority of the web is not inclusive.

I am far from alone in this. We (the people involved in creating websites) are not doing a good enough job. We are way off and the numbers prove it. Awareness is slowly improving, but the state of web accessibility remains frustratingly poor.

In the UK, the Business Disability Forum’s e-check service says that 70% of websites present significant accessibility and usability barriers to disabled users. Imagine only having access to 30% of the web.

In 2014 Vivienne Conway published her thesis on Website accessibility in Australia and the national transition strategy: Outcomes and findings.

Her research concludes that “very few organisations succeeded in meeting even Level A of WCAG.”

What can we practically do about it?

To start answering this question, I stand on the shoulders of giants who have been writing on this topic far longer than I have. I have leaned on their collective wisdom to help articulate my thoughts. I want to join them in their quest to make the web inclusive.

The plan goes like this:

Make people care about accessible and inclusive design

Most people do not care enough. From my experience accessibility is seen as a problem of a minority that is not valuable enough to place the effort to address.

So how do we make people and organisations care?

• Our day-to-day work comes with an ethical obligation
• Adjusting how we frame accessibility
• We shouldn’t need a business case (but sadly we do)

Guiding principles to focus our actions

• “The why” and “the how” of accessible and inclusive design

Coherent actions

• Building accessibility into processes as a priority
• Keep building awareness

Our day-to-day work comes with an ethical obligation

Anyone who plays a role in creating websites — including designers, developers, writers, testers, content editors and managers should care about accessibility. We need accessibility experts to lead the way and guide us, but it is not their sole responsibility to shoulder the load. It is our shared responsibility.

We should be ashamed of the current state and we can do better. Ignoring accessibility or doing the bare minimum is not good enough. As designers, we need to be better. It is our ethical obligation to not exclude people from using the web.

The people who need us the most require the best of our design. Pattie Moore — the mother of universal design

For some, the ethical obligation is enough. The majority of our industry sits somewhere between ignorant and comfortable with leaving it in the too-hard-basket. I am guilty of this too! It is too easy to de-prioritise accessibility. It becomes a sacrificial line item in a budget. Doing the “right thing” on its own is not compelling enough. Sadly, as a society, we are more inclined to pay attention to penalties and rewards. The leaders in accessibility are government websites (although even government has a long way to go too).

A designer is responsible for the work they put into the world. Mike Monteiro — Designer’s Code of Ethics

Google declares that accessibility is an important ranking factor. (Well it’s not yet, but it should be!)

If Google announced this, people would pay attention! Over the years Google has made some big announcements that whips us into shape. Many of these also contribute to improved accessibility.

• Google announced they would be making algorithm changes to favour mobile-friendly sites. Almost everyone responded.
• Google declares running your website over SSL is a ranking factor. Now Google Chrome will identify your website as insecure to users. We are responding.
• Page speed becomes a ranking factor. We pay attention and respond.

Google declares new ranking factors and our industry pays attention. Response happens. Google also build tools to support the change and it helps us respond. Google is starting to show a little more love for accessibility. Google Lighthouse launched in 2017, embedding accessibility into its Chrome developer tools. The tools will only have a limited impact on their own.

When this day comes, it will be a major step forward. (Digitally altered photo)

Right now change is not fast enough. If Google announced accessibility as a ranking factor, it could bring the supercharged focus we desperately need.

Adjusting how we frame web accessibility

Wikipedia defines web accessibility as follows:

Web accessibility refers to the inclusive practice of removing barriers that prevent interaction with, or access to websites, by people with disabilities. When sites are correctly designed, developed and edited, all users have equal access to information and functionality.

I like this definition. It makes sense to me. I believe it’s important that accessibility maintains its focus on providing for the needs of people with disability.

I especially like that all users have equal access. This helps move the conversation beyond disability. Accessibility then becomes an even more important problem to solve and creates opportunities for innovation. It makes putting effort into accessibility more appealing.

Inspire designers with stories

We should not underestimate the power of stories to inspire us and make requirements and checklists into something real and relatable. Below is a story that inspires me…

Curb cuts were originally designed to cater for wheelchair users. It just so happens that people pushing prams and trolleys, skateboarders and bike riders all benefit from curb cuts. A footpath with a curb cut is a better designed footpath. An intangible and surprising benefit of accessible design we take for granted every day.

An accessible design is a better design

There are many intangible and surprising benefit stories when it comes to the web too. It is our job to share these stories.

Accessibility is a pre-requisite for usability

You can only use a website that you can access.

Accessibility practices provide improved usability for all users, not only people with disability.

This overlap with usability is where designers and product managers need to focus our communication. The reality is more people care about usability than accessibility. Decision-makers regard usability as a non-negotiable — an expected minimum. Accessibility is often only a consideration for government and not-for-profit organisations that have inclusivity built into their core values.

Framing accessibility in the context of usability gains helps give it a larger share of attention

The social model of disability

The social model of disability talks about removing barriers. It is not a person’s impairment that causes disability. It is the way society is organised around peoples varied abilities that is the problem.

A physical world example is installing ramps to provide better building access.

A digital world example is to provide high enough colour contrast to make it easier to read content on a screen. Older people can struggle with low contrast, people with colour blindness too. You may have perfect vision, but reading content on a phone with the sun glaring on the screen is tough. This is only one example of a barrier for many people. Disabled or not.

The point is, we all face barriers at some point. Accessibility and inclusive design principles benefit everyone. That is the message we need to send. It is a strong place to start a business case.

The W3C Web Accessibility Initiative (WAI) describes it well:

The Web is fundamentally designed to work for all people, whatever their hardware, software, language, location, or ability…

… Accessibility is essential for developers and organizations that want to create high-quality websites and web tools, and not exclude people from using their products and services.

(Side note: The WAI have launched a great new website with some great resources. I recommend taking a look).

Here are some more examples of the wide appeal of accessible and inclusive practices:

Plain English is better for everyone

44% of 15 to 74-year-olds have a literacy level 1 to 2 and struggle to complete basic forms or grasp text. Clear and simple writing beats complex and wordy writing. We all prefer it.

The argument that writing in plain English is dumbing things down does not hold. Even subject matter experts prefer and trust content that is easy to digest.

Website accessibility and mobile device optimisation share a lot in common

Mobile phones are now the number one device for browsing the web. Getting web accessibility right helps provide a better mobile experience. For example, not relying on a mouse is good for both mobile users and people with motor disabilities. This extends to many other devices types. Tablets, smart watches and digital TVs to name a few.

Performance (page speed) and support for low bandwidth users

Fast websites are an important accessibility factor, particularly for low-bandwidth users. Not only that, users are more likely to leave your site if they have to wait for a page to load. Google has also announced that page speed is an important ranking factor.

Video transcripts and captions have loads of benefits

Video transcripts provide access to people who are deaf or hard of hearing. The benefits do not stop there. They also help when audio is unavailable or in the many situations when you need to mute the sound. There is also the SEO benefit of allowing Google to index your video content as text.

I could go on.

The Web Accessibility Initiative (WAI) has compiled a nice list of benefits worth taking a look at.

The more we frame accessibility as a winner for a much wider audience, the stronger the business case.

A competitive and innovation advantage

The case against accessible design is usually one of cost vs benefit. The effort is too high to cater to “edge cases”.

When we design for the extremes, we make better designs for everyone.

The issues that are relevant to all users are most clearly visible in the extremes of the population

My first exposure to this principle was via IDEO — the designers of some of the world’s most loved products. When researching I came across Derek Featherstone’s An Event Apart presentation. He has created a toolset that takes this concept and applies it to accessibility. The premise is as follows:

“Project an extreme onto a design. Solve that problem. Improve the interface for everyone.”

Derek tells the story of a piece of work that relied on a map. It was a council website. Their boundary was changing and they needed to communicate this to their audience. The solution was a map. This seemed to make sense. People understand maps. It is a nice visual experience. Yet, the solution needed to work for people with a vision impairment. It required a fresh look at the problem. Creating a text alternative to describe the map was not going to work. This forced this team to dig deeper and re-define the problem. The problem was to allow a user to determine if the change in boundary applies to an individual. The solution was a simple form that asked for the user’s postal code. It returns a simple message explaining if the boundary change affects them. It provides a better user experience for all users.

Example from Derek Featherstone’s An Event Apart presentation. How designing for extremes produces better designs for everyone. Adding a postcode search makes it easier for all users.

We shouldn’t need a business case (sadly we do)

We need to educate industry and demand accessibility in the work they commission. Accessibility is a quality factor. A non-negotiable. Not a line item that can be de-scoped.

Karl Groves has spent huge amounts of time and effort dissecting the business case for accessibility. His core message is:

“…your specific business case depends upon your specific situation”

I have been using stories, facts and statistics to explain the business case for each clients context. In combination with explaining of the broader appeal of accessible and inclusive practices, people are starting to pay attention.

Here’s a list of some of the facts and statistics to include in a business case:

• Over 4 million Australians have a disability
• 46% of Australians have at least one parent born overseas
• 44% of 15 to 74-year-olds have a literacy level 1 to 2 and struggle to complete basic forms or grasp text
• 71% of UK web users with disability will leave a website that is not accessible to them
• An accessible website supports an ageing population
• Reduction of legal risk. It is discriminatory to make websites that are not accessible to people with disabilities. You open yourself up to litigation. Just ask the Sydney Olympic’s and Coles.
• Many accessible practices have a strong overlap when it comes to both better usability and SEO ranking factors
• For new sites, getting accessibility right from the outset is far cheaper than retrofitting later on

Guiding principles to live by

I love guiding principles. I use them as a way to summarise deep thought into a shareable and usable format. Here are some guiding principles for accessible and inclusive practices.

The why

• Accessibility and inclusive design principles benefit everyone
• Accessibility guidelines are extremely useful for anyone that cares about doing quality work.
• We have an ethical obligation to be inclusive

The how

• Build accessibility into processes
• Shared responsibility across the whole team

Building accessibility into processes as a priority

Having established “the why”, what about “the how”?

About 10 years ago, I took on a project where the client had mandated that AAA checkpoints of the WCAG must be met. To make the guidelines digestible for the team I added 3 columns: design, developer and author. This allowed the team to scan the guidelines according to their role. Every now and then, another “accessibility project” comes up, and so does the checklist. The notion of an “accessibility project” is fundamentally flawed.

Accessibility and inclusiveness need to be deeply embedded in the process for all projects! Along with all other mandatory tasks required to deliver a quality result.

Recently, we have been taking strides to do much better.

It starts at project inception.

The business case

Has the decision-maker mentioned accessibility? If not, then ensure the education process begins. Craft the unique context business case. It should explain what you will be doing and what is expected of others on the project team. Getting key activities onto a RACI matrix helps define who will be Responsible, Accountable, Consulted and Informed.

Include diverse users in your research

Don’t think “I don’t have the budget for the outliers, I will focus on the majority”.

Do think “The issues that are relevant to all users are most clearly visible in the extremes of the population”.

Use this thinking to frame the inclusion of diverse users. It is as an advantage that will provide better insights for design.

Role-based checklists and guidelines

Accessibility resources and guidelines can be overwhelming. Sifting through accessibility resources relevant to “the work I am doing today” is too onerous.

We have been extending the role-based guidelines to cover more roles (this list is not exhaustive):

• I am conducting research
• I am designing layouts
• I am coding
• I am creating content
• I am loading or editing content
• I am testing
• I am doing an accessibility audit

Here is an example of how it works for the designer role. It is presented as a checklist to assist with compliance.

Designer checklist

(You will notice there are items in the checklist that are not in WCAG. This is deliberate. Mixing general design guidelines and principles in with WCAG puts accessibility in the context of design quality).

Colour

• Do not rely on colour alone to convey meaning
• Provide good contrast between the text on your website and the background colour

Interaction

• Make large clickable actions — don’t demand precision
• People do not like interfaces that look fancy but behaves clumsily
• Provide shortcuts, especially to reduce typing and scrolling

Text and icons

• Do not use images of text
• Be careful when using icons

Assistive technology

• Full access by keyboard only
• Works with a screen reader

Design principles

• Design with mobile and touch screens in mind
• Have a goal in mind and prioritise the information
• Streamline the page design
• Offer several ways to find pages

For each item in the checklist there are guidelines with the following structure:

Item - Provide good contrast between the text on your website and the background colour

Effort - Low

Importance - High

Why it is important - It can be difficult to read the text if the contrast is poor.

How to comply -

• Use a light background with dark text
• Use a dark background with light text
• Note: Bright, contrasting colours can be difficult for people with autism (and harsh on the eye for others)

Examples - 18F Accessibility Guide — Color and contrast

How to test and validate compliance - Use a colour contrast checker to verify your colour combinations e.g WebAIM Contrast Checker

References and further reading - WCAG 1.4.3 — Contrast (Minimum)

This structure is concise and pragmatic. It is digestible and specific. The goal is to lower the barrier to entry and use a practical tool to improve the quality of our work.

Designs can be periodically checked against the list to make sure the bases are covered. If they are not familiar with how to act on an item, they can dive into the guidelines.

We still have work to do to embed the checklists and guidelines into our processes, but we have come a long way.

What gets tested and measured, gets improved

Peter Drucker (the founder of modern management), wrote:

“What gets measured gets managed”.

Metrics such as traffic, conversion rates and revenue get a lot of attention. They are relatively easy to quantify and they are important metrics. Accessibility is a part of this equation and we need to measure it to help improve it.

I like to put accessibility in context by highlighting its relationship with usability and showing how it works in with the other important metrics.

Discoverable. Do people know you exist? This is the role of marketing, social media and SEO.

Accessible and usable. Remove access barriers and ensure your visitors can complete the tasks they have come for

Conversion. Are users behaving in a way that helps us achieve our purpose as an organisation?

So how do we test and measure accessibility?

1. Automated accessibility testing tools. There are many automated tools. The WAI lists 116 tools (at the time of writing). Most of them are designed to test against WCAG. Some of the more popular products include WAVE, Tenon and SiteImprove. They range from free browsing extensions that evaluate single pages, through to full site reports. There is also the option to integrate with APIs to accessibility into your automated testing practices. Most tools will provide an overall score and/or number of issues to improve on. Included this number on dashboards with the other important metrics. Full site reports with scores and API access require a paid account.
2. Manual human review. Automated tools are great for capturing many issues, but they do have limitations. For example, they can alert you to the fact that you did not include alt text for an image. What they can’t do is assess that the alt text provided is meaningful to the user (placeholder text would pass the automated test). There are also many WCAG checkpoints that cannot be picked up by an automated tool. The tools will let you know what requires manual checks.
3. Usability testing with diverse users. In my experience, nothing provides richer insight than usability tests. This is the insight that decision-makers pay attention too. Seeing real users failing to complete tasks is powerful. Including diverse users in user testing panels highlights both access and usability problems. Accessibility then starts to become a part of the way you measure usability. The Centre for Inclusive Design can help find diverse user testing participants. We are yet to try this ourselves, but it is certainly a near future goal.

Using testing tools during the process

It is wasteful when a project has to wait until Quality Assurance (QA) to detect failures that should have been captured earlier. Just like we expect a front-end developer to cross-browser test as they code, so too should they be checking for the accessibility items during development.

Role-based checklists/guidelines plus automated tools and API integrations will make a big difference. Certainly an effort to get set-up, but worth it in the long-run.

Measuring the global state of web accessibility

I would love a way for us to get a global metric of web accessibility beyond individual studies. It would be great to have a number that sees us improve as a community of web creators. Perhaps this would be a nice side-effect of Google making accessibility a ranking factor?

Keep building awareness

Awareness of the importance of accessibility is building. Initiatives like Global Awareness Accessibility Day spike attention. Government agencies like the Government Digital Service (GDS) in the UK and the Digital Transformation Agency (DTA) in Australia are doing a fantastic job.

We all need to continue to build awareness. My aim here is to provide some practical information and tools to help on this quest.

A tough nut worth cracking

Accessibility is a tough nut to crack.

The problem I am working to solve is, “how can we make accessibility and inclusivity easier to achieve”.

As a business owner I am mindful that time, effort and resources are finite. The opportunity cost of doing this work is always going to be a challenge. Starting to educate myself has made me pay more attention.

By sharing how we are tackling the problem we enlighten ourselves and hopefully others. This is the start for me and for Lemonade. There are a lot of passionate and smart people doing great work in this area. I thank you all for the years of effort you have put in. Sorry, I am late to the party.

We will continue to develop our processes and tools. When they are in better shape I will share them for others to use and improve upon.

70% of websites present significant accessibility and usability barriers to disabled users. The ultimate goal is to reduce that number down to zero. Proving a better web for all — a worthwhile quest.