Re: WAI AU guidelines comments

> HotDog already generates standard markup as defined by the W3C,

This statement makes me wonder if we shouldn't strenghten the
guideline about generating valid markup to be generate *only* valid
markup (not that I know or think HotDog doesn't do that already, just
wondering about it).

> By default we would accept any W3C "best practice HTML
> code techniques" as a given. 

I wonder what "accept" mean ?
Does it mean you will implement them by default ?

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

It's unclear if you mean accessibility of the tool or of the markup
itself.

We do have a separate guideline describing accessibility of the
formap/markup itself (w3.org/wai/gl).
 
> 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.

I agreed there is too much "scattering" and I think we ought to focus
more on mainstream browser.

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

As a matter of fact, I think you can be a little bit accessible, or
completely accessible; there are so many variants.
 
> Using your current guidelines it is completely unfeasible:
> - For a Webauthor to create and maintain multiple varieties of
> markup,

I understand this is a reality for some web design shops, but given
that W3C promotes a unique standard markup, we clearly do not want to
encourage multiple varieties of markup.

My take is that our role is to describe what ought to happen in a
context of one HTML markup standard, not to procude a patchwork of
techniques that deals with the legacy mess of the web browser
features.

> - For their Clients to evaluate whether the Websites created for
> them, comply and which target users they are then accessible to.

The concept of "target users", and by that I assume you mean "users of
Netscape 3.0", or users of "Opera 1.0", is another aspect we discussed
in the GL working group in the past (WG on guideline for content, not
for tools) and that we rejected as a foundation for our work, because
it runs contrary to W3C interoperatility goals, even though I
understand it represents a market reality today (how important, that's 
the question).

> 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)

HTML 4.0 is a superset of 3.2, one that was carefully designed to be
backward compatible. So if a tool generates 4.0 markup, it should be
equally readable with a 3.2 browser.

Example: HotMetal Pro 5 lets me add a longdesc (new in HTML4)
attribute to my IMG, which is just ignored by Netscape or IE. Same
thing for Table Markup, Frame, FORM, etc.

The issue with use of CSS is a little be trickier, as one can choose
to generate CSS only (and then to degrade on browser that do not
support, or poorly support CSS), or to generate a combination of CSS
and HTML 4 transitional (a standard version of HTML4 that still
includes all the presentation markup). But it's possible to be
compliant.


> 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.

That's HTML 4.0
 
> 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.

Next you need:
This website is NS/IE 3.0 on Windows 95 accessibility compliant.
This website is NS/IE 3.0 on Windows 98 accessibility compliant.
This website is NS/IE 3.0 on Macintosh System 7 accessibility compliant.
etc

> 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 is exactly what we want to avoid: have authors think they need to
duplicate their entire site to be accessible.

If you look at www.microsoft.com or www.w3.org with a text-only
browser like lynx, you'll see that they are both accessible (both
suffer from information overload syndrom, but that's a different
story).

> 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.

They should be, we have 3 sets of guidelines: for the content, for the 
browser, for the editor.
 
> 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.

It's very helpful to have your opinion.

The issue of market reality vs. W3C lead is important. My personal
position is that W3C should try to define the future/ideal reality,
and not endorse a particular reality, or we will not evolve but
fragment.

Received on Tuesday, 12 January 1999 08:31:55 UTC