- From: Jon Gunderson <jongund@ux1.cso.uiuc.edu>
- Date: Fri, 21 Apr 2000 11:12:04 -0500
- To: w3c-wai-ua@w3.org
Attendance
Chair: Jon Gunderson
Scribe:Kitch Barnicle
RSVP Present:
David Poehlman
Jim Allan
Dick Brown
Al Gilman
Harvey Bingham
Hans Riesebos
Gregory Rosmaita
Ian Jacons (joined at 3:00 EST)
Regrets:
Rich Schwerdtfeger
Charles McCathieNevile
Mickey Quenzer
Action Items
Open Action Items
1.IJ: Draft a preliminary executive summary/mini-FAQ for developers.
(No deadline.)
2.IJ: Propose new 4.15 and 4.16 to list
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0164.html
3.CMN: Propose a technique that explains how serialization plus
navigation would suffice for Checkpoint 8.1.
4.DA: Send name of new organization to list that was mentioned by some
from the US Census Bureau
5.DA: Review techniques for Guidelines 7 and 8
6.DA: Get confirmation that the numbers for checkpoint 4.5 make sense
7.DB: Get Tim Lacy to review G+
8.GR: Look into which checkpoints would benefit from audio examples in
the techniques document.
9.GR: Review techniques for Sections 3.7 and 3.8
10.GR: Send to list screen shot of JFW Window list.
11.MQ: Review techniques for Guidelines 9 and 10
12.MR: Send URI to Micrsoft's implementation of synchronized audio/video
slowing down to the list
13.RS, AG: Take notification of focus and view changes to PF as possible
DOM 3 requirement.
New Action Items
1.AG: Propose wording that will encompass needs to reposition text
equivalents
2.AG: Propose a statement suitable for defining minimum requirements
for structured navigation
Completed Action Items
1.IJ: Propose split to the list. Identify why and issue of priority.
Defer to JG postings:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0166.html
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0169.html
2.IJ: Propose new 4.15 and 4.16 to list
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0164.html
3.DB: Review techniques for Guidelines 3, 4, and 11
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0172.html
Minutes
Open Actions were reviewed
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
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)
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
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.
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.
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.
Action AG: 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.
Copyright © 2000 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
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 Friday, 21 April 2000 12:12:08 UTC