Re: comments on working draft

Hi Madeleine,

Thank you for the comments! Your analysis is great (and even touches
on points we've already resolved since that draft).
I'll only respond to non-editorial ones 
(and take into account the others on my own).

> MR: General comments: I support the suggestion that we arrange the
> guidelines in roughly order of importance. I would vote to place
> 11 and 12 (W3C technologies and OS conventions) nearer the top
> and 6 (document styles), 9 (orientation) and 10 (notify of changes)
> toward the end, for example. But 1 and 2 probably belong in sequence,
> despite any difference in importance, and there may be other logical
> orders that should be preserved.

Guideline order was on the agenda for yesterday, but we didn't get to
it.
We'll take your comments into account when we discuss it.

[This is something we wanted to do for WCAG as well but opted not
to at the end.]
 
> MR: In section 1.1 on principles of accessible design it says that
> the guidelines fall into 4 categories (access to interface, access
> to content, orientation, and system standards) but those categories
> are not tied to specific guidelines. Would it make sense to do that?

We  have that in WCAG 1.0 and had it for these guidelines as well.
It can be reinstituted.

> (bullet) A link to a section of the Techniques Document
> ([UA-TECHNIQUES]) where implementations and examples of the
> checkpoint are discussed. 
> 
> MR: Actually, it's a link to an index that then refers you to
> the section where the implementations and examples are discussed.
> I had trouble figuring this out. I kept thinking that these
> techniques hadn't been written yet, not realizing I had to follow
> a second link to the "refer to" section. I see now how this was
> done, and that it is also what was done for WCAG, but I think
> it could be clearer.

Ok.
 
> MR: Was the index built to support cases where a checkpoint is related
> to more than one part of the techniques?

Yes. The checkpoint map will regroup all the techniques related
to a given checkpoint and all checkpoints related to a given technique.

> Currently only 4 of the
> checkpoints have more than one reference, making this link to the
> index an annoyance rather than a help in most cases. (Though
> I understand that may change as the techniques document matures.)
> Or is the index needed so that the Guidelines doc can be stable
> while the techniques doc changes? 

Yes, that is another purpose. (Good analysis!!!!)

> In that case, let's just 
> clarify the language. Perhaps in the Techniques index we could
> change the words "Refer to" to "Techniques are in section." And in
> the bulleted item in the Guidelines document, should we mention
> this index?

Essentially, you follow the "Techniques for X" link and
land in the checkpoint map. From there, you can find various
pertinent techniques.

 
> Guideline 1 rationale on input and output device independence
> 
> MR: My understanding is that most alternative input devices use
> either the keyboard or the mouse input channels to communicate
> with the operating system.

Yes, we discussed this at a the 14 July teleconference [1]: device
independence in effect relates to standard APIs for mouse/keyboard.

[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0018.html

> I suggest adding a sentence that says
> something like this and urges UAs to use only the OS standard ways
> of reading the input channels. This might clarify the statement
> that UAs need not support every input device since they will most
> likely do so transparently by appropriately supporting the standard
> devices. This might sound like a technique, but I think it is
> important to include this info for developers who might be surprised
> by the long list of alternate input devices. (This is closely
> related to the Guideline 2 rationale, but since most readers will
> read GL 1 first, can we clarify here?)

Good call. We decided that at the 14 July teleconf [1]. Wording will
be along the lines of :

      1.1 Ensure that all functionalities offered through the
          user interface may be operated through standard input 
          device APIs supported by the operating system. [Priority 1] 
 
> MR: Could add a sentence after the example of input about output
> device independence such as:
> "And any output provided in audio should also be available in
> text since most alternative output mechanisms rely on the presence
> of system-drawn text on the screen."

We should discuss this at a teleconference.


> Checkpoint 2.6 Indicate the keyboard access method to activate a
> user agent function using platform conventions. [Priority 2] 
> 
> JRG: Does checkpoint 2.6 currently only refer to how to activate an
> author supplied ACCESSKEY binding to a link or a control? If it is
> only related to ACCESSKEY, then maybe it should be stated for
> ACCESSKEY in the checkpoint.  Otherwise I am not sure how it is
> different from checkpoints 2.2 and 2.3

Checkpoint 2.6 refers to how the information is rendered to the user
(e.g., underlined in a menu). 
 
> MR: I understood this to refer to UA interface functionality,
> like menus and dialog boxes, and to mean "Underline the quick
> access letter on Windows, and do whatever the current platform
> usually does in other platforms." Perhaps an example note would
> clarify, or the technique will once it is written.

Yes, exactly.
 
> Checkpoint 3.1 Ensure that all product documentation conforms to the
> Web Content Accessibility Guidelines. [Priority 1] 
> 
> MR: Should this say "all electronic product documentation"? The 
> technique goes as far as "Documentation created in HTML" but
> the checkpoint wording seems to include paper as well, which the
> WCAG won't have much help for ... The WCAG has basic principles which
> apply to non-HTML docs, so maybe techniques should say "Use WCAG for
> docs in HTML, and observe the same principles as well as relevant
> interface checkpoints in this document when using other technologies."

We could say "electronic". We should address this in a teleconf.
 
[skip]
> MR: I propose adding a new checkpoint (between current 5.5 and 5.6)
> "Allow the user to turn on and off rendering of audio descriptions.
> [Priority 1]"

That sounds like a good idea!
 
> Checkpoint 6.8 Allow the user to control video frame rates. [Priority 1]
> 
> MR: Apologies if I missed discussion on this (can't find any in this
> year's mailing list archives). Why do users want to control video
> frame rates? If what is meant is that users want to speed up and slow
> down video to improve comprehension or save time, say that. Changing
> frame rate changes the quality of video but may not effect how fast
> content goes by. The only access issue I'm aware of for frame rates is
> that sign language requires high frame rates to be comprehensible, but
> that is an authoring issue and a bandwidth issue, I think.

Perhaps you should join a call and explain this. I believe
there was an issue with cognitive disabilities and the need to
slow down for comprehension. Or, in a video presentation with
links, for example, to be able to change the rate of presentation
so that someone with motor difficulties could interact with the
presentation at a rate of his or her choosing.
 
> Checkpoint 7.6: If a technology allows for more than one caption or
> description track for audio, allow the user to choose from among tracks.
> and
> Checkpoint 7.7 Allow the user to specify that captions for audio be
> rendered at the same time as the audio. 
> 
> MR: Remove "or description" from 7.6. Audio tracks do not get
> description tracks. Also, I suggest swapping the order of 7.7 and 7.6,
> since rendering at the same time is the most basic thing to be done,
> and switching tracks is an add-on. (I do think it is priority 1, just
> slightly below getting the synchronization right.)

Ok.
 
> Checkpoint 7.8 If a technology allows for more than one caption or
> description track (e.g., text, video of sign language, etc.) for
> video, allow the user to choose from among tracks.
> and
> Checkpoint 7.9 If a technology allows for more than one audio track
> for video, allow the user to choose from among tracks.
> 
> MR: I'm not clear on the difference between these two. If the intent
> was to separate captioning checkpoints from description checkpoints,

Yes, that was the intent.

> remove "or description" from 7.8 and perhaps add "or video"
> to cover the idea of ASL tracks. Then clarify that the audio tracks
> referred to in 7.9 may be description.

Ok.
 
> MR: Or is 7.9 meant to refer to alternate languages, or some other
> kind of non-description alternate audio like director's comments?
> If so, is that an access issue? (That is, if the UA supports changing
> languages or hearing the director's comments, that feature must be
> accessible, but that should be covered by the checkpoints on interface
> accessibility.)

I don't think that was the intent.
 
> Checkpoint 7.10 Allow the user to specify that text descriptions of
> video be rendered at the same time as the video. [Priority 1] 
> and
> Checkpoint 7.11 Allow the user to specify that auditory descriptions
> of video be rendered at the same time as the video.
> 
> MR: Could 7.10 and 7.11 be combined with "and" or "or" ("text and 
> auditory descriptions")? Also, as mentioned for 7.6 and 7.7, I
> suggest reordering so that the checkpoints on rendering at the
> same time (7.10 and 7.11) come before the ones on extra tracks
> (7.8 and 7.9).

In the past, to make it easier for developers to check off
checkpoints, we've separated functionality (hence the large
number of checkpoints instead of one with a large number
of techniques or examples). I think that's the only reason
these two are separate.
 
> Checkpoint 12.4 For desktop graphical browsers. Comply with W3C
> Document Object Model specifications and export interfaces defined
> by those specifications.
> 
> MR: Should this be part of Guideline 11 on W3C technologies rather
> than in this section on operating system conventions? Or is it here
> because we are asking that UAs export the DOM into an operating
> system standard interface? If so that could be clearer.

Yes, that's why. Will clarify.
 
> Techniques document

Great! We need review/contributions to the Techniques.

> 2.1 Examples and Deprecated Examples
> This document contains a number of examples that illustrate accessible
> solutions in HTML, CSS, etc. but also deprecated examples that
> illustrate what content developers should not do.
> 
> MR: Left over from WCAG? There aren't currently any deprecated
> examples in the techniques, though I know it isn't done yet. At
> any rate, they won't be illustrations for content developers.

You're right, this has to be edited. However, there may be
some deprecated examples (e.g., that make use of deprecated
elements or attributes).
 

> 4.4 The document object model
> MR: The current technique text talks more about what DOM can't do than
> about what it can do. Would be helpful to have concrete examples of
> useful DOM features. Unfortunately I don't know enough about DOM to
> suggest them myself. The text about what DOM can't do could possibly
> say, "The DOM can't do some things, therefore see the techniques in
> the sections on user interface to ensure style and scripting
> controls are accessible" rather than insert info on accessible 
> controls in this section.

Ok, we'll try to liven this section up.
 
> Section 7 SMIL accessibility
> MR: I can work on techniques for multimedia accessibility sections.

I would *love* contributions. Can you coordinate with Marja
Koivunen on this?

> One question is, can the UA techniques document be more forward looking
> than current W3C recommendations? 

Yes, it can. A heads-up is a good thing. However
if developers are looking for practical information today, we
can't tell them too much about what's headed their way (they may
be frustrated to not have it yet). 

> The SMIL access note being written by EO
> refers only to SMIL 1.0, but SMIL 2.0 is in development and may include
> additional features. Can we use the UA recommendations to encourage
> player developers to advance the state of the art?

Yes we can, with the caveat that Working Drafts are still Working
Drafts.
 
> MR: If section 7 will primarily point to the SMIL access document,
> which sections would be best for specific techniques? 3.3, User
> Control of Style? 3.3.1 Feature Control?

Use section 7 for SMIL-specific info (e.g., attributes) and the
other sections for more abstract information (e.g., about
synchronization
or user interface).
 
> MR: Also, should we discuss techniques for other streaming media types
> (AVI, QuickTime)? NCAM has lots of info on this stuff so if you give me
> some pointers on how you'd like it structured I can pull something
> together for the group to look at.

I'll bet you can suggest a better structure than I can. I'll
have to think about this.
 
Wow! Thanks for the great comments. I wanted to get quick answers
back to you, so I apologize if some of my comments are incomplete. 
Please don't hesitate to follow up.

 - Ian

-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel/Fax:                     +1 212 684-1814

Received on Thursday, 5 August 1999 19:07:20 UTC