W3C home > Mailing lists > Public > w3c-wai-au@w3.org > January to March 1998

General approaches to making authoring tools access aware (was Re: Great Free Stuff!)

From: Jan Richards <jan.richards@utoronto.ca>
Date: Tue, 17 Feb 1998 11:56:55 -0500
Message-ID: <002801bd3bc5$0ea2fa80$2981968e@redoctober>
To: <love26@gorge.net>, <w3c-wai-au@w3.org>
By my previous comments I certainly did not attempt to imply that
accessibility is not a right.

However, a certain amount of strategic thinking on the subject is necessary
(1) the HTML specification as it has emerged (with input from WAI) does NOT
mandate accessibility.  Certain features and authoring practices that
present access barriers are still supported.  Therefore HTML editors can
still produce valid grammar HTML that is nonetheless inaccessible.
(2) it is somewhat unclear whether major corporate websites are LEGALLY
compelled to be accessible (and to what extent), let alone individual home
pages or personal (non-world accessible) HTML files.

The idea of using authoring tools to PREVENT users from writing pages (for
any use - including personal) that are readable by browsers and not strictly
illegal is unworkable.  People will simply turn to text editors and software
that do not include these restrictions.  The situation appears analogous to
income tax preparation programs.  If some programs allow users to claim a
large deduction that is generally frowned upon but legally unclear and
others do not, users will probably choose the less restrictive product.  The
software companies themselves would not seem liable (I am not a lawyer so I
may be wrong) if the deduction proves illegal since it is the user who is
ultimately responsible for the tax return, not the tool that they used to
prepare it.

Thus, barring changes to HTML that mean inaccessible pages won't be properly
parsed by browsers, or changes to the law that unequivocally force HTML
editors to produce accessible HTML; the solution is to work with the editor
developers.  There are many shades of grey between the present authoring
tool approach to accessibility and the refusal to save an inaccessible
document.  For example, Bobby-like markers or red underlines can be used to
keep the user constantly aware of errors.  If these markers lead quickly to
a highly automated help and correction system then they may be very

In my own experience, helping to design the accessibility checking system in
Softquad's Hotmetal 4.0, there were many stages where I wish more could have
been done to integrate and expand the system.  However, the company is a
much weaker competitor than Microsoft for example and any reduced focus on
the product as a whole or an overbearing presence of the accessibility
checking system would have meant a competitive disadvantage.  If this were
the case, all the work we had done might have been lost.  Instead, we have a
product that can serve as a first step towards true accessibility awareness
in editors of the future.  Importantly, this successful step was achieved
from within the constraints of the authoring tool market.  This is not to
say that advocacy is not needed to keep the pressure on. Microsoft FrontPage
could be accessible next week if sufficient resources and will were applied.

Jan Richards
Adaptive Technology Resource Centre
SoftQuad HotMetal 4.0 Accessibility Development Team
Received on Tuesday, 17 February 1998 11:52:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:39:41 UTC