Why 'Bobby Approved' is not Enough

Posted on March 26, 2001

in IA/Usability

by frank gaine (gainef)

Rated 3.96 (Ratings: 8) (Add your rating)

Want more?

More articles in IA/Usability
More articles by gainef

frank gaine

Member info | Full bio

User since: January 22, 2001

Last login: January 22, 2001

Articles written: 5

Bobby is provided by CAST (Centre for Applied Special Technology) and is a free piece of software available online or to download. It assists web page authors to identify obstacles to access by individuals with disabilities. Bobby's analysis of accessibility is based on the W3C Web Accessibility Initiative (WAI) guidelines. To become "Bobby Approved" and display the Bobby Approved icon, a web site must successfully address all of the Priority 1 WAI issues that Bobby identifies.

Bobby is a very useful tool but it is all too often misunderstood. Many organisations however, falsely believe that simply passing the Bobby test will satisfy their accessibility obligations. For them, the measure of accessibility is whether or not their pages can attain the Bobby Approved icon. In many ways, this is an understandable perspective. The Bobby icon represents an achievable standard and a tangible, cost effective reward for efforts made towards web accessibility.

It should be remembered that the Bobby test does not ensure 'real' accessibility. Firstly, "Bobby Approved" is based on passing the Priority 1 checkpoints alone. Many now believe that if a site is to be truly accessible it should pass the Priority 2 checkpoints also. Indeed, if we are to look at initiatives at European Union level we should expect Priority 2 compliance to be the benchmark going forward. Bobby tests for these Priority 2 checkpoints but compliance is not part of getting the icon. Secondly, Bobby cannot even warrant that a site has passed all of the WAI Priority 1 checkpoints it has evaluated as Bobby is only one interpretation of the WAI checkpoints.

Indeed, in the absence of a complaint, CAST does not actively regulate the use of the icon. There seems to be abuse in some instances and sites have been observed to display the icon even though they are not compliant. This usually occurs where the test's subjective Priority 1 'user checks' have not been addressed, where only the homepage on a site has been tested or where new content is not assessed for accessibility when added.

It may be difficult to displace the presumption that attaining the well renowned Bobby Approved Icon means sufficient accessibility has been achieved. It has been said that Bobby could have the effect of making the web less accessible due to over-dependence on the test as the standard used by many for measuring accessibility.

CAST itself recommends that web developers use Bobby only as a first step to ensure accessible Web page design. It might be more accurate to say that Bobby can be used to identify definite inaccessibility rather than to verify accessibility. On the up side, the appearance of a Bobby icon is a good indication that the site developer is concerned about accessibility and is amenable to making the necessary changes to facilitate users with impairments.

The reality is that it will always be difficult to create an achievable and accepted stamp of accessibility, especially when the interpretation of many Priority 2 (and Priority 3) issues are still to be universally decided and where they require subjective assessment in each instance.

You can find Bobby at http://www.cast.org/bobby/

19 comments on this article. Log in to add your comment |

EU Initiatives references?

Submitted by MartinB on March 27, 2001 - 12:31.

Hi Frank

Could you share some references (URIs would be nice) for the upcoming EU initiatives?

Accessibility at European Union level

Submitted by gainef on March 28, 2001 - 01:53.

Two good links here Martin:

eEurope Initiative: An Information Society for All
eEurope Initiative: Information Society Basics

Specific EU action points

Submitted by MartinB on March 28, 2001 - 03:28.

Thanks Frank. Their Action Plan clearly shows the direction to be

Headed towards specific legislation enforcing accessibility to online services (most of the original laws were written for offline use, and the legal profession is only slowly understanding them to cover online use too)
Based on the WAI guidelines.

US getting better

Submitted by pnealall@ci.tho... on March 30, 2001 - 11:05.

The US ruled in 1996 that web pages fall under the rules of the Americans with Disabilities Act (ADA), but specific guidelines other than "try to follow the W3C guidelines" were only announced late (as in December) of last year (2000). While most of the WCAG level I checkpoints are contained in the Section 508 Accessibility Requirements, many of the Requirements are Level II checkpoints.

A brief summary of the Requirements can be found at www.webable.com/508_guidelines.html The full and official text of the Final Rule can be found at www.access-board.gov/sec508/508standards.htm

I don't expect that the vast majority of employers or clients will be terribly concerned about the Section 508 guidelines for a while yet, but I did hear mention on The List that lawsuits are starting. Just as with physical access to buildings, busses, etc, it will probably take several years of lawsuits to before the general public really cares. But I post these knowing that we developers have to a) lead the way and b) be ready when someone says "I gotta have this!"

Reality?

Submitted by aericks on April 2, 2001 - 12:02.

I've just been starting to do research and have compiled a good deal of info on making websites accessible to people with all sorts of disabilities. There's a lot of common-sense stuff that I think web designers can do and should such as adding alt tags and descriptive text for graphic elements such as photos and tables but some of the information from the W3C kind of frustrated me.

One of the recommendations that I kept seeing again and again was to use CSS for placement of elements instead of relying on tables for layout. Now... anyone who is trying to reach a broad audience will need to take into consideration that CSS for layout certainly does not degrade gracefully and as far as I know CSS still isn't supported in such a way to render complex layouts properly.

Here I will plead total ignorance and ask why tables for layout are so bad. Can't speech readers be upgraded to handle tables for layout? Is it a funding issue? Or, am I simply barking up the wrong tree with this concern over layout and table structures?

tables for layout

Submitted by pnealall@ci.tho... on April 2, 2001 - 12:22.

aericks:

The main problem with tables for layout is that *some* screen readers handle tables in a linear manner - that is, they read the screen left-to-right (for left-to-right languages), line by line. Thus, if you have tables to, say, break your content into columns, it will read line 1 of cell one, followed by line 1 of cell two, followed by line 2 of cell 1, followed by line 2 of cell 2, and so on.

You hit the nail on the head when you mentioned a funding issue. Our organization hasn't had the funding to explore the screen readers that are purportedly the most common - JAWS, which costs $US 1,195 for a single NT license; Window-Eyes, $US 595 for a single 9x license, and HAL, � 520 (approx. $US 740 when I did my research). Therefore, my research has been limited to freebies. One of the freebies I downloaded handled tables relatively well - but it's free only for a 30-day evaluation period. The totally free screen reader I played with a little bit and was never able to get to work well did not handle tables at all - it performed exactly as I described above.

I'm not sure what the demographic statistics are for individuals who need to use screen readers to explore the internet, but I use my father-in-law as an anecdotal example of one such individual. He is comparitively well off, having had a nice career as a (blind) doctor. He cannot afford the prices I discussed above, for a variety of reasons. Whether other individuals can afford such is probably as varied as the individuals themselves.

Screen readers themselves can be upgraded to handle tables, as you mentioned. As a matter of fact, most of them when I was doing my research used either IE5.x as a "driver" or Netscape 4x. That is, they actually pulled up the page, behind the scenes, in the common visual browser, and then attempt to read the page. Depending on how the screen reader was developed, they seem to parse through the resultant HTML page and read the page based on the tags, the same as a browser which renders the page visually.

Hope this helps some

That does help!

Submitted by aericks on April 2, 2001 - 12:34.

It answers one of my questions which was about tables and the "why" of it all. As I start experimenting with some of the different types of browsers available to those with disabilities, I hope to offer my own article here about the pitfalls.

I guess my follow-up question is -- Can a site be all things to all people? The short answer sounds like 'no'. I wonder then if one of the keys to getting ADA compliance would be for an organization to develop a sort of "Standards of Practice" quideline which shows how to get the most out of a site from the developer's point of view. Can "bells & whisles" coexist peacefully with accessibility?

All things to all people

Submitted by pnealall@ci.tho... on April 2, 2001 - 12:52.

Bravo on the "Standards of Practice" idea! I believe that, just as with (say) browser support, each and every organization should decide how far their Accessibility will go *on their general format pages*, and what accessibility issues will be relegated to supplementary pages.

As you mentioned, no site can be all things to all people. "Bells and whistles" can't possibly abide side-by-side with some accessibility concerns, because some "bells and whistles" are, by their nature, not accessible. A live webcam of whatever the site is about is a really cool idea - if the visitor can see. Streaming audio is a cool idea too - if the site visitor can hear.

Accessibility isn't so much about making it so that the vision impaired visitor can hear the webcam picture, or the hearing impaired visitor can see the audio content, as it is concerned with making sure that the same information is available to all visitors. What added benefit is the web cam picture? Is it a live picture of the construction site of a new building (the use that one of our departments wants), so that people can see what the progress is? Then also provide a link to a description of the progress, that is updated on a reasonable basis ("Construction update 2 April 2001: The foundations were poured this week, and work on the parking lot has progressed to the point where all the bulldozing has taken place. This week, we plan on laying the initial floorboards and putting in the concrete curbs for the parking lot" DISCLAIMER - I am making stuff up. I know nothing about construction, as is probably obvious).

Of what importance is the streaming audio? Is it a speach by a Really Important Person in the organization about Where We Are Going In The Future? Then provide a link to a text transcript of the speech (I'll thank you too, 'cause I usually have my web radio on and it annoys the snot out of me when things turn my radio off to give me information I could read a LOT faster than someone else can read it to me).

Hm. A much-shortened version of what I just said would be "make sure that the information that the visitor gets is available to them no matter HOW they are accessing it." By providing alternative formats for special presentations, such as content presented in "bells and whistles" formats, then everyone can get at the information and you will probably make site visitors with peculiar surfing habits happy as well as the people you are really aiming to serve.

One size need not fit all

Submitted by MartinB on April 3, 2001 - 01:00.

Amanda, you only really face an issue of "Tables or CSS?" if you're trying to make one set of static HTML satisfy all users. While the growth of CSS-capable (and close to standards-compliant) browsers have made this a more sensible proposition than when v4 browsers were newly launched, it may still be necessary to serve 2 templates - one for NS version 4 & below and IE version 3 and below which uses tables for layout, and one for everyone else which uses CSS-P.

Also, the de-emphasis of tables isn't an absolute requirement - it's a Priority 2 element, which puts more emphasis on CSS font styling, which has much greater browser support.

someone's bells are another's whistles

Submitted by pell_mel on April 4, 2001 - 02:02.

if you think about it. (to completely torture a phrase ;-) my apologies!)

a webcam might be fantastic if i'm hearing impaired - it might show me the presentation, and if it's implemented in a SMIL environment, it can be captioned. i can read a less boring transcript this way. (and if i'm deaf, then written english might not be my strong point, as english is not my first language often, don't forget about that.)

if it's got sound, then EVERYbody in our example (vision-impaired, hearing-impaired, ppl with neither disability) can marvel at that building's construction.

bells and whistles

Submitted by pnealall@ci.tho... on April 4, 2001 - 08:09.

pell_mell - You make a GREAT point! If the information that someone is after is available in multiple formats, then EVERYBODY can get at it.

Everything to All - Hardly

Submitted by gainef on April 14, 2001 - 07:57.

It must be kept in mind that by simply following the WAI Guidelines and making the information on your site strictly 'accessible' does not mean that the site will be necessarily easy-to-use for people with disabilities. To make a site usable for these people, it must be developed with them at the centre of the design process from the outset.

Indeed, it may be difficult to create one site that is optimised for both regular users and users with disabilities alike given that their needs and expectations are very different. The Guidelines state that if you cannot make your current site accessible, then you should consider creating an alternative, accessible version. This may be good advice to follow because accessibility retro-fitting can be expensive whereas creating a linear, text-based alternative which is informed by the Guidelines and by users with disabilities can be less traumatic on the bank balance.

Re: someone's bells are another's whistles

Submitted by kerri on May 7, 2001 - 17:20.

>if i'm deaf, then written english might not be my strong point,
>as english is not my first language often, don't forget about that.

A small point, I know, but this is, in fact, usually NOT the case. Most deaf people in developed countries are *late-deafened* ... that is, they were born hearing, and became deaf post-lingually. Just another thing to think about...we can't lump the needs of every person with a disability together...some blind people need the ability to make text larger, because they're not *completely* blind, only partially blind, and use magnification. Others use screen readers, and still others may use refreshable Braille displays. Differences abound with hearing loss, as well. Some people who are "deaf" were born hearing, and (in the case of the US) English is their native language. In other cases, people are born deaf and learn English as a first language anyway, either by speech reading (with or without hearing aids), or even by signing with Signed Exact English (SEE), not American Sign Language (ASL). In still other cases, a user might have a learning disability, so long, prosaic explanations may be more difficult to understand for that user than simple bulleted instructions.

Accessibility is a tough nut to crack, but it's WELL worth it! :-) If my site doesn't *work* in Lynx, I don't publish it. But then, I'm publishing web sites to impart information, not to entertain. Others may have different priorities.

Re: someone's bells are another's whistles

Submitted by Mari on May 8, 2001 - 09:54.

>if i'm deaf, then written english might not be my strong point, >as english is not my first language often, don't forget about that.

>A small point, I know, but this is, in fact, usually NOT the case. Most deaf people in developed countries are *late-deafened* ... that is, they were born hearing, and became deaf post-lingually

thanks for your input

Submitted by pell_mel on May 10, 2001 - 18:56.

I recently went to a Web Accessibility Summit; and there were a lot of ppl who were genuinely surprised when it was pointed out to them that to a lot of deaf ppl (i'm in Australia), english *is* their second language.

bugger, my comment just got munched!

Submitted by pell_mel on May 10, 2001 - 18:58.

bugger, my comment just got *munched* the first paragraph to my comment was... kerri, i hope i wasn't coming across with a "pat" solution; i *do* realise that the issue's a complicated one. i think the main point i was trying to get across was that a lot of ppl assume that you can "talk" to deaf ppl by "writing them a note".

Conflicting needs

Submitted by a_parker on May 22, 2001 - 06:45.

I work for a company that sells computers and software for people with dyslexia, so accessibility is essential for our site. What really bugs me is that recommendations for what makes a site accessible can actually conflict. For example, I am told not to design using tables because of the screen reader problem (and as we know, CSS positioning is still too flaky to rely on). On the other hand, I am also told that lines of text should be short as this helps readability. So, do I design for dyslexic people who are trying to read from the screen, or dyslexic people using screen readers? Help!

Conflicting Needs

Submitted by gainef on May 22, 2001 - 07:25.

Indeed, sometimes it is difficult to reconsile the guidelines themselves.
Whenever I come accross a difficult or interesting question on the Guidelines or on Accessibility issues in general, I have a thrawl through the W3C's Web Accessibility Initiative Interest Group Archives or post the question on the discussion forum. There is a wealth of great information and learned contributors thereto. Links below...
Archives http://lists.w3.org/Archives/Public/w3c-wai-ig/
Subscribe http://www.w3.org/WAI/IG/

Achievable accepted stamp of accessibility

Submitted by TheG on November 3, 2004 - 04:40.

Frank makes the point that it would be difficult to create an accepted stamp of approval. There is actually one method I know if (in the UK at least) and that's an RNIB audit. This audit is carried out by a person, and as such can't be cheated and is properly regulated. Of course, as a result of this it is also expensive (because a proper accessiblity audit of a large site takes some time), but it is a quantifiable and for large organisations that are serious about accessibility it is a worthwhile exercise.

See www.rnib.org.uk for more information.

G

Start of page header

Other Fine Evolt.org Sites

Navigation Starts

Article Categories

Highest rated articles

Submit

Recent comments

Main Page Content

Why 'Bobby Approved' is not Enough

Want more?

frank gaine

EU Initiatives references?

Accessibility at European Union level

Specific EU action points

US getting better

Reality?

tables for layout

That does help!

All things to all people

One size need not fit all

someone's bells are another's whistles

bells and whistles

Everything to All - Hardly

Re: someone's bells are another's whistles

Re: someone's bells are another's whistles

thanks for your input

bugger, my comment just got munched!

Conflicting needs

Conflicting Needs

Achievable accepted stamp of accessibility