Designing an WCAG 2.1 level AA accessible website

The full story

Start with discovery

We started by gathering information about the current website. Content, performance metrics, user data and any branding collateral we could find.

The website audit revealed several issues.

Many pages were duplicated. Several web pages were grouped under “portfolio” despite being about other topics.

We also uncovered “hidden” pages that could only be found via search, or in-page links. In short, content was poorly organised and difficult to navigate.

How do you design an accessible website?

The new visual identity was designed with a broad colour palette that KPSN were keen to use. Colour contrast is core to accessibility, so one of our first tasks was to assess the colour palette.

This would help us decide on colour combinations that would be accessible and influence the design overall.

KPSN were responsible for revising the website content. While they had an initial plan, it was very much still in flux. We knew early on that we needed to design pages as a whole, so both parties could assess the visual design and content together.

To keep things manageable we narrowed in on the core content: services, partners, about, and news.

How do you keep the whole team in the loop?

In our workshops we transformed the mockups into a clickable prototype. This allowed KPSN to assess the design as closely as possible to a real website.

KPSN found this tool especially useful as it enabled them to share the designs internally. All team members had the opportunity to see progress and provide feedback.

Some aspects of a design come together quickly. But others needed more time to create the right solution.

The home page was one such example. We explored several options – including ones we thought may not work – so KPSN could make a clear and informed choice.

How do you develop an accessible website?

By designing core pages as a whole and using it to help define content, we were able to spot where components could be reused. When developing this meant we could develop a feature and limit the number of variations.

This left time for us to delve into more thorny challenges such as the menu bar. Menu bars are critical for users browsing a website. They are also one of the most complex components as they often feature various interactive controls.

During the design phase we spent additional time exploring options with the team.

The main challenge developing accessible menu bars is the variety of contexts it needs to work under. For example a menu bar has to work:

• On any sized device
• When CSS is disabled
• When JavaScript is disabled
• When CSS and JavaScript is disabled
• 400% zoom
• Keyboard use only

One common issue we resolved is that menu bars often have buttons that show and hide content: for example a menu.

These typically work by changing the CSS on the content that is shown/hidden when the user interacts with the button. But when CSS is disabled the button appears to have no functionality, as the content is already visible. This will fail an accessibility audit.

We explored and tested several techniques, in particular checking browser support, before settling on using an HTML attribute “hidden”. The attribute has the same effect as using CSS, but crucially because it is HTML will function when CSS is disabled.

How do you pass an accessibility audit first time?

From our initial conversations with KPSN, we knew the accessibility audit would be conducted by Kent County Council’s Digital Accessibility Team.

We made sure the team was included during the project, so we could make full use of their guidance. Accessibility is tough partly because the Web Content Accessibility Guidelines (WCAG) is not a checklist. Some criteria have an amount of interpretation whereas other criteria do not.

During development we also created a “beta website”, so that when we needed clarification on technical aspects of WCAG 2.1 there was a real working example to look at. This made it easier to align all parties and have focused conversations about critical design elements.

Doing so helped ensure when the live website was audited, there were only a handful of very-minor issues found. This saved considerable time as only minor amendments of the code were needed and not entire refactors.