Re: Comments on 8 December AUGL

Phill's comments on Ian's issues and Charles' responses:

Issue 1) Section 1.3 converge "Conformance" sections with UA
PJ: agree


Issue 2) Editorial change to checkpoint 2.2: change "inform" to "alert".
PJ: agree


Issue 3) Ckpt 3.3 add "prepackaged" and s to descriptions
PJ: partly agree.  I think we still need the word "automatically", but I
agree with Ian that "place-holder" is not well defined. So, I prefer Ian's
re-wording with "automatically" added back in as such:

Checkpoint 3.4 Do not automatically generate equivalent alternatives. Do
not reuse previously authored alternatives without author confirmation.
Note: For example, prompt the user for a text equivalent of an image. If
the author has already provided a text equivalent for the same image used
in another document, offer to reuse that equivalent and prompt the author
for confirmation. Refer also to checkpoints 3.3 and 3.5.


Issue 5) Reword checkpoint 3.5 on multimedia
PJ: I agree with Ian's re-wording.  I like the use of the term "reuse", the
shorter result of the checkpoint text, and the addition of the various
sources of alternative equivalents in the Note.


Issue 6) delete "that is stylistic" from Checkpoint 4.5
PJ: Either way, we need to define the terms "presentation markup" and
"structural markup" and give examples of such markup [we don't currently in
either the glossary nor the techniques].


Issue 7) Checkpoint 5.1
PJ: the three terms are all the same to me, functions, features, or
functionalities. But adding "user interface" is limiting.  I read the
current wording to be more than just the natural integration into the user
interface of the tool, but also into the way the tool works inside, or the
plumbing (non UI) components of the tool.


Issue 8) Guideline 7 rationale question:
PJ: The opening paragraphs may need some work, because MSAA, for example,
was invented to provide access to custom components that did not use the
windows "standard components".  Windows screen readers had to change to
support MSAA as a way to support custom components.  So there is no such
thing as "standard access mechanism" for custom components unless we
consider MSAA as a "standard access mechanism" for the windows platform.

IJ>What are "standard access mechanisms?" How do they apply to custom
  >controls?

>CMN: Standard access mechanisms are the ways in which access to UI
controls
>is done normally. When creating a custom interface component it is
possible
>either to give them the same access methods, or to rewrite special access
>methods for them which may result in assistive technologies not being able
to
>make use of the "standard mechanisms".

PJ proposal: The authoring tool is a software program with user interface
elements and as such must be designed according to relevant accessibility
guidelines. Standard platform components are generally accessible, but when
custom components are created,  it is essential that they follow the
relevant accessibility guidelines.


Issue 9) The note after checkpoint 7.2 should be deleted.
PJ: leave the note so it also show's up in the checklist.



Regards,
Phill Jenkins,

Received on Monday, 13 December 1999 18:16:39 UTC