WCAG Is Not Scary Anymore – A Progressive Approach to Website Accessibility

Guest post from Herin Hentry, Senior Test Analyst at Planit, originally published at www.planittesting.com.

‘WCAG is not scary anymore’ was the title of my presentation at A11yCamp, Melbourne 2016 representing Planit Software Testing, Accessibility Services which received good feedback from the audience. I thought I will follow that up with an article to share with a larger audience.

Why This Title?

This title originates from having a discussion with one of my friends who is a project manager. His team was asked to develop a small-scale website; WCAG Level AA compliant, for production release in 2 months. The team struggled as they found WCAG 2.0 and other reference documents bit overwhelming, in fact a “bit scary” if I use the same words as used by him. Due to the time constraints, the website had to go-live without ticking off WCAG Level AA compliance.

This provoked my thoughts. Every accessibility related meetup, forum and conference has been consistently advising to consider WCAG from the early stages of development rather than retrofitting it. But, how to do this is not clear for most of us. W3C-WAI has documents on Accessibility Responsibility Breakdown for everyone involved in website development. WCAG 2.0 was published in December 2008. But, until now, designers, developers, project managers and content authors feel overwhelmed by the amount of information they need to go through. What seemed helpful was having a step-by-step approach to include WCAG success criteria in the development process.

WCAG 2.0: A Jigsaw Puzzle?

For most of us, even after 8 years of WCAG 2.0, WCAG still looks like a jigsaw puzzle.

Figure 1: Word cloud displayed in separated puzzle pieces

We have our own workaround, trying to fit things in and it still looks jumbled, leaving us feeling overwhelmed and confused.

Figure 2: Word cloud of accessibility terms

After having a conversation with few beginners, I felt that there is a need to make them feel comfortable by showing them a different way of looking at WCAG.

The Inspiration

I saw my 7-year-old daughter playing with a jigsaw puzzle at the table. I observed her trying to solve the puzzle. She was following a process:

1. Emptying puzzle pieces on the table
2. Grouping the edge pieces
3. Identifying and grouping similar coloured pieces
4. Forming a framework with the edge pieces
5. Assembling the identifiable pieces to form smaller recognisable parts
6. Filling the gaps to make the final product

Figure 3: How to assemble a jigsaw puzzle ^[1]

The puzzle pieces emptied on the table reminded me of WCAG. This sparked an idea in my mind. I started searching for a development process for small/large scale websites. Investing some time to understand the complete web development process and referencing WCAG QuickRef gave an idea for a possible progressive approach for considering accessibility from the beginning of the web development process.

Applying Lessons Learned from a Jigsaw Puzzle to WCAG 2.0 Through the Web Development Process

Web Development Process

A simple web development process consists of the following steps:

1. Discovery Process
2. Content Identification
3. Structure Identification
4. Layout / Wireframe
5. Design sample pages (Home + Internal)
6. Creating Web Style Guide
7. Content Integration
8. Development
9. Testing
10. Deployment

I tried to relate the Level A and Level AA success criteria to each stage of web development process.

This article lists the success criteria that need to be introduced / considered at each stage. From this point on, this article is structured with a short explanation of each stage of the web development process, the WCAG success criteria that can be introduced at each stage, and the requirements or tasks that need to be relayed to the team. The task list is not an extensive list. Please refer to WCAG guidelines to fit your needs. Whether you are using Agile, Waterfall or another methodology in web development, using a simple high-level document to keep track of the success criteria is very important. This needs to be revisited at each stage throughout the web development process and make sure it is not broken.

1. Discovery Process

The discovery process helps with identifying the page hierarchy and links content to users. One of the by-products of the discovery process is the site inventory. Making the site inventory user-centred would focus on “How am I going to help the user find the content they are looking for on this website?” Users find their content by the page titles of the content. But, we need to help the users to search / navigate to the relevant content.

Figure 4: Information Architecture diagram ^[2]

This leads to the introduction of the following success criteria related to discovery:

• 2.4.5 Multiple Levels – Offer several ways to find pages
• 2.4.2 Page Titled – Use helpful and clear page titles

Create requirement / task list for the team:

• Include a Global navigation menu and global footer to navigate between pages (refer 2.4.5)
• Include a Search facility at the Global menu bar to get to the content (refer 2.4.5)
• Include a Sitemap at the footer (refer 2.4.5)
• Include descriptive, front-loaded page titles (refer 2.4.2)

Having these requirements / tasks listed helps the designers, developers and content writers to consider provisions for including these features, be it adding a link in the wireframe, or using appropriate tags in the articles.

2. Content Identification

Unless you are creating the dullest, most technical website imaginable, your content should consist of more than just plain text. Having a checklist of common types of content helps at later stages of the development process.

Figure 5: Content Identification Checklist ^[3]

• Articles;
• Blog;
• Banner advertising;
• Discussion forum;
• Documents;
• E-commerce;
• Forms for contact, quotes;
• Physical products;
• Digital content – Audio, Video;
• Email newsletter;
• Event calendar;
• Event registration;
• Image gallery;
• Link management;
• RSS feeds;
• Social media links;
• Staff directory.

3. Structure Identification

Structure and layout are two terms that are very important in a website design and often get mixed up. The structure is how elements and components of an interface are grouped, defining relationships between those elements and components and is the domain of the information architect. Figure 6 shows a section of the Web Accessibility Initiative home page with style sheets turned off. This page has few headings, text and list items grouped in a very structured and meaningful manner. The relationship between headings and content are very clear.

Figure 6: Web Accessibility Initiative (WAI) home page with style sheets turned off

This leads to the introduction of the following success criteria related to structure identification:

• 1.3.1 Info and Relationships – Logical structure
• 1.3.2 Meaningful Sequence – Present content in a meaningful order
• 1.3.3 Sensory Characteristics – Use more than one sense for instructions
• 2.4.1 Bypass Blocks – Provide a ‘Skip to Content’ link, proper heading structure
• 2.4.3 Focus Order – Logical order
• 2.4.6 Headings and Labels – Use clear headings and labels
• 3.2.4 Consistent Identification – Use icons and buttons consistently
• 4.1.1 Parsing – No major code errors

Requirement / Task for the team:

• Use clear labels on forms (1.3.1)
• Present content in a meaningful order using semantic elements (1.3.2)
• Use more than one sense for instructions (1.3.3)
• Add a ‘Skip to Content’ link to all pages on your website (2.4.1)
• Have source code order for focusable components. Ensure focus is received in in an order that preserves meaning (2.4.3)
• Break up content with headings and subheadings using H1 to H6 without skipping levels (2.4.6)
• Label all form elements, widgets, tables (2.4.6)
• Use consistent icons across pages (3.2.4)
• Use consistent naming for Elements with the same function (3.2.4)
• Use semantic HTML structure and unique Ids (4.1.1)

4. Layout / Wireframe

Once the structure of the content is determined, it’s time to move to the first step in the design process which is wireframes. Building wireframes mostly has to do with the layout aspect of web design. They are done as sketches and are designed not to be pretty, but rather to show page layout. The layout is concerned with emphasis, proportions, and placement and is the domain of the visual designer.

The layout of web pages determines the repeated navigation area and the proportion of each component in the web page.

Figure 7: Diagram outlining page layout ^[4]

This leads to the introduction of following success criteria related to layout:

• 3.2.3 Consistent Navigation – Use menus consistently
• 1.4.4 Resize text – Text can be resized to 200% without loss of content or function

Requirement / Task for the team:

• Use a standard template for all repeated navigation areas of web page (3.2.3)
• If pages need future expansion consider pagination in layout (3.2.3)
• Do not disable resizing text and zoom on browsers and mobile devices (1.4.4)
• Do not introduce horizontal scroll on resizing text (1.4.4)

5. Design Sample pages (Home + Internal)

Once the layout is complete it’s time to get started on the design. Web design itself refers to the process of creating a web page’s appearance and to the choice of a right colour scheme, page layout, fonts and more. At this point, the web page layout is getting converted into the visual design with buttons, links, text, controls, errors, focus, forms and navigation, etc.

Figure 8: Sample design outlining the appearance of a web page ^[5]

This leads to the introduction of following success criteria related to design:

• 1.4.1 Use of Color – Don’t use presentation that relies solely on colour
• 1.4.3 Contrast (Minimum) – Contrast ratio between text and background is at least 4.5:1

Requirement / Task for the team:

• Instructions or infographics should not rely on colour alone. Use patterns (1.4.1)
• Use 12pt as minimum font-size (1.4.3)
• All visible content on the web page should have contrast ratio of 4.5:1 in all states (1.4.3)

6. Web Style Guide

Once the sample pages are reviewed and approved, it’s time to create a style guide. A style guide is where proper planning shines. A style guide determines and defines all the design, layout, interactive and type elements used throughout the website. Style guides offer you the chance to present your brand in a consistent way. They help to ensure that multiple authors use one tone. And they help save time and resources by providing an instant answer when questions arise about preferred style. They also help in identifying accessibility issues related to colour contrast, form elements at an earlier stage of your development process. The accessibility rule set for your website can be created as part of your style guide and referred to anytime.

I also recommend getting your style guide tested by an accessibility expert. An accessibility expert can help you create a rule set for each individual component of the style guide. This helps in resolving issues at an earlier stage than retrofitting it. If you identify that a textbox is not associated with its label; radio buttons are not enclosed in fieldsets and legends; error messages are not associated with the correct label using ARIA attributes; hover colour contrast is not sufficient; then anything you can imagine in this context will be cared for and treated in the first instance. This prevents fixing multiple instances of the same issue at different locations and affecting your budget at a later stage. Whether you follow waterfall or Agile for website development, I cannot emphasise enough the need for creating and keeping an updated style guide.

Figure 9: Sample style guide ^[6]

This leads to revisiting the following success criteria we have seen earlier:

• 1.4.3 Contrast (Minimum) – Contrast ratio between text and background is at least 4.5:1
• 1.3.1 Info and Relationships – Logical structure, clear form on the labels / radio buttons (using fieldset, legends)

This also introduces these success criteria at this stage:

• 2.4.7 Focus Visible – Ensure keyboard focus is visible and clear
• 3.3.1 Error Identification – Clearly identify input errors
• 4.1.2 Name, Role, Value – Build all elements for accessibility

Requirement / Task for the team:

• All states of the focusable elements meet minimum colour contrast (1.4.3)
• Use clear labels and grouping on forms (1.3.1)
• Make the keyboard focus visible on all elements (2.4.7)
• Provide concise, clear instructions about fields, formats and required fields (3.3.1)
• Highlight errors in an easily identifiable location (3.3.1)
• Transfer focus to the first element where error is identified (3.3.1)
• Use ARIA attributes to help assistive technology users if required (4.1.2)

7. Development

Figure 10: Cartoon men assembling a jigsaw puzzle together ^[7]

The developmental stage is the point where the website itself is created. All individual graphic elements from design are used to create a functional site. This is typically done by first developing the home page, followed by a “shell” for the interior pages. The shell serves as a template for the content pages of your site, as it contains the main navigational structure for the website.

As the WCAG success criteria have been introduced at every stage of the process and tasks have been created with references for the team, the information has been relayed throughout the process making it an easier transition to development. The developer is not overwhelmed by the rush of information at this level if accessibility has been addressed and included as part of the process.

This leads to the introduction of the success criteria related to development

• 2.1.1 Keyboard – All functionality should be accessible by keyboard only users
• 2.1.2 No Keyboard Trap – Don’t trap keyboard users
• 2.2.1 Timing Adjustable – Time limits have user controls
• 3.2.1 On Focus – Elements do not change when they receive focus
• 3.2.2 On Input – Elements do not change when they receive focus
• 3.3.2 Labels and Instructions – Label elements and give instructions
• 3.3.3 Error Suggestion – Suggest fixes when users make errors
• 3.3.4 Error Prevention (Legal, Financial, Data) – Reduce the risk of input errors for sensitive data

8. Content Integration

Figure 11: Content Integration diagram ^[8]

At last, your brilliant design has been converted to code and is ready to be integrated into a CMS.

As individual pages are created with content, this leads to the introduction of the success criteria related to languages:

• 3.1.1 Language of Page – Page has a language assigned
• 3.1.2 Language of Parts – Tell users when the language on a page change

When content copies are created, it is good to refer to the success criteria related to links:

2.4.4 Link Purpose (In Context) – Every link’s purpose is clear from its context

Content may also include non-text content. Hence this the right time to introduce the non-text content related success criteria:

• 1.1.1 Non-text Content – Provide text alternatives for non-text content
• 1.4.5 Images of Text – Avoid using images of text

For every page created we might need to revisit the following success criteria to verify that the content structure is still valid using the following criteria:

• 1.3.1 Info and Relationships
• 1.3.2 Meaningful Sequence
• 2.4.6 Headings and Labels
• 3.3.2 Labels or Instructions

9. Testing

When you have a set of pages created with accessibility consideration from the beginning, test the website for usability, compatibility, functionality and accessibility. Identify the issues, fix and retest. This process needs to be repeated for every set of pages. I also recommend testing with people with disabilities at this stage.

10. Deployment

Verify if you have included feedback forms / contact forms and accessibility statements as part of your website before you deploy. Deploy the website for beta testing. Prepare a maintenance plan and maintain your website.

Specific content:

Some success criteria are specific to the content type. For example, if you are using media content:

• 1.1.1 Non-text Content
• 1.2.1 Audio-only and Video-only (Pre-recorded)
• 1.2.2 Captions (Pre-recorded)
• 1.2.3 Audio Description or Media Alternative (Pre-recorded)
• 1.2.4 Captions (Live)1.2.5 Audio Description (Pre-recorded)
• 1.4.2 Audio Control

If you are using flashing or moving content:

• 2.2.2 Pause, Stop, Hide
• 2.3.1 Three Flashes or Below Threshold

In Conclusion, What Makes a Website Accessible?

It is important to identify and accommodate WCAG success criteria as part of your process and relaying the information to the entire team. We need to work together as a team and make accessibility everyone’s responsibility. WCAG is not scary anymore if we have a progressive approach for including success criteria in web development. ^[9]

I would like to finish with a Chinese proverb: “To get through the hardest journey we need to take only one step at a time, but we must keep on stepping”. ^[10]

Acknowledgements

• To Planit Software Testing for supporting my work
• To A11yCamp for accepting this presentation and letting me share this approach

References

• A Comprehensive Website Planning Guide by Ben Seigal
• Introduction to Information Architecture & Design by Robert Stribley
• Wuhcag | Web Accessibility for Developers by Luke McGrath
• Structure vs. Layout by Stewart McCoy
• https://www.ntchosting.com/encyclopedia/web-design/web-page-design/
• http://www.idesignstudios.com/blog/web-design/phases-web-design-development-process/#.V5JEhvl97IU

Image Credits

• ¹ http://www.wikihow.com/Assemble-Jigsaw-Puzzles
• ² http://homepageremedy.com/
• ³ https://www.syracusemediagroup.com/marketings-hottest-trend-is-content-marketing/
• ⁴ http://insumedia.com/en/design-and-structure/
• ⁵ http://blog.ispionage.com/build-effective-landing-page.html
• ⁶ http://www.ray-phan.com/citrus-media/
• ⁷ http://www.ksoumet.org/mission-vision/
• ⁸ http://sndsite.com/custom-website-design-development/page-layout/
• ⁹ https://pucksandpuzzlepieces.com/2013/09/27/teamwork-makes-the-dream-work/
• ¹⁰ http://www.blogwithjester.com/mountains-are-climbed-one-step-at-a-time