Bobby Approved Not Always Accessible

by Anthony Quinn

Many organizations genuinely believe that if their site passes the Bobby test and displays the Bobby icon, it is "accessible". However, it should be remembered that the Bobby test does not ensure true "accessibility".

Why "Bobby Approved" Does Not Always Mean Accessible

Bobby is an online testing tool which has been developed to help developers assess web sites for accessibility. It is a free service provided by CAST (Centre for Applied Special Technology), a non-profit organisation which aims to expand opportunities for people with disabilities through computer technology. Bobby looks at the underlying HTML code that controls the presentation of a web page and analyses it against the W3C Web Accessibility Initiative (WAI) guidelines.

To become 'Bobby approved', a web site must pass all of the automatically testable Priority 1 WAI checkpoints. If Bobby detects a violation it will flag it and provide some guidelines on how to repair the HTML code. Bobby deals with WAI checkpoints in one of three ways:

  • Those that relate to a screen element, specific to a given page and for which violations can be detected automatically.
  • Those that relate to a specific a screen element, specific to a given page but for which violations cannot be detected automatically. These require manual checking and Bobby can tell you where to check.
  • Those that do not relate to a specific type of screen element. Bobby will only list these for reference because it cannot test for them.

WAI checkpoints for which violations can be detected automatically include 1.1 (Priority 1) "Provide text equivalent for every non-text element". Images and other non-text elements can be detected and automatically checked to see for alt text. However, Bobby cannot tell you whether the alt text is relevant or useful.

WAI checkpoints for which violations cannot be detected automatically include 14.3 (Priority 3) "Use header elements to convey document structure and use them according to specification". It is not possible for Bobby to know whether a header element has been used to convey structure or whether it has been misused to create a purely visual effect. If Bobby detects any header elements on a page it highlights the possibility that the checkpoint has been violated and prompts for a manual check.

Checkpoints which do not relate to a specific type of screen element include 3.5 (Priority 2) "Create a style of presentation that is consistent across pages". Bobby cannot detect inconsistency or tell you anything at all about presentation style.

Many organizations genuinely believe that if their site passes the Bobby test and displays the Bobby icon, it is "accessible". In many ways, this is an understandable outlook. The "Bobby Approved" icon represents an achievable standard and a tangible, recognisable endorsement of efforts made towards web accessibility. However, it should be remembered that the Bobby test does not ensure true "accessibility".

Some checkpoints - including Priority 1 issues - are not amenable to automatic testing. It is currently impossible for Bobby to guarantee accessibility in compliance with the WAI definition. If Bobby is the only test, which is deployed during development, it is entirely possible to produce a site with accessibility problems.

Bobby is undoubtedly a useful tool but it is often misused and misunderstood. The primary objective of usability is to make web pages accessible and easy to use - for everyone. Since there are some important aspects of accessible web page design that cannot yet be tested by Bobby, it might be more accurate to say that Bobby can be used to identify definite inaccessibility rather than to verify accessibility.

This is useful when the development has reached the point where HTML is in production, something, which happens relatively late in the web development process. Changing the design at this stage in development, while easier and cheaper than doing so after the site goes live, is more expensive than making changes earlier in the process. It is cheaper and more efficient to design accessibility and usability into a web site during the early stages of development.

To develop accessible easy-to-use websites, some qualitative input is required, either in the form of expert input or by involving real users in development as part of an iterative design and testing programme.

frontend

Industry FOCUS

Related Articles

The Benefits of Viewing User Tests

The benefits of user testing have long been established. It is still important however to try and maximise these benefits. One way in which this can be done is by viewing the user test yourself.

The Experience is Key

It is important to remember that the experience a person has using a product or service is every bit as important as that product or services usability.

The Advantages and Limitations of Focus Groups in the Design Process

Focus groups are a great way to collect information from several people very quickly and cost effectively. They are mainly used to gauge people’s reactions and feelings to items, however when used appropriately they can also be used as part of user requirements gathering.

Five Rules For Better Bank Websites

Internet banking is here to stay and the major banks are all busy figuring out how to expand their business online. Online banking is all about convenience and functionality but what about the bank’s public website? It is often a struggle to achieve the right balance between information and product sales, between user functionality and marketing requirements.

Back To Basics: How Poor Usability Effects Accessibility

In recent user testing with a range of participants including Visually Impaired (VIP) and Blind users we found that the majority of problems were common across all groups. However the effect of poor usability is more severe for users with visual disabilities. Surprisingly all of the issues are very familiar and are easy to fix so we thought we’d revisit some of the basics of accessible web design.

 
frontend.com, 7 Westland Court, South Cumberland Street, Dublin 2, Ireland.    Email: mail@frontend.com
IRELAND Tel: +353 1 611 46 30     UK Tel: +44 786 6434 853    SWITZERLAND Tel: +41 21 634 2437