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

raw minutes April 20th telecon

From: Kitch Barnicle <barnicle@trace.wisc.edu>
Date: Thu, 20 Apr 2000 14:46:16 -0500
Message-Id: <4.2.2.20000420130439.00e03de0@trace.wisc.edu>
To: w3c-wai-ua@w3.org
Hans
Dick
Al
Jon
Harvey
Kitch
Jim
Gregory
Ian

Regrets
Charles
Mickey
Rich

Notes by Kitch  (so not as good as Ian)

Open Actions were reviewed

DB: reviewed techniques for 3,4. and 11. and sent to list


New Action
AL : Will bring notification to PF group  (take over action previously 
assigned to RS)

Announcements

1. A week from today  (April 27th, 4:00 Eastern  there will be special 
joint GL UA call related to markup for navigation - to develop consensus on 
techniques for marking up links for navigation . Hopefully results will be 
clear guidelines for inclusion in the techniques UA and GL   (Wendy has 
sent proposal re: using MAP for navigation bars).

2. If UA group does not get through open issue there will be an extra 
telecon on the 25th


Discussion

    1.PR#277: Use DOM level 1 , if DOM level 2 recommendation not ready in time
      http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#277


    2.PR#273: Checkpoint 10.9: Why graphical controls only?
      http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#277


JG: This is a priority 3. Currently the doc only talks about graphical 
controls.
Reviewing: Ian's proposal
What would be the minimal requirement to satisfy?

JG: Jon proposed "allow user

GR: Could we change the graphic . For example, use the tool tip to replace 
the graphic.

AL: would like to have option to order things listed in a menu, 
particularly useful when accessing auditorially (like phone menus)

DB: sounds like it is going beyond rearranging graphics

JG: Original purpose was for individuals with small range of motion, could 
cluster controls in a area together.  During review, other reasons for 
rearranging elements were brought up, for example rearranging menu items

HR: Do we consider the menu to be a control?

JA: Does that include min, max...we could end up rearranging whole screen?

JG: min requirement may just be changing the position or number

AL: Yes, I wording does answer the reviewers comments. The re-wording is ok.

Proposed Wording  For graphical user interfaces, allow the user to configure
   the arrangement of user interface controls.

Resolved: Accept IJ's rewording of Tuesday 4/18/00

JG; Allow the user to change the number, position and function of the 
buttons on available tool bars??

DB: does that mean change the function of a button

AL; Allow the user to change the number, position and selection of the 
buttons on available tool bars??

DB: we don't want to require a tool bar

Allow the user to change which functions and the positions of the functions 
on available tool bars

Note to Ian  - We want wording to the effect - allow user to choose which 
function/buttons show up where on the toolbar.

SHOULD MENUS BE INCLUDED

Al; Users of speech won't know about hot keys until they get to in a 
sequential manner.

JG: May also be an issue for individuals with the cognitive disabilities

JG: seems like order and number could be important for individuals who are 
blind and who cognitive disabilities

JG: We need to specify a minimum requirements so everyone doesn't interpret 
this differently

JG: What about - Allow the user to change the order and remove and add of 
items in pull down menus.

KB: I would want a restore feature if we are going to allow people to 
remove menu items.

JG Should we add - Also user to restore default configuration.

GR: Would restoring defaults be covered in our profile checkpoint.

JG: Allow the user to restore default the menu and toolbar settings (cross 
reference checkpoint 10.7)

DB: does this mean default for menus and toolbars together or just one menu

AL: point of cross reference - if there is a profile mechanism user should 
be able to restore to factory defaults - Users would need restore 
application defaults

Summary - 3 requirements

1. Allow the user to change which functions and the positions of the 
functions on available tool bars Note to Ian  - We want wording to the 
effect - allow user to choose which function/buttons show up where on the 
toolbar.
2. Allow the user to change the order and remove and add of items in pull 
down menus.
3. Allow the user to restore default the menu and toolbar settings (cross 
reference checkpoint 10.7)


    3.PR#271: Checkpoint 4.7: Change to P2 since arbitrary repositioning 
not a requirement.
      http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#271

JG: At f2f - key issues 1) alt equiv is not obscured , 2) video/image can 
be viewed simultaneously with the transcript

Notes from Ian UA doesn't have to allow for configuring - if information is 
not obscured

AL: This is p1 because of the need to support simultaneously magnification 
and captions. Not intent to always require arbitrary positioning, but some 
configuration capability that makes simul mag and captions.

AL: Wording on not obscuring not the best way to answer the commenter's 
questions - want to make it clear - it is not arbitrary control.

JG: Good if we can express in functional needs, that is where obscure 
wording is helpful

AL: User has to have the choice - content may need to obscure other content 
- user should have reasonable control, if captions get so big they it has 
to blot out video..want to leave control in hands of user - whether need to 
obscure or not

JG:

AL: minimum implementation under magnification - need to be able to place 
captions

Action:

AL: Al will post to the list a discussion of this topic to show that we 
still need to work on wording

JG:
1)this is priority 1
2) we do need to allow user to choose whether info is obscured or not
3) functional requirements - how much configuration is needed.


    4.PR#260: Guideline 1 checkpoint language unclear.
      http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#260

Review Ian's proposed new language

<new>
1.1 Ensure that every functionality available through the user interface
     is available through every input API implemented by the user agent.
     [Priority 1]

           Note. This checkpoint does not require developers to
  implement all operating system input APIs, only to make
the  software accessible through those they do implement. The
device-independence required by this checkpoint applies
to  the functionalities described by the other checkpoints
in this  document (e.g., installation, documentation, user agent
user interface configuration, etc.). This checkpoint does not
require developers to reimplement the input methods associated
with the keyboard, pointing device, voice, and other device
APIs For example, developers are not required to implement
text  input through a mouse API.
<new>

<NEW>
  Note. Developers should use APIs available at a higher level of
        abstraction than device APIs, provided that, in turn, these
        higher level APIs make use of the standard device APIs for
        the operating system.
</NEW>


<NEW>
1.4 Implement the standard keyboard API of the operating system and
     ensure that every functionality available through the user interface
is     available through this API. [Priority 1]
         Note. This checkpoint always applies on systems with a
               standard keyboard API. This checkpoint is an important
               special case of checkpoint 1.1. Refer also to checkpoint
10.8.
</NEW>


JG: I think we are clear that developers don't need to generate text 
through a mouse.

JG It is clear that if you implement voice input you should do it 
accessibly. Developers would probably want to make the whole thing voice 
accessible.

AL: May run into this problem (voice control not working) during 
installation. What if installation doesn't support voice input.

JG: Gregory would installation be considered a separate program.

GR: I would consider installation part and partial of product.

Ian joined (yeah!)

IJ: There could be a boot strap problem. If you have to install voice 
component it could be a problem.  If OS doesn't support voice, how do you 
install UA with voice.

GR: Other example, screen reader installation is self voicing - installs a 
temporary module until actual program gets installed

JG: Let's move this to the list

IJ: any objections to incorporating.

Resolved: adopt Ian's proposal with incorporation of comments from the list.


    5.PR#257: Difficult to know when a UA has conformed.
      http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#257



    6.PR#233: Checkpoint 7.6: What does "structure" mean here?
      http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#233


JG: Related to configure UA to navigate structure. Current  min reqs 
proposal for 7.6 - says 1) allow user to sequentially navigate current 
through rendering in the viewport  human recognizable.....for example, 
header...... 2) if no structural defined use programmatic 
structure....  (see draft requirements doc)

IJ: Sounds like minimum is to use document object.
The DOM is limited to XML and HTML. Document objects can include scripts or 
other

Document Object - user agent's representation........ see Ian's proposed 
definition

IJ: not clear in generic sense what is actually in the document object... 
the W3C DOM is specific, document object not

IJ: Structure -  What it means is document object. It has structure, so 
minimal navigation.

JG: For example in HTML, would have a command that would allow you to 
highlight each element in the document tree.

JG: this would allow users to identify an element on the screen and know 
what that "chunk" represents. But some people have pointed out that there 
are human understandable things (e.g. heading level 2 should be under level 
2 etc)

IJ: For a lot of these checkpoints  it is difficult to specify minimal 
requirements. Here is one where absolute min. req is navigation of 
everything in document object in a particular viewport.  We expect more and 
when there are conventions like for HTML, we expect more.    We can say min 
is access to every element in the tree and we can add suggestions for how 
to do it better.

IJ: If we express what we are thinking  - structured navigation - does that 
help developers.

JG: we want to give people more guidance the we currently are on how to 
satisfy this checkpoint. The min. should be to provide the capabilities for 
more complex navigation in the future. This may also be device specific.

IJ: When we say navigate - what are the navigation functions, so far we 
have forward serial navigation. We haven't talked about going up the tree 
and across siblings.

AL: Al will take an action to post to the list about structured navigation

HR. Does this DOM tree related to rendered content

IJ: no???

JG: just because something is in w3c DOM tree doesn't mean it is for human 
understanding. Just because you are navigating tree doesn't mean it is 
human understandable. For real structured navigation, what better 
navigation. Actually want to go a step beyond the DOM. More beneficial once 
you can configure.

JG: Current minimum is navigating the document tree.

IJ: We do want to clarify the "more" we are looking for in this checkpoint. 
We decided to stay more general and flexible but we have had a bunch of 
ideas for navigating (in techniques).

JG: not resolved until we hear from AL

IJ: can we take 2 minutes to hear from Gregory on DOm

GR:  concern - we decided to make a forward looking document. Stepping back 
is more for ER group.
There is a dependency between UA and PF to ensure that PF is monitoring DOM 
work and playing a greater role in ensuring DOM 2 addresses our concerns.

IJ: I think we chose to go with DOM2 because we liked what it had to offer. 
Dropping to DOM1 is more a strategic decision to get a document out.  Few 
documents are XML. I encourage us to drop to DOM1 and get the UA document 
out the door.  For CSS, I could part with it in order to get this document 
out and in the next  round adopt CSS and events that suit us.


IJ: Still have the option to build in language that we "move up" to DOM2 
some time after it is out.


JG
1. wait for DOM 2 to come out (4-6 months)
2) go back to DOM1 - already out, we can control our timing to 
recommendation, could incorporate DOM2 when desired
3) add contingency language - adopt DOM2 when available (we think we know 
what we will get)

Harvey- we'll have to go through another 3 months after DOM2 is out

IJ: Much content does not use namespace today. We should get document out now.


    7.PR#211: Do we need to say "alt equivs that have been marked up as 
such" in 2.1 and 2.5?
      http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#211



    8.PR#207: Interpretation checkpoint 2.1
      http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#207


Open Action Items

    1.IJ: Draft a preliminary executive summary/mini-FAQ for developers. 
(No deadline.)

    2.IJ: Propose split to the list. Identify why and issue of priority.

    3.IJ: Propose new 4.15 and 4.16 to list

    4.CMN: Propose a technique that explains how serialization plus 
navigation would suffice for Checkpoint 8.1.

    5.DA: Send name of new organization to list that was mentioned by some 
from the US Census Bureau

    6.DA: Review techniques for Guidelines 7 and 8

    7.DA: Get confirmation that the numbers for checkpoint 4.5 make sense

    8.DB: Get Tim Lacy to review G+

    9.DB: Review techniques for Guidelines 3, 4, and 11

   10.GR: Look into which checkpoints would benefit from audio examples in 
the techniques document.

   11.GR: Review techniques for Sections 3.7 and 3.8

   12.GR: Send to list screen shot of JFW Window list.

   13.MQ: Review techniques for Guidelines 9 and 10

   14.MR: Send URI to Micrsoft's implementation of synchronized audio/video 
slowing down to the list

   15.RS: Take notification of focus and view changes to PF as possible DOM 
3 requirement.



Jon Gunderson, Ph.D., ATP
Coordinator of Assistive Communication and Information Technology
Chair, W3C WAI User Agent Working Group
Division of Rehabilitation - Education Services
College of Applied Life Studies
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
WWW: http://www.w3.org/wai/ua
Received on Thursday, 20 April 2000 15:46:18 GMT

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