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

RE: WAI AU guidelines comments

From: Rob Cumming <nugget@sausage.com.au>
Date: Wed, 13 Jan 1999 17:08:03 +1100
To: <dd@w3.org>
Cc: <w3c-wai-au@w3.org>
Message-ID: <001301be3ebb$1455db10$13c118cb@madness.sausage.com.au>
I dont want to get myself typecast as a Capitolist Application Developer but I will plead my cause one more time and
then shut up ;o)

One main statement would be that I tried to review the guidelines from the perspective of "If I had to try to adopt
these principles in HotDog 6 (Due mid 99)". In this context HTML 3.2 still represents the level of markup that the
majority of our users want to work to, with perhaps a third of them seriously utilizing HTML 4.0 markup, perhaps a tenth
might dabble with CSS 1 and XML/CSS 2 dont even get on the radar.

Whilst I understand and totally agree that the W3C has to work towards an agenda of an ideal usage of technology,
application developers have to work toward an agenda of what is going to sell product. In mid 99 an accessibility
technique that is based on CSS 2 is completely useless to my customers and thus I dont even want to know about it.

In my discussion with Charles, he indicated to me that one of the major factors that would help get this initiative
moving would be the fact that the US (and other) governments were looking to adopt it as a prerequisite for any
content/applications purchased by them.

In my experience the average government official cant tell their head from their butt, let alone comprehend the
varieties of HTML techniques that are accessible in the varieties of user agents. Unless they have a simple clear cut
set of guidelines I am going to be able to walk up to the government purchasing officer, hand them my product and say
"gee look at all the longdesc's it inserts after the images" and 9 times out of 10 they will say "duh ok" and rubber
stamp me.

You can create a set of guidelines utilizing the latest  XML and CSS2 techniques with multi browser downgrade options
etc. etc. That can go and sit on a pedestal, with a brilliant ray of sunlight shining on it, angels singing in the
background etc.  But in the real world you also have to make a "one size fits all, base level" standard that works works
with todays legacy user agent systems and markup languages. Otherwise all those disabled people are going to have
cobwebs on them before they have a product that lets them navigate out of their ISP's home page.

I realize that I am being a bit melodromatic, but what I am trying to say is if you dont set a more realistic target,
all this great work is either going to go into the "too hard basket" or App Developers will only implement a half assed
version. Either way, the people it was created for are going to suffer.

I have also tried to insert a few clarifications inline below.

Rob

> -----Original Message-----
> From: Daniel.Dardailler@sophia.inria.fr
> [mailto:Daniel.Dardailler@sophia.inria.fr]On Behalf Of Daniel Dardailler
> Sent: Wednesday, January 13, 1999 12:32 AM
> To: Rob Cumming
> Cc: w3c-wai-au@w3.org; Charles McCathieNevile
> Subject: Re: WAI AU guidelines comments

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

Yes, within reason. If we had a function that inserted markup and W3C had a reccomendation for the technique to insert
the markup we would automatically implement the function in that way. If the technique was onerous or forced the user to
create a result that could be percieved to be undesirable in some circumstances, we would make it an option.


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

markup only

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

I would have thought that a better goal would be to promote the creation of content that could be accessible to all
people right now as well as some time in the future.

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

Creating a product that services market reality is the entire goal of Application Developers.  If it is important for
the W3C to have their guidelines widely adopted then they need to be designed in such a way that realisically allows me
to create a saleable product now, with the view to adopting further aspects of the technology as that market becomes
viable.

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

I agree, but what about my users who dont want to utilize (or are freaked out by) HTML 4.0, and CSS. I would simply
reserve the right to present/check various accessibility techniques at the level of markup standard chosen by the user.

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

A large portion of current Web Authors dont use HTML 4.0 markup yet.

Conversely I cant see how simply by using HTML 4.0 you somehow satisfy the users who would otherwise require additional
navigation such as suggested in WAI Authoring Tools Guidelines section 2.8 (text alternative of site map).

I am not trying to be podantic, I am simply trying to point out that Universal Accessibility is a  definition of what
works in "every" situation in the current web environment.

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

As an application developer all I care about is the definition of "Universal Accessibility" compliant. Once I have this
definitition then that is all I will include in my application, to claim it as a feature. If you guys raise the bar and
state that correct use of HTML 4.0 is "Universally Accessible" then that is cool by me. I can include that level of
functionality in my application and claim that I have complied with the standards. Governments and Web Authors will buy
my application thinking they are doing the right thing but they will still create Web Sites that blind people cant
navigate and (even if I wanted to) I couldnt create an automated testing application that told them they had done so.

The reason why I split the definitions was to ensure that the base level represented a web page created using the
realistic base level of markup (HTML 3.2), which was still accessible to every (including disabled) users who could be
using any user agent i.e. the absolute lowest common denominator.

Above this level I cant absolutely guarantee content/techniques are accessible to every person but I can indicate the
group that it would be accessible to.

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

Yeah and as a graphic designer, both these sites are fairly uninteresting. There are certain design techniques that will
never be accessible (or are unfeasible to make them so) to certain groups, so the only feasible alternative is to create
an alternative page/site. Web Authors dont want a button in HotDog that when pressed always tells them that their
current page is not accessible to certain users, they want a button that when pressed will make a page that is.
Additionally unless held at gunpoint, most Web Authors would never sacrifice aesthetics for accessibility, hence I would
never create a product that would force them to do so. I am simply trying to create a situation where if all else fails
a viable alternative can be used.

____________________________________________
  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 Wednesday, 13 January 1999 01:08:21 GMT

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