- From: Ian Jacobs <ij@w3.org>
- Date: Thu, 14 Sep 2000 16:01:00 -0400
- To: w3c-wai-ua@w3.org
14 September 2000 UA Guidelines Teleconference
Present:
Jon Gunderson (Chair)
Ian Jacobs (Scribe)
Eric Hansen
Tim Lacy
Kitch Barnicle
David Poehlman
Charles McCathieNevile
Mickey Quenzer
Jim Allan
Harvey Bingham
Absent:
Rich Schwerdtfeger
Gregory Rosmaita
Next meeting: 19 September
Minutes of previous meeting 12 September:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0378.html
Regrets: Charles
Agenda:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0382.html
Review Action Items
Announcements
1.Extra telecon on 19 September 1:30-2:30 EST USA
http://www.w3.org/WAI/UA/2000/09/wai-ua-telecon-20000919.html
Discussion
1.Issue 257: 4.17 Allow the user to configure the user agent
so that after one viewport is open, no other viewports
open except as the result of explicit user
request. [Priority 2]
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0246.html
/* Ian reviews proposed 4.17 */
CMN: You don't want the viewport to obscure the history. You
want viewports to carry over history. (i.e., don't obscure the
history).
IJ: Note that this is not an issue of focus: I can configure my
Linux box (and have it configured thusly) to not switch focus
when new windows open.
CMN: Often, in full-screen mode, a viewport replaces another
and doesn't carry forward the history. You can't go back.
And this confuses the user even more.
TL: I agree with the proposal, as long as it's configurable
by the user.
JG: True, if a new window opens and is not on top, and there's no
room for it, it would appear "minimized". How would you know that
something happened?
IJ: Yes, notification is missing. (Just like last week's
discussion).
TL: You could call the task switcher. In Windows, you can raise
a dialog that something has happened.
JG: Make both same priority?
IJ: Note that a dialog box is not a viewport.
JG: For partially obscured graphical viewports.
IJ: I propose adding a requirement for notification to the
second proposed checkpoint.
JA: Need to ensure cross references with checkpoint on
focus shifts.
IJ: Another wording: Configuration so that the graphical
viewport with focus is "on top" (i.e., nothing is in front
of it). Notify the user when the configuration is in place.
Resolved:
a) Accept proposal with following changes:
i) Reword second checkpoint to avoid "obscure"
(e.g., "Configuration so that the graphical
viewport with focus is "on top" (i.e., nothing is in front
of it). Notify the user when the configuration is in place.")
ii) Add notification to second checkpoint.
3.Issue 313: On Prompt/Notify/Advise/Alert
http://server.rehab.uiuc.edu/ua-issues/issues-linear.html#313
Refer to issue
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0309.html
IJ: Does prompt mean for user interaction?
Does notify not mean that?
Resolved:
a) Alert means no user response required.
b) Prompt means user response required.
c) s/advise|notify/alert
d) Leave 1.5 as is.
e) Add definitions of alert and prompt.
CMN: There's a definition of prompt in the ATAG
errata.
http://www.w3.org/WAI/AU/ATAG-ERRATA
2.Issue 312: Checkpoint 7.5: Serial renderings and search
requirements
http://server.rehab.uiuc.edu/ua-issues/issues-linear.html#312
EH: Refer to my proposed wording:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0303.html
IJ: Refer to clarification
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0304.html
MQ: What about notification when you don't find something?
Resolved:
a) Adopt proposal:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0304.html
b) Add requirement to move point of regard.
c) Add notification when search not found.
d) Add a technique to provide orientation by stating the number of
occurrences.
e) Add a technique to allow the user to easily search
from the top, backwards search, etc.
5.Issue 315: Definition of terms text and non-text in
checkpoints 7.5, 2.5, 2.6, 1.5, 3.8
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0314.html
/* IJ summarizes EH proposal */
IJ: Text means sequence of characters from doc char set. Text is
the base term. EH wants to build on top of "text" with "text element"
or "non-text element".
EH: There may be better terms than "text element" because "text
element"
may have another meaning in another context. What I want "text
element"
to mean (w.r.t. WCAG 1.0) is: "pre-rendering content that is
understandable
when rendered as synthesized speech, visually displayed text,
Braille."
Key to this is that the rendering is understandable to a qualified
individual (e.g., used to using synthesized speech).
EH: A text equivalent is a text equivalent that has a recognized
equivalence relationship to another piece of content, when rendered
in
those three fashions, fufills its essential function for those
disability groups.
EH: Note that a text element is not defined just as being text.
Consider ascii art, scripts, etc. that require text equivalents.
EH: In principle, a text element could be built from any
format. However, ordinarily, a text equivalent should be build
from text. It can have markup, style, etc. But the style must
be "disposable"; the element can't depend on the style to
deliver its essential message.
JG: What does the WG need to decide?
EH: When we refer to non-text content, that we say that this
is one or more non-text elements per WCAG 1.0. I don't think
we should use the term "text content".
IJ: We use non-text content, but not text content.
IJ: Why is it called "text element" if one criterion
is not that it be composed of characters pre-rendering?
EH: I don't contest that. But we inherit the term from WCAG 1.0.
IJ: So our problem is that:
a) We have a term from WCAG 1.0
b) We have the term "text" which implies characters to people.
EH: I'm just trying to stay the course in a direction set
by WCAG 1.0.
IJ: What about binary formats? The UA may recognize them
and be able to handle them, but the information may not be
composed of characters from the document character set.
IJ: Important: The product is human language! I think that
this is key: the information is converted into a human
language description. We are not talking about conveying
an image of a boat as sound.
EH: But what about a data chart that has three points.
Is the list of coordinates a text equivalent? I would argue
that it may not be complete: you probably need a summary
of what the coordinates turn into. When talking about text
equivalents, we have normally emphasized the digest aspect.
I've been wondering out loud : to what extent can we allow
more complete descriptions of non-text equivalents as part
of their text equivalent? We don't want to set a standard that
text equivalent cannot include a full description.
IJ: I don't think that a list of coordinates would be a text
equivalent for a picture since users of the picture do not
view the coordinates themselves.
EH: Right, a set of pixel coordinates does not suffice. But
I don't want to rule it out. For example, consider the table
summary. I think that the summary is the digest portion of
a text equivalent.
EH: In short, I don't want us, in our definitions, to not
paint ourselves into a corner.
Q: Should 1.5 be expanded to other information in the
user interface?
EH: Are there distinct classes of messages?
EH: I retract (since it may be covered by another issue)
the proposed changes to 1.5).
Resolved changes based on EH's proposal:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0314.html
1) Adopt a definition of non-text content, text element, non-text
element.
2) Add a definition of text. Explain relationship to WCAG 1.0
3) Examine 2.5, 2.6, and 3.8 (editorial)
4) Editorial review of usage of the term "text" based on the
above.
5) [If glyph is used, define it.]
Open Action Items
1.GR: Proposed repair checkpoints
Completed Action Items
1.JG: Add issue related to user agent generated
content being a part of the DOM
http://server.rehab.uiuc.edu/ua-issues/issues-linear.html
--
Ian Jacobs (jacobs@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 831 457-2842
Cell: +1 917 450-8783
Received on Thursday, 14 September 2000 16:01:02 UTC