Re: comments on section 4, ensuring that product documentation isavailable....

I agree. I have one clarification though.  if html or xml perhaps are
one of the formats of choice, and they or one of them is chosen as the
only media, then, we still have to use a browser to access the
documentation, so, drop the forms of documentation that require a
browser to use from the list and we have a good priority one item.  My
rationale for this is that if you are going to class to learn how to
use the tool and you don't have the tool available to use that having
a portable means of studying the documentation is a high priority.
Further, it is impossible for some people to work with something they
have not read about there fore fitting into the priority one class
this need for documentation.  Lastly, Explore though you might, if you
are in a situation where help is unavailable and the browser is
configured by default or by someone else in such a way as to render it
inaccessible, you have the documentation to start with.  This then is
priority one because it provides an anchor for a starting place that
cannot move.
Thanks.

>mark novak wrote:
>
> Jon:
>
> >Neil,
> >In the discussion at the December Face-to-face meeting these exact
> >arguements were presented in defence of documentation accessibility issue
> >being a priority 1.  I don't know of anybody in the working group that
> >doesn't think that accessible documentation is not important.  The
> >consensus of the group on level 2 was based on based on the following idea.
> >
> >If a company was chosing between making the documentation more accessible
> >and adding improved keyboard support, what would you want the developer to
> >do?  If both are priority 1 then to the developer they are equally
> >important.  So we want to limit the priority 1 to items that are most
> >critical for implementations.  In most cases the user can still use the
> >user agent even if the documentation is not completely accessible.
> >Remember a priority 2 still indicates very difficult, while priority 1
> >means impossible.
> >
> >
> >The issue is closed and can only be reopened if new information is provided
> >to the group on why the status should be changed.  You can review the
> >discussion of the the F2F meeting at:
> >http://www.w3.org/WAI/UA/1998/12/wai-ua-f2f-19981211.html#gl34
> >
> >
> >Jon
>
> thanks for the URL to the f2f notes, I've now had a chance to go back
> and review some of the history, that certainly helps.
>
> in short:
>
> at the risk of being a pest, I'm going to suggest that this "issue" is not
> closed and that this topic be re-opened for discussion?  While I didn't
> have access to the "document" used for discussion at the f2f meeting, I am
> concerned that most of that discussion seems to have centered around
> 3.4 "providing documentation about accessibility features" ,  which is
> considerably different than 4.1.2, "ensuring that product documentation
> is available in at least one accessible, open standard format
> (e.g., HTML, XML, ASCIII)."
>
> Therefore, I'd like to make the following proposal:
>
> Reword Guideline 4.1.2 as follows:
>
> Ensure that accessible product documentation is available (or
> available upon request ?).
>
> I'd also propose that this become a priority #1 item.
>
> Then, in the techniques document, I think the technique for providing
> this guideline should state something like (or whatever best words this):
>
> Accessible documentation may take an electronic format (ASCII, HTML, etc.),
> Braille, audio tape, large print, etc. ... and must be available upon user
> request.
>
> - with the key issue being, the user having access to whatever form best
>suites
> their needs when/if they request it.
>
> While not my first choice in solving this problem, I think this method
> still conveys the importance and responsibility to the UA developer for
> accessible documentation as requested, but should not take away from their
> ability
> (time and development team effort) to also create the best and most
> accessible UA,
> which meets as many priority #1 items as they can.
>
> thoughts ?
>
> mark
>
> >>The rationale is that even if the documentation is not accessible,
>somebody
> >>culd still use the user agent.  In general Priority 1 is reserved for the
> >>checkpoints that make it impossible for people to do without the feature.
> >>Priority level 2 still indicates that it is very difficult if it is not
> >>accessible.
> >>
> >>We are trying to limit and focus the priority 1 to the items that are most
> >>essential for implementation.
> >>
> >>Jon
>
> >>>At 02:00 PM 2/18/99 -0500, mark novak wrote:
> >>>hi
> >>>
> >>>[ February 10th version ]
> >>>
> >>>along with Kitch's comments, I was wondering why 4.1.2, Ensure that
>product
> >>>documentation is available in at least one accessible, open standard
> >>>electronic
> >>>format (e.g., HTML, XML, ASCII)., was not a priority 1?   Just seems
>a bit
> >>>strange that so much effort is going into improving the UA, yet  "at
>least
> >>>one"
> >>>accessible form of the documentation is only a "should" (priority 2
> >>>definition).
> >>>
> >>>mark
--
hands-on Technolog(eye)s
Touching The Internet
ftp://ftp.clark.net/pub/poehlman
http://poehlman.clark.net
mailto:poehlman@clark.net
voice 301-949-7599
Dynamic Solutions Inc.
Best of Service for your small business network needs
http://www.dnsolutions.com

Received on Wednesday, 24 February 1999 15:56:55 UTC