When composing a definition for something
which you are gathering spec, it is necessary that the
deffinition fit the spec. For instance, if you are going to
call AT a user agent, the AT must meet the spec or the spec
must be written such that it takes the AT unto account. I would
think that this would be problematic in instances say where you
try to use firefox with the mac os and while the AT for the Mac
with Safari might meet the spec, It would not meet the

<AllanJ> user agent
definition: A user agent is any software that retrieves and
presents Web content for end users. Examples include Web
browsers, media players, plug-ins, and other programs including
assistive technologies, that help in retrieving, rendering and
interacting with Web content.

JA: Could we remove AT from the
definition?
... Does it hurt?

<AllanJ> SH: the first line
is clear. the second line seems to contradict. AT does not do
that.

<AllanJ> A user agent is any
software that retrieves and presents Web content for end users.
Examples include Web browsers, media players, plug-ins, and
other programs that facilitate the retrieving, rendering and
interacting with Web content.

<AllanJ> JS: remove the
second sentence

<AllanJ> A user agent is any
software that retrieves, renders and facilitates interaction
with Web content for end users. Examples include Web browsers,
media players, plug-ins, extensions, and

<AllanJ> ATAG and WCAG
reference the original UAAG def ... A user agent is any
software that retrieves and presents Web content for end users.
Examples include Web browsers, media players, plug-ins, and
other programs including assistive technologies, that help in
retrieving, rendering and interacting with Web content.

JA: To ask DP for
clarification
... Place on Survey and Use in Editors Draft - to see
responses.

<trackbot> Created ACTION-113
- Fix the numbering in Section 4.9 and add an editor's note
saying that it came from section 3.3. Put a note in 3.3 saying
it was moved to 4.9. [on Jeanne Spellman - due 2009-01-22].

<jeanne2> scribe: jeanne

<AllanJ> 3.3.7 should be in
perceivable

<jeanne2> slow is
operable.

<jeanne2> if it requires a
mechanism, then it should be under operable.

<jeanne2> I think the
individual global preferences are better kept in the context
(e.g. keyboard) for better understanding. It may be useful to
have a list of all the global options in one location, but not
in the Guidelines.

JA: 3.3.1 Background Image
Toggle: Thoughts

SH: Operable

JA: Agrees

<jeanne2> JS: Operable

JS: Agrees

MH: Agrees

RESOLUTION: 3.3.1 -
stays as operable

JA: 3.3.F Paused Time-Based Media
- how different from 3.3.9

MH: being able to explore the
media on the screen (once paused) will enable rich content
interaction

JA: Need a list separate and
apart from while it's streaming by.

MH: All there in the DOM.

JA: Is this teased out in the
document - maybe hinders accessibility with all the voicing of
the descriptions going by

MH: Maybe the timeline needs
elaboration? For instance with the DAISY plug in to Firevox you
can navigate via the timeline of the voicing or the structure
of the document.

JA: Do we need to come up with a
whole new set of guidelines for this navigation?