- From: Ian Jacobs <ij@w3.org>
- Date: Wed, 30 Jun 1999 13:39:05 -0400
- To: w3c-wai-ua@w3.org
Minutes 30 June UAGL Teleconference
Ian Jacobs (Chair/Scribe)
Charles McCathieNevile
Harvey Bingham
Marja Koivunen
Glen Gordon
Gregory Rosmaita
Jim Allan
Regrets:
Rich Schwertdfeger
Jon Gunderson
Mark Novak
1) Action CMN: Send URI on default keyboard bindings to list. Ian
will then include in Techniques document.
Status: Done.
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999AprJun/0263.html
Charles has an update on this (and will send to the list).
CMN: In "modern" systems (e.g., Gnome, etc.), you can build your
own bindings at will. The "default" configuration
is less apparent. The problem is more complex than just
advising people not to overwrite certain bindings.
HB: IE has about 30-40 bindings. There's some redundancy in
bindings.
2) Action CMN: Send request to blinux users for info about
orientation.
Status: Not done.
3) Action IJ: Send similar request to IG.
Status: Not done.
4) Action GG: Send ideas on dependent tool point of regard to list.
Status: Dropped on GG's request.
5) Action Editors:
- Add checkpoint about turning on/off author-supplied
keyboard bindings.
Status: Done in internal source files.
Agenda
[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999AprJun/0259.html
[2] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999AprJun/0262.html
1) CMN proposes allowing the user to configure the arrangement of
user interface controls (visually) as a P3.
(http://lists.w3.org/Archives/Public/w3c-wai-ua/1999AprJun/0241.html)
CMN: Tabbing order as much as visual layout. Grouping of controls
and how you get to them. You can do in MS Word and it's very
handy.
IJ: Why do you need to control tabbing order if you have direct
access through keyboard commands?
GG: Novices don't have to memorize keyboard bindings.
GR: One problem with adaptive tech is that unless you have
a toolbar turned on, it won't echo certain formatting
changes. Don't want to have to rely on display of controls
for access to their functionality.
CMN: I'm interested in grouping controls. E.g., with low vision,
want few controls with lots of separation.
IJ: Default is to follow system conventions. But users can
override.
MK: Are we talking about moving around only or being able
to add and delete controls?
CMN: Yes, variety in implementations.
No objections and some support for Priority 3 Checkpoint.
Resolved: Add this checkpoint.
Action: Editors to add to next draft.
2) Checkpoints for guideline 3, about documentation, should be P1.
having to guess these things makes it effectively impossible.
(http://lists.w3.org/Archives/Public/w3c-wai-ua/1999AprJun/0241.html)
CMN: If you have to guess, your lost. Hidden and secret is not
acceptable.
IJ: But "3.2" is about grouping.
CMN: All features of the product must be documented.
IJ: What's the accessibility about documenting all functionalities?
IJ: Are you suggesting "User agent functionalities
described by checkpoints in these guidelines must be documented."
CMN: Yes. Priority 1.
Resolved: No objections to adding this checkpoint.
HB: I'd also like a starting point from the software (readily
available)
that lets me find keyboard bindings.
CMN: For 3.3 - communication of the information is as important
as being able to do it.
Resolved: No objections to changing 3.3 and 3.4 to Priority 1.
GR: Technique for 3.4 - put default keyboard config in README file
at a minimum.
Action editors: Add these checkpoints, make these changes.
3) Proposal on changes to navigation checkpoints
(http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-table.html#66)
IJ: What does it mean to navigate the document tree?
CMN: Prefer to use the term "structure" instead to allow
ambiguity: real (parsed) source tree or a remap of the DTD
(e.g., headings are nested in HTML). More about navigating
what the structure "should be".
CMN: I want a technique that lets people "pass over" information,
but better than just by scanning the entire
document. Sequential gives you context.
MK: It might be that people generally navigate what's rendered
(could be default). Informed users might want to navigate
the tags or through CSS things.
GG: You do need to be able to move backwards and forwards.
IJ: What's the step size?
GG: Have a point of regard that you can navigate by line, word,
sentence, paragraph.
CMN: Move the point of regard, whatever the size of the zone.
And allow configurability.
GG: We are moving from looking only at rendered text to looking
at the document source. This is much richer than just
manipulating rendered info.
CMN: For sequential navigation - fundamental navigation is being
able to read through document in point-of-regard size chunks.
(e.g., line-by-line in braille display).
IJ: I do page down in NN. How do dependent UAs work?
GG: Similar behavior for rendering to speech.
GG: Proposes - allow sequential navigation suitable to device being
used.
IJ: The viewport in short.
CMN: Three ways to navigate the document -
a) Continuous feed (optionally being able to start/stop).
This one is fundamental.
IJ: We have a checkpoint for this: access to all content.
b) Divide the document into structural components (without
specifying how that structure is built exactly - not
necessarily the DTD).
CMN: Jon has argued that this is really important and I
agree. Tree navigation is one technique.
GG: A lot of structure is unimportant to many users: DIV and
OBJECT elements. Navigating the tree is less useful
than navigating some commonly used terms - paragraphs,
headers, etc.
CMN: Yes, strict tree navigation is clunky, but minimally
satisfies the need.
IJ (summarizing):
- Allow navigation of document structure.
- Techniques explain how:
a) DOM is minimal (tree nav)
b) Mix of rendered/source
c) Use commonly understood document models
(based on DTD, but may not match exactly).
d) Simplify view of structure for user.
e) Allow the user to control level of detail/
view of structure.
Resolved: Add a checkpoint about (Pri 4) navigating the
document in a structured manner. For all
user agents. Delete 7.8 (doc tree navigation).
Add a (Pri 3) checkpoint to allow configuration of
the structured navigation mechanism.
c) direct access to an identified point.
IJ: We have a checkpoint for this: search text.
4) Notification of document changes due to scripting events
(http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-table.html#54)
(http://lists.w3.org/Archives/Public/w3c-wai-ua/1999AprJun/0197.html)
CMN: First requirement is that all changes must be available
to AT and user. Probably too much information, so better
implementations will do better.
Jim: Depends on what the purpose of the change is. On my site
for low-vision users, when you move around, the font
size increases. This would annoy screen-reader users.
Information that people want available can vary greatly.
CMN: Given that you can't tell a priori, you must make it
available. I think Pri 1 for desktop to AT and AT to user
as well.
MK: Need some useful default filtering so that user is not
overwhelmed.
Jim (to GG): Can you set up Jaws so that users are informed
of font changes?
GG: We're moving towards being able to do this (and make notification
optional).
NOTE: There's a mix of user needs and author's intentions in using
style that means you can't predict a priori which style info
to communicate.
GR: E.g., drop down menus with links in them (e.g., MS site).
CMN: User agent can tell you that the document (tree) has changed.
GR: MS calls this "active scripting". Happens at a lot of
commercial sites.
Resolved: Generalize 9.2 (drop part about scripts) to talk about
changes to the document. Not just user-caused. For
all user agents. Priority 1.
CMN: Configuration is a higher priority checkpoint in this case
(at least P2).
GR: Priority 1 (my own selfish reasons).
GG: IE 4/5 communicates this info through o.s. conventions today.
Received on Wednesday, 30 June 1999 13:37:29 UTC