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

RE: WAI Guidelines Naming

From: Phill Jenkins <pjenkins@us.ibm.com>
Date: Fri, 30 Jan 1998 14:43:43 -0500
To: <w3c-wai-gl@w3.org>
Message-ID: <5040300011913428000002L082*@MHS>
My new comments are marked PJ::  Some of the discussion is leaning towards
"what should be in the charter", which does influence the "title" of that
charter's output, namely the guideline.  If  you want, we could create new
threads for each group's charter and guideline content and leave it up to the
chairs to "pick" the title.

Phill Jenkins, IBM

WAI Accessibility Guidelines: Master Reference
JG:...a name that reflects that this set deals with the fundamental issues and
the interactions between the other guidelines? For example: Issues and
Strategies for WWW Technology Accessibility
GV: How about "Central Reference Document"
JB: WAI Accessibility Guidelines: Central Reference

PJ:: I prefer "Master", but as long as it's clear in the charter that this is a
total collection of all the guidelines with additional explanation as to why
something is in one guideline versus another.  We could also delete "Central or
Master" and just have "Reference" WAI-REFERENCE.

WAI Accessibility Guidelines: Browsers
PJ: ...Guidelines: Browsers and Assistive Technologies
AG: ...Actually, User Agents is very clear
DD: I like Al's "Client Software"
JB: Not as clear nor familiar to many as "Browsers"
JW: ...WAI client software user interface guidelines
JB: ...also looking at issues between browsers & assistive technology;
JB: ...guidance that [accessibility] are fully implemented.  So, I think that
takes us back to:WAI Accessibility Guidelines: Browsers

PJ:: I missed any discussion on why not "Browsers and Assistive Technologies".
This title would include client AND SERVER software, user interface, and use
terms very familiar yet not so narrow. Again, the charter is more important to
me than the title.  The guidelines need to include where the browser
developer's responsibility stops and where the screen reader developer's
responsibility starts.  The older "dumb" screen reader developers may have some
development to do...

WAI Accessibility Guidelines: Page Authoring
PJ: I really like the 'old EXISTING' title of MARKUP guidelines...
JB: Markup was confusing to a # of people, we kept getting questions.
DD: ...these guidelines are really for people that *knows* about the Markup,
not just people authoring pages with a nice GUI tool. So I prefer Markup too.
JB: ...If these guidelines are only for people who really know technical
mark-up in depth, then we've missed part of our task.  But I think they're for
both, so I'm still rooting for Page Authoring.

PJ:: I agree that the charter is for both, but the title "Page Authoring" seems
to emphasize the using of authoring tools over the marked up source.  It is
guidelines on how the markup should be regardless of editor, or GUI tool, or
auto-generation on-the-fly wizard server and client software generating the
HTML markup.  So I'm back to "HTML Markup".

WAI Accessibility Guidelines: Authoring Tools
PJ: I would add "hosting" to include other tools...
DD: I don't really understand what Hosting means in that context.
DD: The AU group charter doesn't specify, so it's for both.

PJ:: I withdraw my nomination for adding"hosting" and suggest "Web Site
Building Tools".  Here is a snipet of a recent tool manufacturer's
announcement.  This manufacturer is one of the intended readers of this
guideline along with the HTML MARKUP guideline: NetObjects Fusion 3.0 offers
Web site builders an open site-building environment, providing... easily lay
out pageS, control and edit HTML code, adding DHTML-based interactivity and
animation, publish for different browsers, and integrate sites with existing
databases and commerce applications.
Received on Friday, 30 January 1998 14:46:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 16 January 2018 15:33:26 UTC