The website accessibility process: key steps for every project

Deciding to develop your website to conform to the Web Content Accessibility Guidelines (WCAG, pronounced “wickag”) is a positive move that will allow more visitors to consume your content and will help meet impending legal requirements. But how do you get started? What steps do you need to take to make your site more accessible and ensure it stays accessible?

We here at Mugo have helped many teams navigate the website accessibility process. The following outline can help you navigate the process.

When to start

Before we start the process, we like to first explore what are your big picture plans for the website in general. If you have an existing website, is a website redesign pending? In this case it might make sense to audit your new designs for accessibility issues from the beginning. Or if you are switching to a different website platform, you could tackle the website accessibility issue in parallel. In both cases, you benefit from a more efficient process and a potentially advantageous point in your organization’s budget cycle.

Getting everybody on board

A website accessibility project requires commitment from all levels of your organization. It’s imperative at the start to get buy-in from all levels. Each department will have different levels of motivation and enthusiasm for this project.

Product owners will want to know that an accessible site will bring more visitors to the site. If your site is currently not accessible, fewer users will be able to enjoy your content.

Designers need to consider accessibility when producing page layouts. All users will benefit from cleaner, uncluttered pages with easy to read text.

Developers need to adjust their workflows and understand how the code they are generating interacts with accessibility tools. Accessibility requires added scrutiny of the HTML, CSS, and JavaScript that your CMS is outputting.

Executives control whether or not this is a project they’re going to fund. It might be helpful to point to the relevant legislation in your jurisdiction, or how an accessibility website supports your organization’s mission. Many publicly funded North American websites are already required to, or will soon be required to conform to the WCAG 2.0 Level AA guidelines. Europe has similar legislation in force or imminent.

Here’s a bottom line constant: More users spending more time on your website helps to achieve your organization’s goals, whether that’s revenue, education, awareness, or some other metric. Read our article on why an accessible website benefits your business.

Scoping the project

Once your stakeholders have agreed that accessibility is a worthy pursuit, we like to perform a preliminary audit of the existing website or designs. This is a high level review of the website to get some idea of the scope of the project.

What level of accessibility are you targeting?

This question can usually be answered by examining the existing or impending legal requirements in your jurisdiction. Most regions require or will require WCAG 2.0 Level AA. Although WCAG 2.1 has been recently released, this version has not been indoctrinated into any law at the time of this writing. You might still wish to review WCAG 2.1 to take a forward-looking approach.

State of the existing website

Are you able to define the main page types on your website, and is there a clear definition of where your website starts and ends? From there, we can do an initial assessment of the following:

• Can the layout be navigated with only a keyboard?
• Does the general theme meet contrast standards?
• Does the HTML appear to be well-formed?
• Do the images have proper “alt” text? 
• Are links formatted consistently and correctly?
• Are there skip links?

Identifying potentially complex problems

Does your website have any features that are normally difficult to address?

• If your website has a lot of audio and video, you’ll need captioning and transcripts.
• What sort of widgets does your website use? If you’re using third-party tools for widgets such as carousels and modal pop-ups, sometimes these tools can be upgraded or modified appropriately. However, different tools might need to be created or sourced.
• Does your website make use of a lot of forms? Proper form validation is a common conformance issue.
• Does your website have a large library of images? Most images (depending on how they’re used) will need appropriate alt text, and it might be a big project to populate this for existing images.

Available budget

There are 2 major aspects to consider:

1. Full audit of the website
2. Remediation of the issues outlined in the audit

If there isn’t enough budget for both audit and remediation, you might consider budgeting for the audit and then deciding if there is enough budget for addressing the issues uncovered by the audit. A full audit will aid in determining the budget for remediation, which can be done in phases or delayed until sufficient funds are available. You might consider trying to reach WCAG 2.0 Level A first, or a subset of Level AA as an interim milestone.

Making sure you have the internal resources to complete the project

You might have to hire a third party to audit your website, but do you have the staff to complete the remediation? If you have a development team that knows the code well, then they are often best suited to implement the changes necessary, as long as they can handle the work alongside any other projects. When we provide an audit, we include tips on how to remediate each issue and we can be available to support your developers.

Some issues also require help from outside of your development team, such as populating image alt text, and rich media transcripts and captions.

Full audit

Once we have a general project plan in place, we can start the full audit of the website.

Content assessment

We start by identifying what to audit. Websites usually consist of distinct types of pages and elements. These page types might include:

• Articles
• Category landing pages
• Media pages
• Forms

If your website has hundreds or even thousands of articles, it’s not practical to audit each one. These articles will have common elements such as the way links are used and displayed, size and colour of text, how images are embedded, and how headings are styled.

A good way to develop this list of elements to audit is a guided tour of the website by people intimately familiar with all aspects of the website.

Technical review

Our list of pages and elements will be subject to a technical review. We do this by employing tools that provide a report of accessibility errors on the page. These reports do sometimes give false positives. For that reason, we have to carefully review these automated reports. These tools are best used to reveal problems with the HTML, such as unclosed tags, that will need to be addressed.

Experiential review

The tools used for the technical review do not catch all of the issues. To get the most complete picture of the site, we need to experience the site with the tools used by people with disabilities.

Keyboard

Each element on each page of the website must be accessible via the keyboard only. Using only the keyboard, we navigate the site. What’s hidden from the keyboard? Can I clearly understand where I am on the page? Can I invoke buttons and follow links?

Screen reader

If a visitor to your site has difficulty seeing or has comprehension issues, they might use a screen reader to consume the content on your page. These are tools that read aloud your pages. We use a screen reader to determine if the page’s content and interactivity is properly communicated audibly to the user. 

Final report

The WCAG reference page provides a list of all criteria to be assessed. Our report document will report on any failures of these criteria in the form of an “issue”. Each issue will explain the failure and have one or more suggestions on how to remediate the problem.

Audit review

We find it useful to review the audit with the client. Each issue that we’ve discovered is reviewed and explained with your team.

The audit will provide the basis for assessing the budget for remediation. We will consult with your team to establish any risks of cost overruns during remediation. It is important that editors, designers, and developers be represented in the audit review to better understand the impact of the required changes. This is a great time to begin training your team as they will be doing most of the remediation. Viewing issues related to real examples in the context of your website will help introduce them to the general principles of accessibility. 

Remediation

Time to roll up those sleeves. Every issue in the audit will be converted into a ticket where progress on the issue and testing of the issue can be tracked. Each issue will be assigned to an editor, designer, or developer or some combination of these resources. Noting what team is responsible for which issue will help schedule out the remediation around the availability of these teams. Some of the work may be dependent on others, while some issues can be done simultaneously. For example, editors can get to work on descriptive alt tags while developers can change the image templates to ensure the alt tags are properly implemented.

One of our clients had a massive number of images that needed alt tags, so a creative solution (crowdsourcing) was needed to keep that issue within the budget. This process was completed on a stream completely independent of the rest of the remediation.

There may be some hard dates to consider such as legal requirements. Time-sensitive budgeting constraints may also play a role. Will the remediation take place in the current fiscal year or a future one?

Testing and more testing!

Each change must be properly tested. It’s important that each member of the remediation team be able to test their work using the appropriate tool. If you are a designer working on colour contrast, then you will need to be able to use a tool to verify your work. If you are a developer, you will have to become familiar with using the keyboard and a screen reader to test your changes. All changes can be tested by the auditors.

Ongoing maintenance

Accessibility is an ongoing commitment. Bravo on getting this far and making your site accessible. But as new content and features are added to your website, new issues can arise. There’s lots you can do to efficiently preserve your hard work.

Committing to accessibility starts with ensuring that your team has the resources to maintain it. With proper preparation and training, this should not be very impactful to your overall budget. The key is to put your whole team on notice that every change made to the website must take accessibility into consideration. If this becomes part of your corporate culture, it will be second nature for:

• An editor to write a proper alt tag for an image
• A designer to create colour schemes that meet contrast minimums
• A developer to test new templates with a screen reader

Involve as many people as possible from each of these disciplines during remediation. Stress that this is not a one-time exercise but the new normal. Provide them with the tools they need to maintain accessibility standards. Accessibility should become part of the regular training for new designers, developers, and editors. Product owners and project managers will need to make sure content changes are audited for accessibility. 

Accessibility statement

An accessibility statement is not technically required for WCAG conformance, but it is nonetheless an important addition to any site striving for accessibility. This is a page you should add to your site that is available from anywhere on your site, for example in the main menu or footer. You can use this page to communicate your commitment to accessibility, and can share your journey with the public. You can list the browser / screen reader combinations for which you’ve developed and tested. Perhaps you have reached WCAG 2.0 Level A, but you are planning to get to Level AA. Maybe there are some pages on the site that you have not yet addressed. It’s possible your site includes widgets where you don’t control the accessibility, for example a Twitter feed. All of these can be documented in the accessibility statement.

Internet for all

The path to accessibility is not a trivial undertaking, but it is a worthy and potentially required endeavour. We’re here to help you navigate this rewarding process!