- From: Ian Jacobs <ij@w3.org>
- Date: Thu, 13 Jan 2000 15:44:48 -0500
- To: w3c-wai-ua@w3.org
WAI UAGL Teleconference
13 January 1999
Participants:
Jon Gunderson
Ian Jacobs
Gregory Rosmaita
Harvey Bingham
Charles McCathieNevile
Dick Brown
Denis Anson
Jim Allan
Rich Schwertdfeger
Mickey Quenzer
Regrets:
Marja Koivunen
David Poehlman
NEXT MEETING: 19 January 2000 @ 12pm ET for 90 minutes
Agenda [1]
[1]
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0080.ht
1) Review of action items
1.IJ: Update document with resolutions for issue LC#162
Status: Not done.
2.IJ: Update document with resolutions for issue LC#166
Status: Not done.
3.IJ: Update document with resolutions for issue LC#175
Status: Not done.
4.IJ: Update document with resolutions for Issue LC#176
Status: Not done.
5.JG: Review techniques for Guideline 8.9
Status: Not done.
6.JG: Draft a preliminary implementation report for CR consideration
Status:
http://www.w3.org/WAI/UA/2000/01/wai-ua-implementation-20000112.html
7.DB: Ask IE Team about publication of review of IE 5 and Pri 1
checkpoints.
Status: No news.
8.DB: Find out how developers find out which appropriate triggers to
use in
Windows for using built-in accessibility features (i.e. sound sentry,
show
sounds, ...)
Status: No news.
9.DP: Propose new Checkpoint 1.5 for access to system messages
Status: No news.
10.GR: Send to the list techniques for how to use and control focus to
not
have new windows cause problems for usability. In particular, how this
will
work with ATs.
Status: pending
11.GR: Send screen shot of JFW link list to the list
Status: pending
12.MK: Find out techniques for sending text search requests to servers
of
streamed text.
Status: No news.
13.MR: Review techniques for topic 3.1 (Multi-media)
Status: No news.
14.MR: Review techniques for Guideline 4 (Multi-media)
Status: No news.
15.MR: Run a multimedia player through the guidelines for January.
Status: No news.
16.MQ: Ask Mark about meaning of comment raised in Issue #167
Status: No news.
17.WC: Take form submission to GL WG to discuss issues related to
inadvertent
submission.
Status: No news.
2) Announcements
1.Extra UA telecon scheduled 19 January 2000 at 12:00 pm to 1:30 pm
Eastern
Standard Time, USA
http://www.w3.org/WAI/UA/2000/01/wai-ua-telecon-20000119.html
2. Please refer to page for tracking upcoming CR review
http://www.w3.org/WAI/UA/2000/01/reviewers-cr
3. Will attempt for week of 10 April for next face-to-face.
DA: Early the week of the 10th better for me.
Action JG: Find a host/date for the meeting.
3) Issue LC#142: Checkpoint 1.5 (output device-independence) needs
clarification.
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#142
IJ: Refer to DP's action to rewrite 1.5.
Action IJ: Repropose checkpoint 1.5.
Action GR: Contact DP offline to follow up on his action.
4) Issue LC#158 Propose priority change (1 to 2) for checkpoint
4.1 (control of font family)
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#158
JG: Objections from JG and DP on the resolution to go to P2.
JG: I work with people with visual impairments. Serifed fonts
like Times NewRoman are difficult to read.
GR: From conversations offline, people feel that this is P1.
Observation: Lots of evidence that implementable.
DB: You can change fonts in IE.
CMN: You can do with style sheets.
RS: Does this checkpoint apply to cell phones?
CMN: The requirement, yes. However it may not apply to those
phones that only have one font available.
/* Discussion about mobile technologies */
DA: One way to specify the font is presumably through style
sheets.
RS: I think that 4.1 (in 20 December GL) should be P2. Part of
the problem is the number of P1 checkpoints we have.
CMN: We should resist that pushback. The goal is to solve the
problems people face.
DB: I share some of RS's concerns, but I think this one is
very important. I personally have problems reading some
pages.
GR: I think that it's
a) Important
b) Implemented
c) Implementable.
And thus P1.
RS: I can live with this as P1.
JA, HB: P1.
Resolved: Make the checkpoint a P1.
/* Discussion of applicability of Guidelines to mobile devices */
IJ: Recall W3C Mobile IG review of last call draft:
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0533.html
Action MQ: Ask Mark Hakkinen about mobile devices and the
guidelines.
Action JG: Take issue of mobile devices/guidelines in next
WAI CG meeting.
5) Issue WD#179: Priority of 5.8 should be Priority 1
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#179
JG: 5.6 in 20 December draft
"Follow operating system conventions and accessibility settings"
IJ: I would argue that not following conventions is not a P1
issue. A tool may be very accessible and not follow
conventions (might be hard, admittedly). An inaccessible
tool would have other problems more grave than not following
conventions.
CMN: I think a sliding priority scale might be useful here.
I think we probably make the most important ones P1
explicitly in these guidelines. Therefore, probably ok to
stay P2.
Resolved: Leave a P2.
6) Issue WD#180: 10.8 should be priority 2
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#180
JG: 10.8 from 20 December 1999 Draft. Alan Cantor thinks that
for learning and cognitive disabilities, should be P2.
DA: I think that it's also a physical disability issue
(too close, too far).
DB: Is this about toolbar customization?
JG: yes.
DB: It sounds like we're trying to solve a problem of
bad design.
DB: Note that there are keyboard equivalents for most of the
controls.
CMN: But often not direct; require tabbing. I'd like to be able
to change the tabbing order...
GR: For people with certain types of disabilities, the visual
iconic information is easier to retain than a list of
commands. Thus, being able to rearrange the chrome is
important for consistency, knowing where things are.
DB, RS: Still think it's P3.
JA, HB, CMN: I'm on the fence.
RS: Seems like ability to change tabbing is a lot of work
to change bad design.
JG: My concern is that this is a general checkpoint. You
could do things that don't enhance accessibility and
still conform.
IJ: I think the close together/far apart requirement is
probably P2. I don't know how to express the learning
disability requirement as clearly.
CMN: Jonathan Chetwyn always talks about "show/hide".
DA: Not just toolbars: menus, etc.
RS: Be careful, you're almost reproducing the work of the
authoring tools layout requirement.
CMN: I think we need to specify what we need more.
Action CMN: Follow up on this with some learning disability
people.
IJ: It sounds like, however specific the requirement, some
configurability would be required. But it sounds like there
will be resistance to configurability, so how do we hope
to advance here?
RS: I think it should be there, but P3. Is the order of toolbar
buttons a P2?
JG: What about limiting to "toolbar"?
RS: Yes, those boundaries are more resonable, but ...
DB: This doesn't feel like a P2 to me.
Action DA: Follow up with Alan Cantor (done by email during
meeting).
DA: Looking at techniques, they are all based on current toolbars.
We will take this to the list.
7) Issue WD#182: Should searching equivalent text be an AT
responsibility
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#182
7.5 Allow the user to search for rendered text content,
including text equivalents of visual and auditory
content. [Priority 2]
JG: Note that this is for rendered text only.
IJ:
- If it's rendered for some people, it must be rendered for all
people.
IJ: What does it mean to search on something that's not rendered?
What happens when it's found? Will you have to rerender
content?
GR: My concern: people work in a corporate environment; they can't
change options or preferences. They have image loading turned
on and can't turn it off.
IJ: (One technique is view source.)
IJ: It doesn't make sense to me that socially, someone cannot
access a browser's functionalities and therefore to require
the browser vendors to do more.
RS: I'm familiar with this problem (working on JavaOS). Some
clients are downloadable that can only be configured by the
sysadmin. It's not the application that has the problem,
it's the policy. What needs to be fixed is not the UA.
GR: I agree it's not the UA's responsibility to make up for
bad management.
IJ: I think that it's not useful to fish around in the dark:
ask the UA to render and then look for things.
GR: If the requirement is only rendered text, we need to highlight
this in the AT appendix. Searching and configuration of non
rendered info may be left to ATs (refer to JFW).
Action IJ: add this info to appendix.
HB: What about META? Are we allowing people to search for that?
IJ: Today, no one has access to it.
CMN: It's not part of the semantics of HTML to render META. It is,
for example, to render "title" and "alt".
JG: In fact, people put information in META that they *don't*
want rendered.
CMN: It seems counter-intuitive to find something that you don't
know is there (since it's not rendered).
GR: Netscape gives you an information page. No meta information.
But that's clearly a place where that information could be
exposed.
No objections to leaving P2 as is.
8) Issue WD#183: Proposed rewording to checkpoint 7.5 (search alt
content)
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#183
IJ: What's the difference?
Resolved: shorten to checkpoint text to:
Checkpoint 7.5 Allow the user to search for rendered text
content, including rendered text equivalents.
CMN: I wonder whether we need a requirement for view source...?
IJ: Isn't that a technique for structured view?
9) Issue WD#184: Proposed simplification to checkpoint 1.1
(device-independent access)
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#184
Proposed:
1.1 Ensure that each functionality available
through the user interface is also
available through each supported input
device API. Excluded from this requirement
are functionalities that are part of an input
API itself (e.g., text input for the keyboard
API, pointer motion for the pointer API,
etc.)
IJ: I might change to "through each input device API supported
by the user agent" for clarity.
Resolved: Adopt the proposal.
Action Ian: Adopt this wording.
10) Issue WD#185: clarification of "single key" access
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#185
GR: When you have to hold down one key and press another, that's
a problem.
JG: Sticky keys is available, but requires a second key.
RS: I think we need to give users the option of:
a) Either a single stroke
b) A sequence, without being required to hold down a modifier.
DA: I think direct access to a subset of functionalities is what
people want.
RS: We differentiate "key sequence" from "key chord" (one or more).
Goals:
- Avoid key chord.
- Single key is best, but not always applicable.
- Sequence applicable in some cases (e.g., where motion
involved).
IJ: We mean "Every functionality that may be operated through
a single stroke, but not all functionalities assigned
at once to single keys."
DB: But functionalities aren't always one step. I think we are
talking
about macros.
IJ: Take case of print: you have both "single stroke" printing
and the preferences menu (for multiple changes). You want single
key for the former, doesn't apply to latter.
GR: substitute "any" for "every".
Action DB: Send proposal for new text for this requirement.
Adjourned 15:43 ET
--
Ian Jacobs (jacobs@w3.org) http://www.w3.org/People/Jacobs
Tel/Fax: +1 212 684-1814
Cell: +1 917 450-8783
Received on Thursday, 13 January 2000 15:46:08 UTC