W3C home > Mailing lists > Public > html-tidy@w3.org > October to December 2001

Re: [Tidy-dev] Accessibility checking in Tidy

From: Charles Reitzel <creitzel@rcn.com>
Date: Tue, 06 Nov 2001 20:41:31 -0500
Message-Id: <>
To: "Chris Ridpath" <chris.ridpath@utoronto.ca>
Cc: <html-tidy@w3.org>, "Terry Teague" <terry_teague@users.sourceforge.net>, <tidy-develop@lists.sourceforge.net>, <mikes.lam@utoronto.ca>
The reason I ask for the ability to distinguish accessibility messages vs. 
other Warnings and Errors is to give me flexibility in how my application 
responds to the condition.

For example, I personally used Tidy to screen HTML that gets posted to our 
in-house Content Management System (CMS).  I run tidy in a CGI by shelling 
out to a command line and grab the standard error.  I filter this to only 
show Warnings and Errors and throw away the "info" text that sometimes 
appears.  We are not a government body, so I can see an initial deployment 
where we run Tidy to show accessibility priority 1 items, but treat them as 
warnings - i.e. let publication proceed.  Currently, we do not allow any 
warnings at all.  This way, I can raise authors' awareness of accessibility 
issues without unilaterally forcing a large editing burden on them.

How about a compromise?   Treat all accessibility messages as a separate 
severity (e.g. Info, Warning, Access, Error).  This, in combination with 
the existing command line option, will give me all the flexibility I need.

Thinking about it, this change would make a great test case for the library 
version of Tidy.  I.e. it doesn't appear to have required substantial 
changes to the parser or pretty printer.  Thus, in theory, you could use 
Tidy to load the tree and implement the accessibility checker by traversing 
that tree (with an API like we discussed back in May).  If possible, I'd 
like to do just that when we get to the library form of Tidy Real Soon Now.

take it easy,

At 04:34 PM 11/6/2001 -0500, Chris Ridpath wrote:
>We can identify the priority level of the accessibility error in the
>warning/error message if that would be helpful.
>Our initial thought was that since you specified the error level on the
>command line that you didn't need it for each error/warning message.
>We're working on some explanation text for each warning/error and expect it
>to be done in 2 weeks.
>I'm not sure how this would be integrated with the program. Should we have a
>"verbose" mode where you get a about a paragraph of explanation for each
>----- Original Message -----
>From: "Terry Teague" <terry_teague@users.sourceforge.net>
>To: <html-tidy@w3.org>
>Cc: <tidy-develop@lists.sourceforge.net>; <chris.ridpath@utoronto.ca>;
>Sent: Tuesday, November 06, 2001 3:48 AM
>Subject: Re: [Tidy-dev] Accessibility checking in Tidy
> > At 10:58 AM -0500 11/5/01, Charles Reitzel wrote:
> > >My immediate response:  Great! Let's do it.
> > >
> > >Nits to pick:
> > >
> > >1) Should Accessibility warnings be identified as such?  Perhaps even
> > >their own "severity level".  E.g. Info, Warning, Access, Error.
> >
> > At the moment, the Accessibility warnings are similar to those for the
> > of Tidy. There was talk at one time of improving the Tidy error msgs to be
> > similar to what you proposed above - I think that will have to wait for a
> > future version.
> >
> > What I haven't done - in the original code, there was a "-notidy" option
> > only do accessibility checking and none of the rest of the Tidy stuff; I
> > didn't think this was necessary, so I didn't implement it. But what I
> > do is add some kind of divider line between the accessibility error
> > and the other errors.
> >
> > Waiting on further info from Mike/Chris regards error msgs.
> >
> > >2) Accessibility warnings should identify the "level" of compliance (A,
> > >AAA)?
> > >
> > >With these changes, it will be easy for HTML developers to prioritize
> > >accessibility efforts.  After all, it will take time to move existing
> > >bases over.  Tidy can be used as a diagnostic and management tool.
> >
> > I guess if you specify "-access 1" and you get no errrors/warnings, the
> > "level" of compliance would be "A"; similarly for "-access 2"/"AA" and
> > "-access 3"/"AAA".
> >
> > Perhaps this is something that Mike/Chris could be thinking about regards
> > any accessibility error summary.
> >
> > >Side question: is the "Error: suspicious 'href': has invalid file
> > >extension." new?  With server side URL re-writing/mapping, I don't think
> > >you can validate URL file extensions at all.
> >
> > >>
> > >>Accessibility Checks: Version 0.1
> >
> > >>line 66 column 51 - Warning: 'href' may reference to sound file.
> > >>line 67 column 41 - Error: suspicious 'href': has invalid file
> >
> > Perhaps the grammar in the first error could be improved.
> >
> > As for the invalid file extension issue, I need to be careful not to have
> > platform specific implementation of the checking code - I rewrote the
> > original Windows centric code with a more general solution that I haven't
> > really checked into since I wrote it.
> >
> > Regards, Terry
> >
> >
>Tidy-develop mailing list
Received on Tuesday, 6 November 2001 20:31:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:38:51 UTC