Re: Aie it's HUGE

Chris,

I am coming from the background of an instructional designer, not a
skilled html author. Designing Hypertext documents in Hypercard or
Toolbook allows the creation of templates that assist the teacher in
actually creating their own document and removes all unnecessary
scripting language needed to accomplish this prior to creating a "read
only" document for student use.

My limited experience with creating a template with a blank html table
cell is that this process should not delete any accessibility codes
already contained in the html source code when someone enters text into
the blank cell when using an authoring tool like FrontPage.

Another approach is the use of a wizard that asks questions and then
produces a blank html FrontPage document. A template that asks questions
and automatically converts the results into a useful screen design is
what I envisioned. I imagined that a question would be asked as follows:

Is this document to be an English only document?  Yes  No
A yes answer would add the specific code for a text reader.
A no answer would provide a list of other languages (Spanish, French,
Russian, etc.) and the selected language would be incorporated into the
hidden code.

Is this concept beyond the abilities of the technical committee? It
would facilitate the expansion of accessibility of web sites if such a
template could be developed.

I appreciate your thoughts and possible assistance.
Claude Sweet




> >>> Claude Sweet <sweetent@home.com> 12/08 1:22 PM >>>
> Is it not possible to have templates designed to be fully accessible
> that other individuals could use FrontPage as a means of inserting
> information?
> <<<
> 
> Regardless of the tool, page templates or skeletons are not enough. Once the author begins to modify the page, they could easily remove the accessibility features which were built into the original template. The tool needs to apply accessible features as the page is edited. Accessibility considerations must be built into the tool.
> 
> >>>
> My objective is the creation of a first class design with navigational
> tools that would NOT require two different sets of pages. While I don't
> have the expertise to presently write such code, I believe that this is
> something that should be part of the Guidelines (standards).
> <<<
> 
> It's definitely possible to create accessible pages and sites without requiring two (or more) different sets of pages. This is one of the educational challenges facing WAI and other efforts: Accessibility does *not* mean double the work! It does mean more design and analysis time up-front, but not a lot more. It does require ongoing consciousness and attention to the issues on the part of authors as they create new content and modify existing content. Like it or not, some people prefer to remain unconscious [g].
> 
> >>>
> I doubt seriously that I can inspire teachers and students that they
> must become experts in html accessible pages. More must be done to
> facilitate the development of accessible materials without requiring
> such html expertise. Failure to provide a lower entry level of expertise
> will exclude 90% (in my opinion) of the existing non-commercial sites on
> the web, especially educational site of k-6 schools.
> 
> Non-profit organizations and educational sites (especially grades K-6)
> will be unable to participate in using the web if individuals are
> required to become expert html code writers able to comply with
> accessibility standards.
> 
> Non-profit groups, especially smaller organizations depend on volunteers
> and most will [not] have individuals who have such html expertise. School
> teachers primary job is not writing html code. To expect them to obtain
> such expertise is unrealistic and counter productive to efforts to
> involve students in using the web as a means of communicating with other
> classrooms as distance learning projects.
> <<<
> 
> Unfortunately, there are no currently available tools which don't require HTML expertise on the author's part while producing accessible HTML. For example: HTML allows an author to provide alternate text for the areas of a mapped/hyperlinked image. If a tool assists the author in creating a mapped image, does it also support, nay urge, the author to add alternate text for each mapped area of the image?
> 
> FrontPage 98, specifically, fails in several regards.
> 1) It doesn't support or recognize many accessibility-related HTML tags and attributes.
> 2) It automatically provides meaningless ALT text for images: the name of the file and its size.
> 3) Most egregiously, it modifys existing HTML to its own liking, destroying HTML which has been carefully crafted for accessibility. To protect HTML it must be "wrapped" in a special FrontPage tag, which renders it invisible in the visual editor! Using the mapped image example, the image can't be seen in the visual editor! An author could easily delete the entire image without even knowing they'd done so.

Received on Tuesday, 8 December 1998 14:55:16 UTC