RE: Bobby output daunting on accessible page

Thank you Michael.

Cynthia D. Waddell

---------------------------------------------------
Cynthia D. Waddell   
ADA Coordinator
City Manager Department
City of San Jose, CA USA
801 North First Street, Room 460
San Jose, CA  95110-1704
(408)277-4034
(408)971-0134 TTY
(408)277-3885 FAX
http://www.icdri.org/cynthia_waddell.htm



-----Original Message-----
From: Michael Cooper [mailto:mcooper@cast.org]
Sent: Wednesday, May 17, 2000 4:21 AM
To: uaccess-l@trace.wisc.edu; basr-l@trace.wisc.edu; w3c-wai-gl@W3.ORG
Cc: chuckop@coppersoftware.com; w3c-wai-er-ig@W3.ORG; bobby
Subject: RE: Bobby output daunting on accessible page


Hi all - sorry to make such a delayed response to this thread, I just got
the messages today, my email access has been sporadic during my time in
Amsterdam.

I'll start by seconding what Phill Jenkins and Chuck Hitchcock have already
said - we do attempt to provide completeness of coverage of the guidelines;
currently this is at an expense of usability, which we fully acknowledge and
are working on solutions. Coming up with these solutions requires
significant design time, and we benefit greatly from feedback in forums such
as this and our email at bobby@cast.org. Implementing solutions is also a
large task for us in the current architecture, which is several years old,
so the solutions have not come as quickly as many, including us, would like.
We have a plan in place to rewrite Bobby from the ground up, with the
specific intent of creating an architecutre that will enable us to address
issues like this more quickly; we also want to enlarge the team to improve
our response time. We have not yet ascertained how to fund this enlargement
of the project as new sponsors have been slow to appear, but we are working
on this and I am hopeful that we will in fact be able to move forward on
that work soon.

In the meantime, we have focused our efforts on developing a version 3.2
that, more or less, addresses the largest issues that have been brought to
us. Many unexpected development cycle issues have delayed this release,
including most recently the loss of our previous programmer, but we do think
we are close to that release. As Phill mentioned, one of the projects has
been to add the ability to filter guidelines out of the report that you
don't want. The filter can be on the basis of a particular priority level,
or on the "automaticity" of the guidelines so you aren't presented with
issues that may or may not be relevant to a particular page, etc. The "Bobby
Approved" rating will continue to require compliance with all Priority 1
checkpoints, so users who use this filter option will need to account for
that if they seek to claim Bobby Approved status. For many people, though,
that is not the goal and the suppression of unwanted checkpoints will
increase the relevance of the report.

The other major goal for this release has been to improve the accuracy of
our evaluation as much as possible within the current architecture. Again,
Phill mentioned the guidelines from the WAI Evaluation and Repair group, to
which we have actively contributed and from which we have drawn extensively
in the 3.2 implementation. We have moved many items from "partial detection"
to "complete detection" status, and many more from "no detection" to
"partial detection" status, so this version will also be inherently more
useful even without the report filtering option.

Here I should describe the distinction between the above detection types,
which I think is at the core of the confusion I see here. Again, I
acknowledge that the wording of the report does not explain this well, and
we are trying to find a terse wording [a non-terse wording would introduce
another usabilty problem] that will do so. Broadly, "complete detection"
items can be detected definitively by Bobby. "Partial detection" items are
more confusing - it means a trigger exists which tells Bobby it needs to ask
a question, but it cannot answer the question fully on its own. For example,
if a <TABLE> is found, there are guidelines that apply only if the table is
used for layout, and others only if it is used for data, but Bobby does not
have a heuristic to determine which role the table plays, so it has to ask,
as in "If this table contains data in rows and columns ...". For another
example, we have not yet written a module to allow Bobby to evaluate script
languages, so whenever it detects a <SCRIPT> element it has to ask a series
of questions related to scripts. The third category, "no detection", is
straightforward though not clearly differentiated from the others in the
report; basically there are no particular triggers we could give Bobby, such
as the checkpoint to use navigation bars - there is no <NAVBAR> element, so
any group of images and/or links may or may not be a navigation bar. Bobby
just asks those questions in every report.

I could go over each of the Bobby report items that confused you and fit
them into the explanations above, but that's probably not a good use of this
forum. Let me just speak to a couple that are especially relevant. The one
about properly positioning form labels - that is triggered actually be the
presence of form controls, not <LABEL> elements. This is because it's a
backwards-compatibility checkpoint; people whose browsers, screen readers,
Braille displays, etc. don't support the <LABEL> element have no way of
knowing which piece of text functions as the label for a form control except
by positional context. So proper use of the <LABEL> element does not,
currently, remove the need to also consider label positioning. Another
example, the advisory to use Q and BLOCKQUOTE elements - this is one of the
ones asked on every page - Bobby can't detect the presence of quotes on the
page that may need this markup, so it's just asked. Finally, the browser
compatibility error - I tend to see those as advisories - they indicate
elements, attributes, and values that are not supported by a particular
browser. However, browsers support different sets (thus the need for browser
compatibility tests), and since the usual behavior is to ignore unknown
elements and attributes, if you know something functions properly in one
target browser it's probably ok for the rest. Note too that as far as Bobby
is concerned HTML 4.0 is a "browser" even though it's really a
specification.

We've been working on the explanations of these items (that you get by
selecting the hyperlinked error title in the report) and hope they will also
be much clearer in Bobby 3.2.

The best ways you can help us to reduce confusions caused by Bobby's
implementation of the Guidelines is to send us feedback to bobby@cast.org
and, if you represent an organization that is a potential funder, contact
our development officer, Don Giller, dgiller@cast.org. I assure you that we
are committed to providing the best support for the guidelines possible for
us, and to keeping Bobby available for free at the same time. Many thanks to
our funders who have made the current work possible: IBM Special Needs
Systems, Microsoft Accessibility, Misubishi Electric America Foundation, Sun
Microsystems Enabling Technologies Program, and HalfthePlanet.com.

Michael Cooper
Bobby Project Manager
CAST, Inc.
39 Cross St.
Peabody, MA  01960
Tel +1 978-531-8555 x265
TTY +1 978-538-3110
Fax +1 978-531-0192
Email mcooper@cast.org
http://www.cast.org/
http://www.cast.org/bobby/

-----Original Message-----
From: owner-uaccess-l@trace.wisc.edu
[mailto:owner-uaccess-l@trace.wisc.edu]On Behalf Of Charles Oppermann
Sent: Sunday, May 14, 2000 4:07 PM
To: uaccess-l@trace.wisc.edu; basr-l@trace.wisc.edu
Cc: bobby
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 Wednesday, 17 May 2000 12:51:38 UTC