RE: Bobby output daunting on accessible page

Charles was with Microsoft but is now at

> Copper Software
> http://www.coppersoftware.com
> chuckop@coppersoftware.com

I guess that would make him  a    Copperman

Gregg

-- ------------------------------
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: 	w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org]  On
Behalf Of Bruce Bailey
Sent:	Monday, May 15, 2000 1:56 PM
To:	GL - WAI Guidelines WG (E-mail); chuckop@coppersoftware.com
Cc:	uaccess-l@trace.wisc.edu; basr-l@trace.wisc.edu
Subject:	RE: Bobby output daunting on accessible page

Yep.  The Bobby report is verbose to the point of being useless.  The CAST
folks think that this is a feature.  What can be done?

Isn't Chuck Oppermann the name of the head disability wok at Microsoft?

> -----Original Message-----
> From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org]On
> Behalf Of Gregg Vanderheiden
> Sent: Sunday, May 14, 2000 4:26 PM
> To: GL - WAI Guidelines WG (E-mail)
> Subject: 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 Monday, 15 May 2000 16:24:37 UTC