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

WAI AU guidelines comments

From: Rob Cumming <nugget@sausage.com.au>
Date: Tue, 12 Jan 1999 16:23:10 +1100
To: <w3c-wai-au@w3.org>
Cc: "Charles McCathieNevile" <charles@w3.org>
Message-ID: <001701be3deb$a4ed8130$13c118cb@madness.sausage.com.au>
Hi everyone,

As a means of introduction, my name is Rob Cumming and I am the Product Development Manager at Sausage Software.

As the person responsible for defining product direction, functional specification and interface design in HotDog
Professional, Charles McCathieNevile has invited me to comment on the various WAI guidelines currently under
development.

From and ideological perspective, we (Sausage) totally support the creation of universally accessible HTML and hence are
keen to support this initiative. HotDog already generates standard markup as defined by the W3C, and as a Text Authoring
tool we allow complete user control over the markup they produce. By default we would accept any W3C "best practice HTML
code techniques" as a given. Thus my assessment of the guidelines is purely from the business perspective: logistics of
implementing them into our existing Authoring Tool (HotDog), whether our users would accept them, and what viable
alternatives there are.

After accessing the current guidelines and techniques I came to the following conclusions.

1. The formation of a base level accessibility specification, regardless of the guidelines.

In their current form the guidelines provide a (scattered) "range" of suggestions and solutions to ensure accessibility
for a "range" of target  users and user agents.

Accessibility must be clearly defined in black and white, not in 256 shades of grey. You cant be "a little bit
accessible".

Using your current guidelines it is completely unfeasible:
- For a Webauthor to create and maintain multiple varieties of markup,
- For their Clients to evaluate whether the Websites created for them, comply and which target users they are then
accessible to.
- For Application developers to create products that allow the above in an automated, user-friendly way,

Unless there is a clear, concise, set of standards that define "universally" accessible markup I would seriously doubt
that your guidelines could feasibly be adopted.

I would suggest that the guidelines be categorized into the following zones:

_____________________________________________________________________________

Base Level "Universal" Accessibility compliance:
i.e. Aurally, Visually handicapped user with HTML 3.2 text only User Agent (specialized text to speech compliant etc.).

HTML 3.2: Accessibility compliance/Best Practice:
i.e. all techniques recommended for HTML 3.2, hence universally accessible in V 3.0 browsers.

HTML 4.0: Accessibility compliance/Best Practice:
i.e. all techniques recommended for HTML 4.0 (apart from CSS), hence universally accessible in V 4.0 browsers (generally
gracefully downgradable to V 3.0 browsers)

CSS Stylesheet: Accessibility compliance/Best Practice:
i.e. all techniques recommended for CSS 1 (and in future 2), hence accessible in V 4.0 browsers (but not necessarily
gracefully downgradable to V 3.0 browsers)
______________________________________________________________________________

Basically my rationale behind this is threefold:

1. Universal compliance standard ensures that there is a base definition of HTML markup that can be accessed by
absolutely anyone with any user agent.

With one unbending standard, based on fairly low level markup it is much more feasible for Application Developers to
create and maintain a singular automated testing/conversion tool. With these tools available, it is then far more
feasible for Governing Bodies to enforce compliance and hence far more likely for Web Authors to create pages (or
alternative pages) that comply.

2. Generally each level of HTML markup, naturally lends itself to certain HTML techniques used by both Application
Developers and Web Authors, which guarantee a desired end result in the target browsers.

Categorization/association of best practices with their related HTML standard ensures easy promotion and then adaptation
(by both Application Developer and Web Author) of the correct technique when utilizing that set of markup. It removes
the confusion of recommending a blanket set of techniques, some of which are irrelevant to certain levels of markup. It
allows Application Developers to create applications customizable to various levels of HTML markup with accessibility
issues fully integrated, rather than as a noticeable addition. It also allows easier compliance categorization as well:

for example...
This website is Universal accessibility compliant.
This website is NS/IE 3.0 accessibility compliant.
This website is NS/IE 3.0/4.0 accessibility compliant.
This website is NS/IE 4.0 CSS accessibility compliant.

3. By separating guidelines into clear, concise, easily identifiable zones, there is no possibility for confusion. Even
the smallest amount of confusion will result in reluctance to enforce and adopt  the standards, or someone finding
loopholes in the standard allowing them to claim compliance with little or no effort.

In addition to these categories I would also note the following:

The base "Universal accessibility" specification would require significant changes both aesthetically and structurally
to most modern Websites. Thus to be compliant to this level, "the Webpage must conform to Universal accessibility
specifications OR provide sufficient accessible links to one that does".

WebAuthors can then comply to this standard without compromising specialized design or layout techniques by maintaining
a second, much simplified Universally accessible site to their main one. This fairly onerous task could be eased with
the creation of automatic conversion Applications, which would be possible if the target standard is of a fairly
simplified level of markup.

In my opinion, the techniques suggested for the other HTML standards are not overly onerous for Application Developers
or WebAuthors to implement as long as they are categorized and enforced in the above fashion.

The only other comment I would make would be that the issues of Page Authoring Accessibility and User Agent
Accessibility should be completely separate issues.

I hope that this appraisal makes sense and is of some help to your discussion. Please don't hesitate to contact me
regarding any of the above comments.

Regards

Rob

____________________________________________
  Robert Cumming: nugget@sausage.com.au
         Product Development Manager
    Sausage Software: www.sausage.com
____________________________________________
   HotDog has consistently been the most
  popularly downloaded Web Authoring Tool
   on the Internet over the last 3 years,
      according to CNet's download.com.

Sausage Software has a registered userbase
   of over half a million Web developers.

     http://www.sausage.com/hotdog5/

____________________________________________
Received on Tuesday, 12 January 1999 00:23:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 22 September 2008 15:52:54 GMT