Re: section 2.5 - charles' proposal and Jan's proposal

I apologize if this has been discussed already or is not pertinent to this
discussion - I may be way out of scope for these guidelines.  However, I am
curious how server-side scripting directives or other types of
place-holding elements that are not defined anywhere fit into the picture?  

For example, the WAI guidelines are all generated from "source" documents.
These documents are primarily HTML but also include directives for where to
pull information into the document at the time of generation.  For example,
there is a statement that says, "put a table of contents here" another that
says "put the references here."  However, I like to edit chunks of content
in a WYSIWYG editor and luckily, all of the directives are commented out
(e.g., <!-- processing directive -->) so this isn't an issue - for our set
of documents.  

These strategies won't be found in a DTD nor in a registry anywhere (I
assume).  This will further the problem that Jutta outlines, because there
is a slim chance at best that the tool could a. access the server-side
script then b. analyze the content it produces for accessibility.

I don't think we can assume that people using these types of templates are
versed in a markup language. A company could provide a template to all
employees regardless of markup language knowledge and say, "put your
content here. we'll generate the rest (nav bars, advertising, etc.)."

Perhaps this isn't an issue at all - if all directives are commented out
the tool will ignore them. but, i'm not sure that is a safe assumption,
either (unless it becomes an authoring practice....i can add something to
techniques for server-side scripting in the WCAG but that doesn't guarantee
anything).
--wendy

At 01:18 PM 4/21/99 , you wrote:
>In an attempt to get a handle on 2.5 I tried to restate the problem again.
>It basically boils down to wanting to:
>Prevent the removal of structure and content that adds accessibility but
>may be part of older or newer markup that is not supported by the tool,
>without preventing the tool from cleaning up the markup (which often helps
>with access).
>
>The dilemma is if the tool does not recognize the targeted elements how can
>it distinguish between elements that help access and elements that hinder
>access. Given the range of authors, it is highly unlikely that the average
>author can handle the decision making. If mechanisms and conditions exist
>that allow the tool to update and seek out information about the unknown
>markup over the web, thats great but we cannot depend upon that.
>
>Perhaps we need to become more specific without dating the guideline. Can
>we establish in W3 some registry of elements that are necessary for access
>in both older and newer markup languages and reference this in this
>guideline?
>
>Jutta
>

Received on Thursday, 22 April 1999 10:36:30 UTC