W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > January to March 2000

Raw minutes from 13 January UA Guidelines teleconference

From: Ian Jacobs <ij@w3.org>
Date: Thu, 13 Jan 2000 15:44:48 -0500
Message-ID: <387E3940.C22CEC86@w3.org>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:49:51 GMT