Why FrontPage is not a good tool for accessible design (Re: Best tools for accessible design?)

Valid HTML is a pre-requisite for accessible design. Several of FrontPage2000's features generate INVALID HTML. These are just some examples:
- Shared Borders generates a META tag such as:
  <meta name="Microsoft Border" content="...">
  "name=" takes an identifier, a single word, not an arbitrary string.
- Same goes for Themes:
  <meta name="Microsoft Theme" content="...">
- The Search component generates invalid HTML in the Search form.

Even beyond the invalid HTML, there are other accessible design problems. An example:
- Text Navigation bars are necessary, but insufficent. FP generates a horizontal menu which looks like this:
  [ Topic1 ] [ Topic2 ] ... 
  Vertical dividers. please! There's also no automated means of wrapping the navigation bar with a "skip link."

Don't believe me? Run any FrontPage-generated Web site against the W3C HTML validator and see how many errors you get. Or run it against Bobby for even more fun. Don't challenge complainants for "specific examples" of invalid HTML or accessibility problems. Check it out yourself before you respond.

And please, DON'T tell me I can cleanup FrontPage-generated HTML "by simply switching to the HTML view"! I might as well use NotePad. Or vi. Or switch to another authoring tool which actually understands HTML instead of one which "you can configure ... to control which browsers and browser technologies are enabled within the user interface." I code to standards, not "browsers."

I speak from experience. I've used FrontPage 97, 98 and 2000. I continue to use both FP98 and FP2000. For non-accessible intranet Web sites, where validity and accessibility concerns can be managed in a controlled environment, it can be sufficient. For public sites, I feel it's insufficient. I find it a useful tool for rapid prototyping of Web page layout, site structure, etc. Once that's done, I have to rebuild all the invalid FrontPage features using my own HTML and other, non-FrontPage server-side facilities just to have valid HTML, let alone accessibility.



-----
<sig>
<author>Chris Kreussling</author>
<disclaimer>The views expressed are 
those of the author and do not necessarily 
reflect the position of the Federal Reserve 
Bank of New York or the Federal Reserve 
System.</disclaimer>
</sig>

>>> Terry Crowley <tcrowley@microsoft.com> 10/23 2:11 PM >>>
Fine by me.  I've seen a couple messages go by on this list referring to
FP2000 that didn't seem completely accurate from an overall perspective -
I'd love to clarify any questions there.

Do you have specific examples you're referring to with respect to "valid
code" or "pages that are accessible"?  The specific issues that I'm aware of
that have been discussed on this list are the issues of inserting a DOCTYPE
by default and the fact that there is no WYSIWYG interface for placing an
alt attribute on AREA tags.  I believe there's already been a response on
the DOCTYPE issue (this is relatively easy to do by simply switching to the
HTML view and pasting it in, or by changing your default template so that
all new pages will get one automatically).  I don't really have a response
on the alt attribute on AREA tags (unless you want to hear the history of
how our original WYSIWYG hotspot tools (from 1995) would automatically
handle generating the various different server-side image map files (all
different formats) before client-side imagemaps existed).  That became less
interesting/useful once the installed base of browsers supported client-side
image maps, but there continued to be some consequences to our internal
architecture.

Clearly, when picking a tool to use you need to look at the overall issues.
One point to note where FP2000 can help generate accessible content is that
the navigation bar tools allow you to automatically generate navigation bars
with appropriate alt tags and to generate text-only versions of the
navigation bars that are guaranteed to stay in sync with the graphical bars.
I'm not trying to make a sales pitch here, I just think it makes sense to
look at the overall picture in making any kind of decision like this.

Terry


-----Original Message-----
From: Kathleen Anderson [mailto:kathleen.anderson@po.state.ct.us] 
Sent: Monday, October 23, 2000 9:41 AM
To: Terry Crowley; 'Kristi R Schueler/NONFS/USDAFS'; w3c-wai-ig@w3.org 
Subject: Re: Best tools for accessible design?


I vote to keep this discussion on the list, as I would like to participate,
please. It's a subject near and dear to my heart.  FrontPage 2000 used in
WYSIWYG-only mode does not produce valid code or pages that are accessible.
However, there are workarounds for some issues and for the others, you need
to use the "HTML mode' to fix them. I don't know if FrontPage as a tool is
accessible, however, there is accessible documentation at:
http://www.microsoft.com/enable/products/docs/frontpage2000.htm 


Kathleen Anderson, Webmaster
Office of the State Comptroller
55 Elm Street
Hartford, Connecticut   06106
voice: 860.702.3355 fax: 860.702.3634
e-mail: kathleen.anderson@po.state.ct.us 
URL: http://www.osc.state.ct.us/ 
URL ACCESS: http://www.cmac.state.ct.us/access/ 



----- Original Message -----
From: Terry Crowley <tcrowley@microsoft.com>
To: 'Kristi R Schueler/NONFS/USDAFS' <kschueler@fs.fed.us>;
<w3c-wai-ig@w3.org>
Sent: Monday, October 23, 2000 12:24 PM
Subject: RE: Best tools for accessible design?


> Note that you can configure FrontPage (FP2000) to control which browsers
and
> browser technologies are enabled within the user interface.
>
> By the way, which tags are we "notorious" for?  (I *knew* we never should
> have put that Insert/Marquee command on the menus...)
>
> This continued thread is probably off-topic - feel free to reply directly.
>
> Terry Crowley
> FrontPage Development Manager
>
> -----Original Message-----
> From: Kristi R Schueler/NONFS/USDAFS [mailto:kschueler@fs.fed.us] 
> Sent: Monday, October 23, 2000 9:16 AM
> To: w3c-wai-ig@w3.org 
> Subject: Best tools for accessible design?
>
>
> I am needing to make some decisions on the what software we purchase.
> Previously they have been using old versions of FrontPage, but since they
> are notorious for using proprietary tags that are not HTML 4.01 compliant,
> I have campaigned for a change in web authoring tools.  Now, I have to
tell
> them which to get.  Does anyone have any recommendations?  Thanks for any
> help you can offer!
>
> Kristi Schueler
> USFS - WOD,  FC AQM Systems
> Web Developer (contractor)
> (970)295-5801 (voice)
> (970)295-5809 (fax)
>
>

Received on Tuesday, 24 October 2000 10:45:09 UTC