- From: Ian Jacobs <ij@w3.org>
- Date: Thu, 13 Jul 2000 16:08:42 -0400
- To: w3c-wai-ua@w3.org
13 July 2000 UA Guidelines Teleconference
Present:
Jon Gunderson (Chair)
Ian Jacobs (Scribe)
Harvey Bingham
David Poehlman
Kitch Barnicle
Mickey Quenzer
Tim Lacy
Dick Brown
Gregory Rosmaita
Eric Hansen
Charles McCathieNevile
Rich Schwerdtfeger
Regrets:
Mark Novak
Jim Allan
Next meeting: 20 July.
Regrets for August: Jim Allan
Agenda [1]
[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0038.html
Discussion
0. IJ: I talked with MAC IE developer Tantek Çelik about the UA
Guidelines. I will send comments about this discussion and
issues raised to the list.
1. Please comment on 7 July 2000 Working Draft.
http://www.w3.org/WAI/UA/WD-UAAG10-20000707
a) HB: Has there been any effort to harmonize definitions
across guidelines?
IJ: Yes.
GR: I recommend taking this to EO.
GR: I reviewed the draft and am still concerned about speech
characteristics being a P2. We may be missing the needs of
some people.
/* Discussion of increments for 4.11 */
Resolved: Change 4.11 to 5% increments.
b) Definitions
EH: To help break logjam in defining some of these issues,
I think we should define "primary content" to be content intended
to be used by people without any disability. Until conventions
are established for indicating that content is primary or
alternative,
that certain assumptions should be made. For example, if you have
content in the "alt" attribute, we assume that that's
alternative. Same for "longdesc".
CMN: I have a long and complex argument against this proposal.
GR: I have a simple one: primary content is in the mind of the
beholder.
/* The Chair moves this discussion to the mailing list. */
/* EH leaves */
2.Proposed changes to audio volume control checkpoints
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0004.html
Resolved: proposal accepted.
Action IJ: Implement this proposal.
3.Minimum list of single command functionalities for checkpoint 10.5
JRG:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0037.html
KB:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0433.html
HB: I don't like all the implications of the list.
Who hesitates to create an explicit list of functionalities:
CMN, KB, IJ, DB, HB, GR.
DP: I like the list, but it shouldn't be the *only* list.
HB: Some of the proposed functionalities have limited domain
(e.g., font size).
KB: When I was first trying to come up with this list, I
wondered whether "search" was critical, since you need to
do this by entering text.
JG: Note clearly that this is single-key (in the case of a
keyboard).
Not modifiers.
Resolved: Unless someone sends a new proposal that we accept,
then this list is ok.
5.Minimum requirement for checkpoint 7.5 on searching:
case-sensitive forward.
IJ: I think that forward is P1. Anything else is convenient.
GR: You search from an arbitrary point, you don't know where you
are.
HB: When you find content, you need to figure out your context.
IJ: We assume that you need to be able to search from the
beginning. You need to be able to continue from where you are.
Resolved:
- You need to be able to start a forward search from a location
in content selected or focused by the user.
[The default starting point is the beginning of content.]
- When a match occurs, you need to be able to
continue searching forward from that location in content.
- Case-insensitive search option (when applicable to
the text language).
- Include in techniques context information (e.g., 3rd match,
bottom of document reached).
GR: Is search necessarily on a per-viewport basis?
IJ: Both functionalities are useful: search on a set of
documents, search on this document only.
GR: What about framesets?
JG: I think that it would be useful to be able to search
on all frames in a frameset, but that we shouldn't
be that specific in the guidelines.
Action IJ: Add search options to techniques document about
searching on framesets.
6.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
IJ: I retract the proposal. I don't want to say "in content". I
think
that style and the DOM in tandem would allow people to know.
IJ: Also, I think that "notification" is the wrong idea.
I think identification is necessary. Prompts are not.
DP: I agree, I don't think that the user should be interrupted.
/* Rich joins */
Action IJ: Repropose checkpoint 2.7.
7.Minimum requirement for Checkpoints 6.1: 6.1 Implement the
accessibility features of all supported specifications (markup
languages,
style sheet languages,
metadata languages, graphics formats, etc.). [Priority 1]
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0448.html
IJ: In short - implement the features related to the requirements
of the WAI guidelines.
CMN: Re circularity; I have concerns about how far "applicability"
goes.
/* IJ notes that IETF drafts have "security issues" sections,
which allows people to know what security issues are raised by
a spec. We don't have the same thing for accessibility. */
IJ: Basically, I want people to:
- Look at specs for identified accessibility features.
- Look at WAI guidelines to find out accessibility
requirements.
- Look at system level accessibility requirements.
- That's all you're required to do.
CMN: The process I have in mind is this:
- You're building a VRML browser. You go to the VRML spec
and implement what it requires.
- Then you go to WCAG 1.0 and see what features in VRML let
you do this.
- I'm not so sure about system-level requirements.
GR: Those are required by ATAG and UAAG.
(You don't need to do anything in addition to meeting ATAG
and UAAG.)
Resolved:
The set of things to implement is :
- Those things labeled in the spec as such.
- Those things in the specification which support
WAI Guidelines requirements.
8.Minimum requirement for Checkpoints 8.1: 8.1 Make available to the
user the author-specified purpose of each table and the
relationships among the table cells and headers. [Priority 1]
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0448.html
IJ: Do we need to say more than "support what the spec says"?
In my discussion with Tantek yesterday, we talked about UA
requirements
to conform to specification but also to *not conform* by
performing repair functionalities. I'll raise this issue on the
list.
/* DB leaves */
IJ: I am proposing to leave the checkpoint as is and adding
as a note that information that relies on spatial relationships
in a two-d environment must translate those relationships
if rendering serially. And leave this as a note as well:
"For graphical user agents, it is sufficient
to render a table as a two-dimensional grid with header
information, and to make available all content per checkpoint
2.1."
GR: This assumes that you can view header and cell information
together on the same screen (size of table, screen magnification,
etc.)
KB: I have concerns similar to GR. The spatial is only
meaningful if you can get at the information needed.
IJ: There may be some rendering situations when you simply
can't render cells and header cells at the same time.
HB: You could enable scrolling.
HB: A concern that I have: most markup used today does not
use the features available in HTML.
JG: I think we may need a query interface.
/* We don't have any other query requirements, only "make
available" */
IJ:
- I think we might want to point out danger cases instead
of establishing minimal requirements, and possible techniques:
a) MQ: For large tables, or large text, need to ensure
that relationships are available, e.g., through a query
interface. Refer to structured navigation, which could
be used in conjunction with a query mechanism.
b) For many cases, fixed headers and footers will suffice
(i.e., rendering alone will suffice). Heads up on serial
rendering.
Resolved: In 8.1, change "relationships" to
"author-specified relationships". No change to
make a minimal requirement.
Action IJ: Make rendering v. query clearer in the note after
the checkpoint.
Action HB: Propose a finite set of information about tables
calculated by the user agent based on author-specified
markup that might be incorporated as a minimal requirement for
checkpoint 8.1.
9.Minimum requirement for Checkpoints 8.2 and 8.3: Distinguishing
link checkpoints.
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0448.html
12.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
13.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
IJ: I propose for 8.2, 8.3, 4.13, and 4.14 one mechanism beyond
color. Note that this is for the UA's user interface, the
information must also be available through an API.
GR: I would also add - don't rely on font characteristics alone as
well.
IJ: If you your solution uses fonts, you need to make sure that
the user can control font family and font size.
Action IJ: Propose change for these four checkpoints that basically
says:
- At least one mechanism other than color.
- Any mechanism used must meet the accessibility requirements
of this document (e.g., related to color selection, font
size or family selection, etc.).
Open Action Items
1.IJ: Draft a preliminary executive summary/mini-FAQ for developers.
(No deadline.)
Completed Action Items
2.JG: Check on availability of telephone bridge for starting telecon
one half hour earlier.
Results: We will have two-hour teleconferences starting today.
3.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.
Refer to IJ's proposal:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0022.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, 13 July 2000 16:08:46 UTC