- From: Jon Gunderson <jongund@staff.uiuc.edu>
- Date: Wed, 22 Sep 1999 14:09:42 -0700
- To: w3c-wai-ua@w3.org
Attendance
Chair: Jon Gunderson
Scribe: Ian Jacobs
Present:
Gregory J. Rosmaita
Madeleine Rothberg
Al Gilman
Mark Novak
Rich Schwerdtfeger
Kitch Barnicle
Charles McCathieNevile
Marja-Riitta Koivunen
Regrets:
Harvey Bingham
Jim Allan
David Poehlman
Action Items
Completed Action Items
1.JG: Ask Denis Anson to review the document
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0370.html
2.JG: Ask Al Gilman to come to the next meeting to talk about spawned
windows
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0371.html
3.IJ: Run NN (and Mozilla) through guidelines.
http://www.w3.org/WAI/UA/uagl-checklist-nn4.60
4.IJ: In document, highlight existence of "native" and "applies to".
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0396.html
5.IJ: Make the dependency on micropayments more visible.
Status: done, next working draft
6.IJ: Include GR's link checkpoint as P3 (configurability). Change
priority of 9.6 to P2. Get techniques out of [1].
Status: done, next working draft
7.IJ: Propose checkpoint wording for access to form control information
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0395.html
8.IJ: Rewording of checkpoint 4.12: Allow the user to turn on and off
rendering of frames
Status: done, next working draft
9.CL: Submit a technique related to text rendering of client-side image
maps
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0383.html
10.HB: Submit a technique related to using for ABBR and ACRONYM elements
for rendering
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0382.html
Continued Action Items
1.JG: Run pwWebSpeak (with Mark H.) through the guidelines.
2.JG: Propose techniques for rendering of frames
3.IJ: Find out about MS review of document before F2F and their
participation in the meeting.
4.DP: Technique 3.6 - Propose techniques
5.DP: Run Jaws for Windows through the guidelines
6.GG: Review proposal for techniques for accessing content.
7.Working Group: Review IJ proposal for changes in conformance for
discussion next week
New Action Items
1.JG: Contact DP about particpation
2.JG: Contact GG about particpation and review of conformance proposal
3.IJ, MRK: Send reference on SMIL note to UA list
4.IJ: Make these editorial changes about continuous equivs for audio
captioning and descriptions
5.IJ: Link to "altifier" from Techniques document.
http://www.vorburger.ch/projects/alt/
Link to ER tools page from techniques.
http://www.w3.org/WAI/ER/existingtools.html
6.GR: Write a proposal to address issues about spawned windows.
7.MR: Working on SMIL techniques in addition to SMIL access note.
8.MR: Coordinate with Geoff Freed so that issue related to aalternatiove
content is sufficiently addressed in PF.
Minutes
Agenda [1]
[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0378.html
1) Review of action items:
1.JG: Run pwWebSpeak (with Mark H.) through the guidelines.
Not done.
2.JG: Ask Denis Anson to review the document
Done, but haven't heard back.
3.JG: Propose techniques for rendering of frames
Not done.
4.JG: Ask Al Gilman to come to the next meeting to talk about spawned
windows
Done, Al will arrive at about 11:30.
5.IJ: Find out about MS review of document before F2F and their
participation in the meeting.
Status: Pending.
6.IJ: Run NN (and Mozilla) through guidelines.
Status: Done.
7.IJ: In document, highlight existence of "native" and "applies to".
Status: Done,
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0396.html
8.IJ: Make the dependency on micropayments more visible.
Status: Done. Added reference to that WD.
9.IJ: Include GR's link checkpoint as P3 (configurability). Change
priority of 9.6 to P2. Get techniques out of [1].
Status: Done. For next draft.
10.IJ: Propose checkpoint wording for access to form control information.
Status: Done.
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0395.html
11.IJ: Rewording of checkpoint 4.12: Allow the user to turn on and off
rendering of frames
Status: Done.
12.CL: Submit a technique related to text rendering of client-side image
maps .
Status: Done.
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0383.html
13.HB: Submit a technique related to using for ABBR and ACRONYM elements
for rendering
Status: Done,
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0382.html
14.DP: Technique 3.6 - Propose techniques
Status: Not done.
15.DP: Run Jaws for Windows through the guidelines.
Status: Not done.
16.GG: Review proposal for techniques for accessing content.
Status: Not done.
17.Working Group: Review IJ proposal for changes in conformance for
discussion next week
Status: Done
2) Conformance.
Ian reviews conformance proposal.
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0365.html
KB: Is it basically all or nothing for communication?
CMN: If you don't work with other software, then you're not interoperable.
RS: Are there degrees of interoperability?
JB: Yes, there are different priorities for those checkpoints.
MN: I think this is the wrong direction since it weakens conformance. I'm
not comfortable with this direction. Why would you offer conformance for
UAs that don't
meet published software accessibility standards. I could say I'm
interoperable and not support some standard API.
IJ: You could not support the mouse and still be interoperable. But if you
support the mouse, you need to do so accessibly.
CMN: My concern: HPR is not an accessible user agent, per se. It's a good
tool for a certain set of user, just like NN is useful for a set of users.
I don't want the
result of this conformance provision to be useful tools that are not
interoperable. I think we would still lose. Analogous to question in AUGL
WG about accessibility
of AU Tools. I think this proposal is a step forward. I want to emphasize
that a stand-alone UA is not sufficient to solve the problem of ensuring an
accessible Web.
KB: I like removing the distinction between desktop and dependent UA. Like
Ian, I'm concerned about removing the complete requirement of
interoperability.
JG: The checkpoints in Guideline 6 (on communication) refer to standards
and conventions (except for DOM) that are not W3C Recommendations.
MN: I don't understand "interoperability". I don't want a tool to be able
to confirm if it doesn't conform to published guidelines for software
accessibility.
JG: I like in this proposal that it is forward-looking for new technologies
(e.g., voice input/output).
AG: This is related to mobile platforms - it makes sense for desktop
computers to have extensibility requirements. But not as much for a mobile
device. It's not so
much that the tool interacts with the Web. But is it running in a context
where extension is a natural requirement.
MK: If you're afraid people won't conform, you can do something at the icon
level.
IJ: But we would still need to agree on the split.
No consensus. Please review and comment on the list. This will be on the
agenda again next week.
3) Issue #90: UA and AU dependency list (KB and JA proposals)
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#90
CMN: Those comments are more about when AU will review UA in last call
rather than vice-versa. But is there something we need to do to the UA
guidelines to
meet requirements of UAGL.
AG: E.g., UAGL wants to do hierarchical navigation. An extremely useful
thing for AU tools to do is to display the hierarchical structure. This
would expose the
author to the concepts of hierarchical blocks. (e.g., in a related power toy).
MR: The second half of Kitch's message goes in that direction.
CMN: Yes. The Authoring Tool GL approach is to refer to other documents
rather than repeating that information. We're not going to include WCAG
techniques,
for example, since implementors must know those guidelines anyway. We've
also tried to be general enough to not refer only to HTML or a particular
image format
or tool. Most popular tools used by professionals are really text editors
without a WYSIWYG interface that give access to the source (e.g.,
DreamWeaver, etc.) In
short, there's a big dependency on the UAGL. But the current approach is
not to include specific checkpoints that match up exactly with checkpoints
in other
guidelines. The AUGL would love more review. But the UAGL review has
already been good.
JG: All my comments were sent to AU archives.
IJ: Kitch, Jon, Jim, Ian have all commented. Perhaps all we need to make
available to AUGL at some point is a statement from the Chair stating that
the AUGL WG
has responded to our comments.
JG: Can UAGL review again during Proposed Recommendation?
CMN: It's not exactly clear what a WG does when it's not happy with the
results of the last call. But the WG will track last call comments and show
resolutions.
AG: And Ian should track those for the UA Group.
Resolved: This issue is considered closed. However, the AUGL last call
continues and comments are still welcome.
(Rich and Mark leave).
4) Issue #78 Review requirements for window spawning
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#78
AG: Generic three levels of control:
a) Lightest: When you spawn, alert the user. No control
b) Middle: If you spawn, you ask the user to confirm.
c) Most severe: Spawning inhibited.
Ian had proposed (a) only in [1]
[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0212.html
AG: People need to be able to follow the evolution. Need to be able to
return to known context with back button. Spawning breaks this since you
can't undo the
window creation. Eyes-free users need to understand the information space.
The difference between Ian's proposal and what I proposed [2] is no more
than P3.
The user should be able to invoke a mode that requires confirmation.
[2] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0214.html
JG: If I were Chuck Oppermann, I would say that this problem is not one of
user agents, but an operating system convention issue. Why is problem unique to
browsers?
AG: When it happens in the context of browsing, this is a violation of the
contract with the user w.r.t. the Web content. Thus, even if implemented in
the operating
system, this is a UA requirement.
GR: I recently proposed a checkpoint for forms. See Ian's rewritten
proposal [3]. Would it be helpful to write something similar for spawned
windows?
[3] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0395.html
MK: What about history list of spawned windows?
AG: You lose old history list thread.
CMN: Håkon Lie proposed importing history into spawned windows. If you do
this, do you respect the contract that Al refers to? My instinct is that
you probably
have.
AG: You've improved usability, in my opinion, without invoking the
additional levels of control.
CMN: With Amaya, if you have a page that hasn't been saved, it opens the
page in a new window. At the end of the day, I have a huge pile of excess
windows. I
throw them all away.
KB: I've seen situations where users end up with two UAs unknowingly, going
to a text editor, then returning and being lost. (Window opened either by
page or UA
new window functionality.)
Action GR: Write a proposal to address issues about spawned windows.
5) Issue #80 Make audio available as text.
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#80
MR: In rationale of Guideline 1, I thought an additional example on output
device independence. Example would meet needs of deaf users and output device
independence. Take text from [3]:
"And any output provided in audio should also be available in text since
most alternative output mechanisms rely on the presence of system-drawn
text on the
screen."
AG: Also add cross-reference to show sounds in techniques document.
Resolved: ok to add text to introduction
[3] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0083.html
6) Issue #81 Turn on/off audio descs.
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#81
MR: Propose adding a one for auditory descriptions.
IJ: Could combine as "auditory description" as we did below.
AG: Might be better to keep separate for clarity.
MR: Propose "alternative equivalent" track in place of "descriptive track".
MK: "Continuous equivalent".
MR: So bring language more in line with SMIL accessibility Note.
Resolved:
a) Generalize 4.5 to continuous equivalents. (list each expected type).
b) Apply this language to related checkpoints.
Action Ian: Make these editorial changes about continuous equivs.
MR: Note that SMIL 1.0 only allows people to turn off captions. Should have
in SMIL 2.0 means to turn off auditory descs.
IJ: I agree that design ideas about the future are good for the techniques.
AG: In PF, we may not be seeing enough of this conversation. The PF charter
requires us to send requirements to the SYMM Group.
CMN: Some of that's in my court.
Action MR: Working on SMIL techniques in addition to SMIL access note.
Action MR: Coordinate with Geoff Freed so that issue related to
aalternatiove content is sufficiently addressed in PF.
7) Issue #82 Rendering image in a link when there's no alt.
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#82
When images are turned off, how do you indicate the link?
AG: The "altifier" tool does this. E.g., for a link to the same place on
the same page, it steals the link text.
Resolved (pending comments from Harvey): Add info to techniques document
about this.
Action Ian: Link to "altifier" from Techniques document.
http://www.vorburger.ch/projects/alt/
Link to ER tools page from techniques.
http://www.w3.org/WAI/ER/existingtools.html
8) Issue #83 Split speech rendering checkpoints since different priorities.
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#83
From Jim Thatcher:
Speech volume/rate are priority 2 or 1, pitch and gender are priority 3
(max), in my opinion.
JG: Proposal to create several checkpoints or just reshuffle elements of
current checkpoints.
MR: I agree with Rate/Volume Priority 1, Pitch/Gender Priority 3.
GR: Sounds reasonable
AG: Let's ask Kitch to investigate the pitch issue. May be P2 for a small
number of people.
JG: Some people with head injuries are sensitive to gender/pitch. It also
is pretty easy to do with todays speech technology.
GR: I'd support P2 for Pitch/Gender
MR: If you're implementing synthetic speech anyway, these aren't much more.
Resolved:
a) Volume is P1
b) Others P2.
9) Issue #84 Checkpoint on natural language applies to all UAs.
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#84
KB, IJ: Should apply to all user agents.
AG: One argument is that supporting it in the visual environment is just
supporting HTML 4.0. The severity of the accessibility issue goes up in the
auditory scenario.
It applies in all cases, however, just in terms of conformance to the HTML
spec.
KB: Is there some reason a mainstream UA would not want to do this?
IJ: I delete email that arrives in the wrong character encoding.
CMN: I don't, I go to a different tool.
Resolved: Natural language checkpoint applies to all user agents.
13:33 ET Adjourned
Copyright © 1999 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C
liability, trademark, document use and software licensing rules apply. Your
interactions with this site are in
accordance with our public and Member privacy statements.
Jon Gunderson, Ph.D., ATP
Coordinator of Assistive Communication and Information Technology
Chair, W3C WAI User Agent Working Group
Division of Rehabilitation - Education Services
University of Illinois at Urbana/Champaign
1207 S. Oak Street
Champaign, IL 61820
Voice: 217-244-5870
Fax: 217-333-0248
E-mail: jongund@uiuc.edu
WWW: http://www.staff.uiuc.edu/~jongund
http://www.w3.org/wai/ua
http://www.als.uiuc.edu/InfoTechAccess
Received on Wednesday, 22 September 1999 15:05:01 UTC