FW: Bobby output daunting on accessible page

	fyi


-- ------------------------------
Gregg C Vanderheiden Ph.D.
Professor - Human Factors
Dept of Ind. Engr. - U of Wis.
Director - Trace R & D Center
Gv@trace.wisc.edu, http://trace.wisc.edu/
FAX 608/262-8848
For a list of our listserves send "lists" to listproc@trace.wisc.edu

-----Original Message-----
From: 	owner-basr-l@trace.wisc.edu [mailto:owner-basr-l@trace.wisc.edu]  On
Behalf Of Charles Oppermann
Sent:	Sunday, May 14, 2000 3:07 PM
To:	uaccess-l@trace.wisc.edu; basr-l@trace.wisc.edu
Cc:	bobby@cast.org
Subject:	Bobby output daunting on accessible page

In response to a question about multiple selection controls in HTML, I wrote
an short page that demonstrates two examples of the <SELECT> tag in HTML.  I
used FrontPage 2000 to create the page and used it's built-in features to
create the <SELECT> elements, <LABEL> elements and ALT attributes.  I then
took time to tweak the HTML for better accessibility by adding TITLE and
ACCESSKEY attributes.
The page is at
http://www.coppersoftware.com/Software/accessibility/select_example.html
.

I used LYNX 2.8.1 (Win32 version) to test the page and then ran it through
Bobby and was shocked to see the number of reported errors that were
returned on the page.  Here is a condensed list:
"P1 - Manual check" (apparently things that Bobby can't figure out on it's
own)
1.	Ensure that descriptions of dynamic content are updated with changes in
content.
2.	Make sure that style sheets transform gracefully.
3.	If any of the images on this page convey important information beyond
what is in each image's alternative text, add a LONGDESC attribute. (2
instances)
4.	If this table contains data in rows and columns (i.e. a spreadsheet),
have you identified headers for the table rows and columns? (3 instances)
5.	If any of the images on this page convey important information beyond
what is in each image's alternative text, add descriptive (D) links. (2
instances)

"P2 - Manual check"
1.	Mark up quotations with the Q and BLOCKQUOTE elements.
2.	Did you avoid using movement where possible? (2 instances)
3.	Make sure that headings are nested properly.
4.	Do not use pop-up windows or change active window unless the user is
aware this is happening. (1 instance)
5.	Do labels of all form controls immediately follow its control on the same
line? (8 instances)
6.	Have you provided a linear text alternative for all tables that lay out
content in parallel, word-wrapped columns? (6 instances)
7.	For long lists of selections, have you grouped items into a hierarchy? (2
instances)
8.	Style sheets should be used to control layout and presentation wherever
possible. (3 instances)

"P3 - Manual check"
1.	Use the ABBR and ACRONYM elements to denote and expand abbreviations and
acronyms.
2.	If this table is used to display data in rows and columns (i.e. a
spreadsheet), have you provided a summary of the table? (3 instances)
3.	Consider adding keyboard shortcuts to frequently used links. (1 instance)
4.	Specify a logical tab order among form controls, links and objects.
(2 instances)
5.	Identify the language of the text, and any changes in the language.

"Browser Compatibility Errors"
1.	Unknown attribute TABINDEX in element LABEL. for browser(s): HTML4.0 (2
instances)

While I got the "Bobby Approved" statement, what's disconcerting is the
sheer number of benign errors that are reported to the author that really
don't affect accessibility.  It's a huge negative reinforcement issue.
Instead of rewarding authors for doing the right thing, they are flooded
with minor issues.
Here's my perspective:  I've used a extremely popular tool to create a very
small page. I've worked to ensure accessibility by digging into the HTML.
I've tested it.  I know accessibility.  Yet I'm told there are 19 different
categories covering 41 problems!
It's not hard to see why people feel that accessibility is a burden.
Even when I do the right thing, like use Style Sheets, Bobby warns me:
"Priority 1, item 2: Make sure that style sheets transform gracefully."
Some of the reported problems are completely bogus, like:
"Priority 2, item 1:  Mark up quotations with the Q and BLOCKQUOTE
elements."
There are no <BLOCKQUOTE> elements in my document.
"Priority 2, item 3:  Make sure that headings are nested properly."
Why can't Bobby figure this out?  In my document, a H1 is followed by a H2
which is followed by another H2 then a H3.  No nesting problem there.  At
least err on the side of the author because even if I screwed it up, it's
not going to adversely affect the accessibility of the document.
"Priority 2, item 5: Do labels of all form controls immediately follow its
control on the same line? (8 instances)"
I really think this one is bogus.  The purpose of <LABEL> is to make a
programmatic association between a control and it's label text.  I use
<LABEL> in my code, yet I get this error.
"Priority 2, item 7:  For long lists of selections, have you grouped items
into a hierarchy? (2 instances)"
My selections have 3 items in each.  Bobby should have a cut off value so
this isn't displayed when less than X selections are used.
"Priority 3, item 4:  Specify a logical tab order among form controls, links
and objects. (2 instances)"
I did exactly that with TABINDEX in the <LABEL> tag.  Bobby should be smart
enough to know that the <SELECT> control was nested inside the <LABEL> block
and since the <LABEL> had a TABINDEX attribute should not report the error.
This one I can understand, since HTML 4 doesn't allow TABINDEX in <LABEL>,
thus the following error:
"Unknown attribute TABINDEX in element LABEL. for browser(s): HTML4.0 (2
instances)"
Internet Explorer allows for TABINDEX to be placed in nearly all elements, a
major boost for accessibility, but since it's not part of HTML 4.0, it's not
considered.  So while I've great enhanced the accessibility of my page by
using TABINDEX, it actually generates a warning message.
If the community wants to prove that accessibility is not a burden to
authors and that the benefits outweigh the cost, I suggest restructuring the
Bobby output to focus on the positives, highlight major errors and hide
minor issues from the summary, allowing authors to dig deeper if they
choose.  But if we're going to harp on Header nesting and incorrect usage of
<BLOCKQUOTE>, then the recently expressed concerns of the authoring
community are valid.
Charles Oppermann
Copper Software
http://www.coppersoftware.com
chuckop@coppersoftware.com

Received on Sunday, 14 May 2000 16:26:36 UTC