- From: Ian Jacobs <ij@w3.org>
- Date: Fri, 21 Jul 2000 17:25:12 -0400
- To: w3c-wai-ua@w3.org
20 July 2000 UA Guidelines Teleconference
Present:
Jon Gunderson (Chair)
Ian Jacobs (Scribe)
Charles McCathieNevile
Harvey Bingham
Mickey Quenzer
Tim Lacy
Kitch Barnicle
Eric Hansen
David Poehlman
Dick Brown
Gregory Rosmaita
Regrets:
Mark Novak
Jim Allan
Next meeting: 27 July.
Regrets for August: Jim Allan
Agenda [1]
[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0074.html
A. Announcements
Additional Telecon scheduled for Monday, 24 July at 2:00 EST USA for
90 minutes
No: CMN, TL, EH, DB
Yes: KB, JG, IJ
B. Discussion
1.Issue 289: Multimedia definitions.
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0517.html
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0520.html
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0503.html
IJ: Mostly about definitions. Also may cause changes to some
checkpoints.
IJ: Related issues:
- Turn on/off
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#290
- Audio as style
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#297
- Definitions themselves (e.g., degenerate multimedia
presentations).
EH: Def of multimedia: at least one audio track and visual track
that are complements; in order to get the full meaning of the
presentation
you need both tracks.
EH: In order to know whether content is accessible, the only thing
that counts is in the end is what is presented to the user. In an
ideal world, we could categorize presentations by their purpose
and associations. We wouldn't care whether the component used to
produce the presentation was a WAV or AVI file. Or text animated by
a style sheet or for that matter it was a caption screen. But today
we don't have the language support for dividing all those
presentations into neat little packages as they appear to the user.
So we drop back a layer and we end up being concerned with the
components used to generate the presentation. When can we talk
about the product independently of the mechanisms used to produce
it, and when do we have to talk about the means used to produce it.
In the Guidelines, because we don't have perfect support for
capturing the end product presentations, we retreat to earlier
layers,
which is why we run into problems with "multimedia". I have in mind
that this means something more than what can be presented by a
movie file. We've agreed that in some cases, animations can be
considered to have a visual track. But when one has a static page
(or even a moving text page) that's automatically or manually
scrolling with background audio, some of us balk at calling that a
visual track.
IJ: Can we eliminate normative references to "multimedia" in the
document? (Refer to checkpoint 4.5; perhaps say "audio and visual
track").
Resolved:
- Try to remove normative references to "multimedia" in the
guidelines.
- Add a definition of "presentation".
EH: In some places, we don't distinguish style and content, in
others we do. We need to elaborate our definition of content.
Action IJ and EH: Work on multimedia-related definitions and
presentations and send to the list.
2.Issue 257: Minimum requirement for Checkpoints 2.7: For
author-identified but unsupported natural languages, allow the
user to configure the user agent to
identify those language changes in content. [Priority 3]
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0448.html
EH: In some cases where you have a plain text text equivalent and
you're supposed to mark up changes in languages.
CMN: I made some comments on the list about my understanding.
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0084.html
KB: You may have a problem with stating "this content may not
disorient the user". We want to say that it could disorient the
user.
IJ: I agree that it could be rewritten so that the rationale is
clearer.
GR: Should the UA identify the unsupported language?
CMN: I think that language information is useful information.
/* Discussion of having visual rendering being tuned to
meet needs of some assistive technologies */
IJ: I don't think that rendering language name in content is the
best solution for giving access to content in an unsupported
language.
JG: We do require access to all content.
Resolved:
- Accept Ian's proposed rewording of checkpoint with edits
to be proposed by Kitch.
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0080.html
3.Issue 257: Minimum requirement for Checkpoints 8.2 and 8.3:
Distinguishing link checkpoints
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0448.html
IJ: The model I'd like to use for these and similar checkpoints:
a) If color is used as a mechanism, at least one
mechanism in addition to color that is distinguishable from
other types of information.
b) Whatever mechanism is used, refer to pertinent checkpoints in
this
document (color, fonts) for rendering requirement.
(We're talking about rendering.)
c) Info has to be available programmatically as well.
EH: Should a text-based option be required? Does this information
require a text equivalent?
JG: This could be an option for user agents (using
pseudo-elements).
JG: How do I know as a user agent that the author has specified
boxes around links?
CMN: The UA does the rendering, so it knows.
Resolved: Adopt three-pronged proposal.
4.13: Allow the user to configure how the selection is
highlighted (e.g., foreground and background color).
4.14: Allow the user to configure how the content focus is
highlighted (e.g., foreground and background color).
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0035.htm
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0036.html
JG: Boxes are easier to find for people with low vision.
Resolved: Adopt same three-pronged proposal. However, focus and
selection must be rendered as distinct.
/* Kitch starts minuting here, Ian goes to the airport */
6.Issue 257: Minimum requirement for checkpoint 4.13: Allow the user
to
configure how the selection is highlighted (e.g., foreground and
background
color).
[Priority 1]
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0036.html
7.Issue 257: Minimum requirement for checkpoint 4.14: Allow the user
to
configure how the content focus is highlighted (e.g., foreground and
background
color). [Priority 1]
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0035.html
JG: Is everyone okay with one style?
EH: What if the whole block of text is underlined and you are relying on
underlined text to show visited links.
JG: Rather see minimum color plus something else. Basically color is
what
is used now. I don't think color is used for focus changes.
Who thinks we should require color in addition to something else? With
Ian's proposal a user agent could just use a box.
Yes: DP, GR, CMN
No: Kitch
GR: Min should include font families and something else.
TL: Shouldn't restrict it to one channel of information. ie, don't rely
on
any ONE means of conveying information. Should be allowed to configure .
IJ: I could live with color plus something else.
JG: What about font plus something else.
IJ: I believe we should in general go with current implementation.
GR: Color plus something is insufficient. If i'm using high
magnification i
might not see box and text at the same time. Offer user a range of font
characteristics.
IJ: that is not the metaphor used today.
GR: with netscape 6 I can choose a font family for serif and sans
serif....
CMN: are you suggesting that instead of using color, select out of the
range of presentation options, fonts, boxes etc.
IJ: I oppose this as being going overboard. It is a good idea but
GR: why should user have less configurability over active elements vs
surrounding content.
IJ: I would agree to color plus something and include a note with
reference
to other checkpoints.
CMN: I don't support "one other mechanism". I support GR's "use full
range
of presentation" The requirement in the other checkpoint is for the text
as
a whole. No particular scope, it would set the font for the whole page.
It
doesn't give you a way of distinguishing headers for example.
Specifically
we are saying provide a mechanism for things to stand out.
IJ: I would suggest the same set of elements suggested by another
checkpoint - those marked important. Here is a specified set of
important
elements.
CMN:
JG: Can people live with something other than color and font family as
the
min. req for those checkpoints and if we develop a list of important
elements that these psuedo elements be included in that.
(visited links, thinks that involve a fee)
YES: CMN,
DB: so you are saying that you'll have to control the font of links,
differently from the rest of the text.
JG: could be done through style sheets. This is a priority 2 checkpoint.
TL: When you get down to controlling all aspects of an object (color,
font,...etc). I'm okay with it, in light of the style sheet comments.
JG: Proposal:
For 8.2 and 8.3 indicate to the user by at least one technique other
than
by distinguishing with color, font family, font size whether a to
indicate
that a link has been visited, involves a fee, selected text and the
element
with focus.
EH: Is there a priority 1 requirement that requires access to this
information auditorily, visually and in braille.
JG: yes through API.
IJ: proposal was to expand list of min techniques. was there a proposal
to
adjust 4.2... to adjust font family. Is there a proposal to control
important elements independently of the rest of the text.
IJ: summary
1. expand font family size and color requirement to be on an element
basis
not just a global setting
2. for check 8.2, 8.3 4.13. 4.14 cross reference those font and color
checkpoint and indicate a) you are required and b) that would be a
solution.
3. for the case of HTML should we list what we consider to be important
elements...we need to do that for 7.6. For the ones we know we can say
these are the important elements.
Resolved: @@No resolution indicated@@
4.Issue 257: Clearer definition of the term "Easy access" in
checkpoint 2.3
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0034.html
Current wording
2.3 If content available in a viewport has equivalent alternatives,
provide
easy access in context to the alternatives. [Priority 1]
IJ: I would rephrase to say provide direct access e.g. through a link or
context menu. That is, it is either there or one more away. It doesn't
have
to be a link to another page. Basically, providing one step access to
alternative equipment. It basically means direct access.
IJ: editorially, it has to be written careful that you have to do A or B
or
C . You have to do 1 of 3.
No objections to modification of Jon's proposal for modification 2.3
RESOLVED.- accept new proposal with modifications
5.Issue 257: Clearer definition of the term "Easy access" in
checkpoint
10.8
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0032.html
New proposal. one step activation for frequently used
DP: one step defined
IJ: We do need to define one step, basically direct access.
JG: list for 10.5 could also be our list of frequently used commands
27.Issue 257: Other minimal requirements part of issue PR#257 (No
proposals)
Checkpoint 10.4: Input configuration
Checkpoint 9.3: Configuration of notification.
JG: allow one, two, or three step operations to be accomplished with one
step ??(changing the font size in IE.)
GR: want to bind the font size increment to keystroke
IJ: what if i want to change my language to French. Should I be able to
do
that with one stroke.
IJ: what are the types of multikey sequences that we have? do they
require
a modifier?
JG: most require a modifier
NOTE: one command does not include a modifier but one step can require a
modifier
Still open.
Completed Action Items
3.IJ: Send counter proposal to identify unsupported language
changes
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0080.html
Open Action Items
1.IJ: Draft a preliminary executive summary/mini-FAQ for developers.
(No deadline.)
2.IJ: Add to note on checkpoint 8.1 the important cases that this
checkpoint must provide information through the user interface
4.IJ: Update document with resolutions from 7/13/00 telecon
5.EH: Send comments on definitions of "primary content" to the list
for
consideration by the group
6.GR: Re-examine the orientation checkpoints and see whether they
can
be clarified to account for control of rendering of audio (and possibly
other content) on
load.
7.HB: Review note for checkpoint 8.1
--
Ian Jacobs (jacobs@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 831 457-2842
Cell: +1 917 450-8783
Received on Friday, 21 July 2000 17:25:20 UTC