IJ: Poste message to begin discussiion of fotification of scripting events.
Two main issues to be discussed: 1) What requirements on browser for
notification of changes to AT? 2) What required of AT to make these changes
known?

IJ: Even if flicker is covered by scripts, should be indicated explicitly.

DA: Risky to say "get rid of flicker" without killing all scripts
and applets.

RESOLVED: Since caused by scripts/applets, support for turning
off/pausing/controlling covers this.

RESOLVED: Add to spec information specific to flicker and epilepsy.

b) RESOLVED: ADD checkpoint for "Use w3c specs" (Priority 2)

RESOLVED: No checkpoint for support of deprecated features

c) CMN: Why support lang? Contracting mechanisms in different languages
differ. Contractions come out wrong if not marked up.

DA: I think should be priority 1 since otherwise gibberish.

CMN: Not sure of this.

GG: Jaws supports multiple languages.

Proposed: 1) Desktops expose 2) ATs indicate change in language.

Rich: Not all AT developers have resources to support multiple languages.
If language supported, just deal with it, otherwise announce the change.
(Techniques)

GG: I'm conflicted in importance. It's an item worth addressing. How often
does it come up? How difficult is it to adapt? Can turn of Grade II braille if
necessary. Grade II in American-English added to Jaws in recent months.

(Allow the user specify that audio descriptions of video be rendered at the
same time as the video.)

5.2.8 [Priority 1] Allow the user to specify that captions or descriptions
for video be rendered at the same time as the video.

5.2.9 [Priority 2] Allow the user to specify that audio descriptions of
video be rendered at the same time as the video.

Resolution proposal: Merge 5.2.8 and 5.2.9 in 31 march draft

CMN: Case for merging them: for time-dependent equivalent content,
synchronize with the video presentation. Lots of cases are priority one. But
some cases fall away if you assume a single user. If you assume several people
at the same presentation, lots more requirements.

DA: Synchronization important for someone with a learning disability.

JA: With SMIL 2, synchronization of multiple description tracks will be
easier.

6.3.2 [Priority 2] Alert the user when scripts or applets are executed.

6.3.3 [Priority 3] Provide information about document changes resulting
from the execution of a script.

Resolution proposal: Include checkpoint related to notification of document
changes

CMN:

a) Base Notification (the document changed)

b) Better Notification (where change occurred)

GG: In some cases, you have hidden fields where data is changing for form
designer. This could be sent across as document changes...

GG: Caret changes less important, since can be detected. We find dynamic
changes hard to track, notably if we move to the realm of caching data. Useful
to know when the cache should be reconstructed.

IJ: Inform of changes to rendered content.

IJ: Read/Write/Change notification

JG: Need to tell AT of changes, but ATs also need to tell users about
changes.

RS: I have concerns about annoying announcements.

CMN: I don't think we want to go into implementation issues.

GG: If I know that the user has pressed the key, and then I get information
that the document changes, I could ignore the change since the user made the
change through the AT's functionality.

MK: Does this mean that there is not notification at all when it's
user-initiated?

CMN: Notification also varies in its severity.

RS: Maybe we should require that the AT maintain the state of the document.
Allow the user to configure the AT to specify the level of information
presented.

RS: Analogy: If two people were working on a remote document and changes
reflected on both clients, you may or may not want to know about all changes.

DA: What about mouse position changes?

ACTION Ian: Move this to the list:

a) What requirements on browser for notification of changes to AT?

b) What required of AT to make these changes known to the user?

6) PROPOSED additional functionaility: Do you want to provide some audio
feedback as to audio length, either before it plays, or when paused, etc. ?
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JanMar/0230.html

Resolution proposal: Next document there will be better information on
summary document. Do we need a checkpoint or more desciption in a technique
about summary information?

JA: Seems like an authoring thing: "This is a 15 Mbyte file."

IJ: But you could adjust playback rate and that wouldn't be valid.

Marja: Want relative information: how much viewed.

IJ: How does this information benefit accessibility?

GG: Marginally interesting, but so easy to abort in most cases. Or you can
read progress in the dialog box.

Marja: You may want to advance to the middle of a file.

GG: This is more navigational, though. True, if you can navigate, knowing
the dimensions helps.