Chair: Jon Gunderson
Date: Thursday, January 13th
Time: 2:00 pm to 3:30 pm Eastern Standard Time, USA
Call-in: Longfellow Bridge (+1) (617) 252-1038
Chair: Jon Gunderson
Scribe: Ian Jacobs
RSVP Present:
Denis Anson
Mickey Quenzer
Rich Schwerdtfeger
Gregory J. Rosmaita
Harvey Bingham
Charles CathieNevile
Dick Brown
Jim Allan
Regrets:
David Poehlman
Kitch Barnicle
Marja Koivunen
[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0080.ht
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.
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
JG: will discuss next weeks telecon
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.
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.
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.
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.
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.
IJ: We will take this to the list.
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.
ResolutionNo objections to leaving P2 as is.
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?
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.
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.