The Web Accessibility Lifecycle

When to use automated tools

Summary

This article outlines which aspects of accessibility can be checked at each stage of development, with a focus on where automated tools should fit in. Some knowledge of web accessibility is assumed. If this subject is new to you, please read an introductory article on web accessibility. The target audience is people who manage medium to large web site projects.

Introduction

The accessibility of a web site can be measured at various stages throughout its development, against the Web Content Accessibility Guidelines (WCAG), so it helps to know which accessibility issues are best dealt with at which stage. The most important stage for accessibility is during template development, where the general code that will be produced is decided. It should be approached in the same way that buildings are constructed. If there are weak foundations from the start, it will be time consuming and maybe even impossible to repair the problems that manifest themselves in the final construction. Building a web site from solid foundations creates a reliable base for future development. Tools can check your success for some issues, but an understanding of the development process is required to act purposefully on the results.

Web Development Lifecycle

The general web development lifecycle for most projects tends to include these stages:

• Design;
• Structure outlined;
• Templates created;
• Templates integrated;
• Initial content added;
• Site launch;
• Further content added.

Theoretically any accessibility aspect could be considered at any stage; however, for simplicity we will deal with the usual order. Accessibility checks are not required at every stage of this development process, but approaching accessibility checking in the right way for those stages where it is important is key to overall success.

Design

At the initial design stage there are very few things to check, however these checks are important. These are human, visual checks on a design storyboard before it goes into the template stage, and they include:

Flexible layout

Does the design allow the layout to ‘scale’ to the user’s window size? It is usually fairly obvious at this stage to an HTML/CSS coder whether a layout can be made flexible. It should also be possible to check if the layout will cope with the fonts being increased in size.

Consistent Layout

Will the navigation and layout be consistent drilling down to all the anticipated levels? For example, does the main navigation stay in the same position when users click through to deeper levels of the site?

Colour contrast

Does the colour scheme provide sufficient colour contrast between text and background colours, and is it appropriate for known colour blindness conditions?

Structure

There is little to be done accessibility-wise at the structure stage (often called Information Architecture) that is not covered by creating a usable structure and navigation system.

Templates

The templates are created from the design storyboard, translating the design into the code that people will receive from the web site. These templates form the foundation from which all the pages on the site will be made, and this is where the most WCAG checkpoints are accounted for. The template stage is where many of the ‘user-checks’ can also be performed. Tools such as the W3C’s validator and accessibility tools are useful at this stage to test the templates, but many items still require human checks to see what is appropriate. The templates should undergo a full check on code, cross-browser compatibility and accessibility compliance.

Valid Code

Does the code used conform to the specification? The code of each page should conform to the specification it is using so that any program reading it knows how to deal with the page. It is easy to check with the official HTML validator.

Separating content from presentation

Do the templates separate content from presentation? (In most cases, this means using ‘Cascading Style Sheets’ for presentational mark-up).

Structural mark-up

Do the templates use structural markup such as headings and lists appropriately?

Skip links

Does the template include internal page links to assist with in-page navigation?

Technologies used

Is there a reliance on technologies beyonnd HTML? e.g. Is JavaScript, Flash or Active-X required?

Relative units

Do the templates use relative sizes so that the layout and fonts can be resized?

Language markup

Do the templates specify the language in the code?

Keyboard use

Can the site be operated and navigated with a keyboard?

Avoid moving or flickering content

Movement can be very distracting, especially for those with learning difficulties. Flickering at certain rates can also be problematic for those with epilepsy.

Scripts

Do any scripts on the site degrade gracefully (i.e. basic functionality works without JavaScript), and work with a keyboard as well as a mouse?

Template Integration

The process of integrating accessible templates into a product or system, such as a content management system (CMS), can be very difficult. Often there are times when certain aspects are ‘hard-coded’, so it would involve changing how a system works to produce valid and accessible code. Occasionally it is not possible to replicate templates exactly. However, it is vital to check at the end of this stage that the templates have been integrated successfully. If the system has not produced accessible code previously, allow plenty of time at this stage as it could involve making changes to the system.

Initial Content Added

Once the site has been implemented, it is useful to include a good sample of content to give an impression of what it will look like. During the Quality Assurance stage you tend to find situations that hadn’t been anticipated when creating the templates, for example, including a large data table and a right hand column may not fit within a page properly. Allow some time for updates to the design to account for unforeseen content types. Once the site has been implemented on whatever (content management) system is being used, it is vital to check that the pages match the templates now that the content is included. Some content management systems have trouble creating valid code that matches the templates, and the text or WYSIWYG editors (What You See Is What You Get) used by the systems can also output inaccessible code. It is best to do a complete accessibility and code check on a representative sample of pages, and run automated checks on the entire site to see if any other errors come up. When templates are used, the only errors that occur tend to be replicated across many or all pages. Once the site has been confirmed as being completely accessible at this stage, the only thing that can go wrong now is the content…

Further Content Added

How much training content editors will need depends on the complexity of the CMS interface. Taking alternative text as an example, if an editor can add an image, they need to be able to add an alternative text equivalent. A CMS could handle this in a number of different ways:

• Not allow images to be added without an alternative text, or highlight those that are missing the text
• Provide contextual help advising how suitable alternative text might be chosen
• Centrally manage alternative texts for all images.

If these checks are not in place, then editors need to know how to apply alternative text to an image, and the type of description that would be suitable. Other aspects of accessibility that editors need to know about are:

• Correct use of headings;
• Correct use of quotes and acronyms;
• Correct use of tables;
• Marking any change in the language of sections in the text (for example, French);
• Appropriate link text.

Some of these issues can be caught by automated checks, but they tend to be checks that will only be recognised if it has been done correctly. For example, an automated check could test when quotation markup is used, but not when quotation markup should have been used.

Results from automated tools

Automated tools (e.g. Cynthia Says, WebXACT) will check a page for many items, but it is important to understand how much of each checkpoint an automated tool can realistically check for.

Total automation

Of the 65 WCAG version 1 checkpoints, there are five checkpoints that can be fully assessed by an automated process, and which are actually better assessed automatically:

• Valid code (checkpoint 3.2)
• Identify the language of a document (checkpoint 4.3)
• Don’t use server-side image maps (checkpoint 9.1)
• Avoid deprecated HTML elements (checkpoint 11.2)
• Associate labels with their controls in the code (checkpoint 12.4).

These items are all code-issues with no need for human interpretation, which is why automated checks are best for these issues.

Partial automation

Another 8 checkpoints can be partially assessed by automated tools:

Alternative text (checkpoint 1.1) – can check for existence, not for suitability

• Use relative units (Checkpoint 3.4) – can check for the existence of non-relative units, but not whether they make a difference to display
• Ensure pages work without scripts (checkpoint 6.3 & 9.3) – can check for scripts, but not whether the page works for a user
• Use device independent scripts (checkpoint 6.4) – can check for mouse or keyboard only scripts, but not whether they actually work for people
• Do not create automatically refreshing/redirecting pages (checkpoints 7.4 and 7.5) – some can be detected, but there are many possible methods that may escape detection
• Clearly identify the target of each link (checkpoint 13.1) – can check whether link text is repeated for links to different pages (e.g. ‘click here’), or if the same page is linked to by different text. However, many instances found by checkers do not affect people.

Automated tools can be used pre-launch stage to check across many pages, as user-checks have been performed already. However, some things (such as relevance of alternative text) will never be machine-checkable. These issues account for 13 of the 65 checkpoints; however, the point is really that there are many things that cannot be confirmed by an automated process. To underline this point, a knowledgeable web developer can easily trick the automated testers. Juicy Studio recently produced a page that breaks 33 checkpoints but passes automated tests. Nomensa had a similar page being developed for this article, but they beat us to it! While our version was intended purely as an academic exercise to show how easy it is, Juicy Studio give a much better explanation for each item. This article was written to show when automated tools are useful.

Prevention rather than cure

It is well documented that creating an accessible site is much easier (and therefore cheaper) than retrofitting a site to be accessible. To quote Matt May of the W3C, imagine this conversation with the contractor who’s building your house:

Aren’t you going to use a level for that railing? Oh, yeah, I’ll check it with the level once it’s screwed in.

Sure, it’s good to have a tool to help you do a job, but if you’re not adequately skilled to do the task, all a tool like a level is going to do is inform you after you’re done that you did it wrong.

Further Content Added

Once the templates are tried and tested, and the CMS is in full swing, there are several checkpoints that often come up when a site is reviewed:

• Links to the same page with different link text (e.g. a link in the main navigation is replicated in the content with slightly different text)
• Links not separated (a priority 3 issue where links should have a non-link separator in between)
• Headings not nested correctly (e.g. having a heading level 3 following a level 1).

These are common examples from our experience of (relatively minor) accessibility issues that are often best found by an accessibility testing tool that ‘spiders’ a site (checking every page linked to within a specified domain). Content issues such as alternative text have to be checked by people, and training the authors is the most effective measure. NB: Even minor changes to the template(s) of a site can impact accessibility of the whole site. It is important that any changes to the templates are checked thoroughly before release, for accessibility, valid code, and browser rendering.

Do Nomensa use automated accessibility tools?

A common question is whether we use automated tools as part of our process. The answer is yes, to a degree. Nomensa never conduct an audit, quality assurance review or accessibility test without a person checking every aspect of the page. A tool speeds up this process, and we have many free, created and paid-for tools in our arsenal. The best tool we have is our knowledge of how people use technology, and how web standards and Internet technologies interact to create different interfaces for different people.

Conclusion

Accessibility is an integral component of the development process. Knowing when to apply checks and techniques for identifying and resolving accessibility issues can make the  difference between achieving your accessibility targets and falling short of the mark. Many accessibility issues will be identified during the template stage. Working to resolve them at this point in the development cycle will prevent more resource intensive resolution attempts farther down the line. Quality assurance and automated tools both play a part in the latter stages of the development cycle, but more often than not they will identify issues too late for them to be resolved satisfactorily. Formulating a clear strategy, based on knowing where and when to test for accessibility issues, combined with the right tools, the right training and a good quality assurance process, is the key to a successful development project. Using a constrained system, such as a CMS, can provide a degree of protection against accessibility issues that regularly crop up in content loading. Training site editors to use the given system, and ensuring that they are fully aware of possible accessibility issues provides another layer of resilience against possible problems. Finally, a thorough and well rounded quality assurance process adds a final layer of screening to complete the program. Simply put, a successful development strategy anticipates potential accessibility problems and moves to resolve them before they become insurmountable.

Could we help?

Start building accessibility into your projects at the beginning to save time and money, don’t just leave it hanging on the backlog letting it gather up dust. Drill it in.

If you would like Nomensa to help you with your accessibility challenges or to provide you with an accessibility evaluation of your website/mobile app, please don’t hesitate to get in touch.

Take a full look at the digital accessibility services that we offer.