Raw minutes/12 December 1998/WAI UA WG Face-to-face in Cambridge

WAI UA WG Face to Face
Cambridge, MA
12 December 1998

Chair: Jon Gunderson (JG)
Scribe: Ian Jacobs (IJ)

Participants:
Olivier Borius (OB)
David Clark (DC)
Kathy Hewitt (KH)
Daniel Dardailler (DD)
Glen Gordon (GG)
Wilson Craig (WC)
Charles McCathieNeville(CMN)
Denis Anson (DA)
Chuck Oppermann (CO)
Harvey Bingham (HB)
Wendy Chisholm (WAC)
Markku Hakkinen (MH)
Judy Brewer (JB)

---------------
8:30 am

JG: We're not moving forward enough. I would
like to propose the following (conceived with
DA last night): Split document into two guidelines
those for visual and those for non-visual user agents.
How does this affect compliance? Compliance based
on what media type a UA supports. Note that one
company's compliance should not depend on another
company's compliance.

DA: Background - one assumption: niche market browsers
only provide the functionality specific to their
market. But warning: a UA might say that their
niche market is mouse-using visual. Allowing compliance
in that area would not be acceptable.

IJ: We already have the pieces in the document. See
section 1.1 of the techniques document. Need to
integrate that into conformance. But conformance
by one company must not depend on conformance or
even existence of another company's product.
The guidelines must be written so that this
is possible.

JB: Denis' background was helpful. But I don't
know how conformance implies breaking into
several documents.


WAC: 
1) We had similar discussions in the PAGL WG.
We ended up with two documents, split according
to certain dependencies. 
2) Agree with need to comply based on
   media. Several checklists (media split).

MH: The term "UA" is already a tricky term.
It includes a lot of devices. Let's define
UA clearly, but in one document.

CMN: As RMIT's member until two weeks ago,
under the impression that we didn't divide
the world based on niche markets, but rather
media type dependencies.

DC: I understand the impetus for the proposal,
but I have concerns about it. Need to distinguish
source from rendering. Of course IE is not a
voice browser. But that doesn't mean they can
say "we don't know need to support rendering
content auditorially since that's not our
purpose." Difference between inter and intra
media interpretations. All UAs need to
facilitate inter media rendering. Other concern:
saying assistive technologies can do something
doesn't get us further. Users still need to
buy the other products to get the job done.
I can walk up to any MS machine and can use
it thanks to built-in keyboard support and
accessibility.

HB: If we fragment this document into special case
needs, we must do the interface definitions very
carefully.

MH: I agree with DC and HB. Also a question for
MS - where will my handheld computer fall?

/* IJ shows how media types are used in the
CSS 2 specification: http://www.w3.org/TR/REC-CSS2 */

WC: If we split into two documents, how will
compliance be measured? Who will I claim compliance
to?

CMN: To follow up: we should not split the document.

Consensus: The WG will produce one guidelines
document (with a techniques supplement).

DD: Media conformance (as in CSS) is a more
general solution than a visual/non-visual split.
It wouldn't be practical to split into N documents
for N media types.
    It's my opinion that it's more important to
    make sure mainstream UAs are compliant rather
    than focusing on specialized UAs

MH: I agree with Ian's model as shown in CSS2.
How does co-dependency work? What if a UA
and another in conjunction form a "fully compliant"
UA? 

DA: Nice if we can use divisions across documents
(i.e., with CSS2). 

KH: I like the media type split idea. If we claim
to support a given media type, we implement natively.
Otherwise we make the information available through
an interface.

JB (to MH's comment): Danger in assistive techs
"sleeping with" mainstream UAs in terms of compliance.
On the one hand, ensures access. But limits competitive
choice.

MH: Important point is that it's not vendor-specific.
If we do this through DOM, I work immediately with
another UA that employs that interface.

DC: Ensure media separation.

DD (to MH): I can't map DOM onto a media-dependency.
I can't force a handheld device to comply with
DOM since there's no way to plug it in. Consider a small
device that does visual but that is too small to
support the DOM.

CMN: Here's where it does apply: In Australia, there are
information kiosks everywhere. There is no
way to plug into that browser.

DD: In addition to media independence, an attribute
such as "I claim to export". 

DA: If I'm a device that doesn't do, e.g., video,
how do I support video? Must I support alternative
representations of it?

JG (Summarizing)
 1) One document
 2) Media type split
 3) How to handle unsupported media
 4) What happens when a UA can't communicate
    with others.

IJ: We're stuck on table linearization because
of dependencies. When each UA is independent
for what it does (w.r.t. a media type) and provides
info through an interface for what it doesn't, we
are all happy. But the case of screen readers shows
another dependency: the screen reader depends
not on the interface but the visual rendering. 

JG: We want long-term solutions, not quick fixes.

Resolved: Make full conformance with DOM level 1 a priority
one technique for UAs that export HTML or XML
information.

KH: We do some things with MSAA, others with DOM.

Action editors: 
  1) Propose conformance text to the mailing list
  2) Propose media type text to the mailing list

/* Break */

10am

GG: Good idea to specify the level of functionality
expected (by media type). Standards should not
say how something will be implemented.

IJ: Rationales should describe goal. But
conformance is to a specific list. Conformance
is not to "accessibility" in general. 

/* End of conformance discussion */

5.2 Point of regard

5.2.1 Is this a priority 1?
 
IJ: 5.2.1. For UAs that support multiple views.

DA: Think should be a priority 2.
DD: Think should be a priority 2.
GG: Think should be a priority 2, in particular
since some things have to go (i.e., from
Priority 1s). Jaws used to not provide frame
information and people survived. Now they do
(for IE).

CMN: How does this extend to having multiple
browser processes.

GG: Most screen readers will typically tell
you as you move from window to window and
process to process. Typically title bar info
will tell you where you are.

IJ: Is there some class of disability for
which browsing would be impossible?

CMN: May be an issue for some people
with cognitive impairments.

DA: May be some individuals, but can't
say whether would be impossible for
all people to use.

WAC: Implication for PAGL. We have a technique
that it's a priority 1 to name all frames. Does
this change our requirement?

DC: Will priority levels be evaluated during
cross-disability review?

JB: Yes. Comments on guidelines will be sent
to the appropriate list. Senders won't do
further advocacy or become WG participants.

5.2.2 

CMN: Priority 1, applies to all media types
that are dynamic.

IJ: In the CSS spec, we have the media group
"interactive". Thus, printers don't have
to allow highlighting.

GG: Why is selection a priority 1? 

CO: In visual realm, we use standard system
colors and attributes for selection.

IJ: Selection required for *all* users.

DC: Do we want to add "programmatically"
to all of these.

CO: Separate "rendering" (e.g., of focus)
    from "access to" (programmatically).

GG: There are cases when you can't get
at the selection other than how it's
rendered.

DA: If you provide a selection mechanism,
user must know how it is selected.

IJ: I think highlighting is Pri 1 since
everyone in this room needs a highlighting
mechanism.

CO: Currently, there's no means in the Windows OS
   to do selection (programmatically). Selection
   color should be removed (or color changed) when
   you switch windows.

Resolved: 5.2.2 Priority 1. If UA supports selection
mechanism. Media: all.

CO: Add to "identifying" : "through standard
interfaces where available". Worried about
wiggle room if a UA implements rendering but
not through a standard OS interface.

DA: Don't forget sound highlighting.

DC: I think wiggle room is ok.

5.2.3 Is this the same issue? 

CO: Focus is more important than selection,
but should be treated the same.

CO: Editorial comment - keep wording similar
between selection and focus for all pertinent
techniques.

5.2.4 

CMN: I suggest that this be moved to Pri 2,
with caveat that cognitive disability groups
might respond that this deserves Pri 1.

DC: I second this.

KH: I think there are two scenarios:

1) Moving viewport to follow focus. I think
  Pri 1 to move the viewport to follow the focus.

2) Moving focus to follow the viewport. I think
  Pri 2 to move the focus to follow the viewport.
  This is a good feature. Should be available,
  user should be able to turn on/off.

CMN: Propose Pri 2 for case 1, Pri 3 for case 2.

DC: We shouldn't be delving into User Interface
   issues so much.

CO: Important to ensure that focus, selection, etc.
    be in the viewport. Think that 5.2.4 should
    read that the user's POR be within the viewport.

CMN: Example - using emacsspeak. Wouldn't want
   it to read what's a page and a half away from
   the viewport.

DC: Don't think guidelines should discuss UI.

The focus can be outside of the viewport, but if
it changes, the viewport must follow it.

WAC: If I scroll down and focus outside of
viewport, but start tabbing, should the viewport
move to the focus earlier in the document
or the focus move into the viewport?

IJ: Propose two techniques:

 1) Priority 1 when focus changes, must then
    be in the viewport.

 2) Whether you move the viewport to meet the focus
    or the focus to meet the current viewport's location
    is not Priority 1. 

DC: Focus and tab order could be different. If you
    search text to move to a point in the text,
    your focus doesn't change, but your selection
    does. 

IJ: Propose that when the selection changes,
it should be in the viewport afterwards.

WAC: I'm confused.

/* Ian tries to explain */

Resolved: Priority 1 when focus or selection changes,
afterward the focus or selection must be in the viewport.

WAC: Proposal: I think moving the focus to follow the
viewport should be at least a Priority 2 functionality.

CMN: Should be a togglable feature.

JG: Add a navigation command to move the focus
to the first focusable place in the viewport if
one exists.

IJ: For any "thing" you want to navigate to,
navigate to the next logical "thing" or navigate
to the next "thing" in the viewport.

CO: But how does this interact with tabindex?

IJ: Good question.

/* CMN Proposes we push this to mailing list
and move on to script navigation */

5.3

Note:
MS would like to get feedback on keyboard models.
Cf. the Web TV-style model (four buttons to
get anywhere on the page). MS also working on
keyboard navigation to non-document parts of
a UI. After the meeting, we would like to solicit
input from people interested in this.

5.3.1

JG: From last meeting, sentiment that scripts
are not inherently accessible or inaccessible.
But when a script creates a user interface,
it should follow the UA guidelines related
to interfaces.

DA: This means a script might be considered a UA.

JG: There are both device-dependent and device-independent
events (e.g., mouse-down, etc.).

/* Editor's note: sort techniques in section 5.3 */

DC: There's a difference between server-side and
client-side scripting. We're concerned about
changes to the UA output.

CMN: I have a question about triggering events.  The
device-independent part is covered by 3.1.1 (allow device
independence). I would like this group to formally take this
to the P&F WG and examine the event model and take to
HTML/DOM WGs.

JB: It's already in that WG.

DD: 5.3.1: We need to say that doing this through
an API is ok. 

CO: IE currently and will in the future support 5.3.1.
User can say disable/enable/prompt before scripts
are executed. 

IJ: Add "security reasons" to rationale section
about alerts before script is executed.

DD: Divide "ability to alert" from "user wants
to be alerted".

CNM: Propose to drop 5.3.1 (since, e.g., some
scripts don't cause change). Boost 5.3.2 up
in priority and say "when changes occur,
there could be accessibility problems".

CO: Let's keep 5.3.1. It's a stop-gap
(and MS already does it!) It's a useful
technique.

GG: From a usability standpoint, it's not
clear how valuable it is to know something
before every script is run. I may want
to disable or enable all scripts. But
when a change occurs, I want to know. But
impossible to know what the change is.

DA: Gregg Vanderheiden has an example of a page
with a spinning globe. If the globe is decorative,
who cares. But if it's a map with links, knowing
that and providing alternatives is crucial.

IJ and WAC talk about interdependence of
PAGL and UAGL on this issue. Not sure where
burden should fall.

DC: 5.3.2 has to be priority 2 if not level 1.

WAC: I agree with DC that 5.3.2 should be Pri 1.

WAC: Notification based on execution
and timing of execution configurable.

IJ proposes:
  1) UA should allow turn on/off scripts (3.3.8)
  2) Author should provide alt information for
     important scripts describing what a script
     will do (e.g., cost money, change environment).
     Talk to PAGL WG and HTML WG about this.
  3) UA must provide access to that information.

DC: Difference between notification and instant
rendering.

CO: MS is coming from a background of documents
that suddenly got behavior. Can we get a "title"
attribute on SCRIPT element?

/* "title" is not on SCRIPT element in HTML 4.0 */

CO: Lots of scripts are just useful to programmer.
In other languages, you wouldn't want this, why
for HTML.

CMN: Yes, we want document about what code does.
Specifically for embedded applets, PAGL requires
that that information be available through other
means. Also suggests that in the content of the
page, explain what important scripts will do.

DA: I only want to know about *significant*
changes. Just like a button on a user interface.

GG: There seems to be two kinds of scripts
1) One makes underlining page look smarter. You
   don't care about that type of script. This type
   we don't care about.

2) Another script makes the page behave in an 
   unexpected fashion that might cause a screen
   reader to miss something. Need to provide
   a description (e.g., on the status bar).

The average community is not striving for
this functionality.

KH: The UA doesn't know what a script will do.
The author knows what the script is expected
to do.

IJ: There's (unfortunately) no longdesc on SCRIPT,
which seems to be the missing piece.

DC: To provide alt content for scripts:
 1) Use NOSCRIPT
 2) Use "alt" with APPLET.

DD: A script can generate html that is included
in the document that explains what the script does.

IJ: Good idea.

CMN: We're not asking UA to figure out
script semantics. We're asking Authors to provide
a description.

CO: We should expect that script authors not
do unexpected things. Or we expect authors
to document them.

DD: Proposes:
1) Users must be able to turn on/off scripts (Pri 1)
2) When scripting changes the document output (which
   the UA knows after the fact), the UA should alert,
   through an interface, that the document has changed.
   Pri 1.

   CO: There is work under way in msaa to inform of changes
   in document model.

   DD: Also being discussed by DOM WG.

   CMN: Note also that this is covered by the guideline
   to use W3C specs when available/pertinent.

The rest is not up to the UA to handle.

========

What to expect in near future:
1) No document before end of year (due to
   editor commitments)
2) Will keep issues list up to date.
3) Proposals from editors will be 
   sent to mailing list before
   being integrated into document.
   [Some Subject trickery like "Proposed: ..."]

JB: I've seen other WGs do this (face-to-face
   and teleconfs): issues will have been posted,
   discussion on email, hammered into a proposal,
   then consensus is declared and the issue
   considered "closed" unless new information
   is presented.

IJ: Chair is also resonsible for recording minority
opinions.

/* Lunch */

Should we allow users to navigate elements
with scripts and synthesize those events (trigger
them through other means)?

Need "onactivate". (Not in HTML 4.0).

GG: This should be a DOM issue and adaptive
technology vendor issue.

5.4.4: Navigation among elements with event
handlers.

DD: Do through the DOM (interface).

CMN: I don't think that *navigation* of these
is not priority 1 (should be pri 2). And
the triggering is covered by 3.1.1.

KH: I don't think that any of 5.4.1/2/3/4 should
be priority 1. I think navigation among
active elements is priority 1.

IJ: Pri 2 to navigate among specific classes of objects.

KH: Another concern - conformance. In IE currently,
we don't provide keyboard access to elements unless
they are links or form controls. E.g., can't
navigate to headers with associated scripts. Want
to ensure that techniques written so that missing
one functionality doesn't mean conformance broken
for three techniques.

CMN: But if you don't give access to headers
with "onmouseover", you violate more than one
technique.

WAC: Scripts are to browser what browser is to
OS (with inheritance). 

CMN: Scripts need repair strategy from UA. We
would all benefit from a proper event model.

DC: I concur with my colleague from Australia
that 3.3.1 covers this whole discussion.

/* Discussion of synthesis of event triggering */

CO: Problem is not identifying the events but
identifying the keyboard model for activating them.
(Navigating from element with event to element
with event).

IJ: Not hard to insert events into the list
of things that can have focus. Then right
click to activate a particular event.

CO: In theory, not hard. But would be ugly.
I think this should be handled by P&F.

DC: I hear CO saying that if it's ugly then
we shouldn't put it in the guidelines.

CO: I *do* want to do this. It's political issue,
   to. If you provide a "crutch" (for keyboard access),
   the result could be lazy authors. "We don't 
   have to provide keyboard access since the UA does it."
   
JG: Proposed 5.4.4. Do we provide a repair
strategy for this case?

CO: I think the technique should be in there,
should discuss the priority.

CMN: Don't think we need a repair strategy. The
solution is ugly. The more specific we make our
solutions, the more we lock ourselves into those
solutions. My favorite 3.1.1 covers us and we
shouldn't discuss implementations. Let P&F fix
this properly. The more we specify the repair
strategy, the more we delay creating a real
solution.

WAC: If a priority 1, you would navigate to
a lot of elements that aren't really that
interesting.

DC: I read 3.1.1 to mean program commands
generated output. 

JG: Leave in 5.4.4 as Priority 2 for now.

CO: Propose to move to issues list.

-----
JG: How do we deal with issues?

HB: In XML, we handled about 10 issues a week.

JB: Need to take time at end of a meeting to
summarize "where we are". Need telecons
to discuss resolutions.

CO: Need to translate issue to guideline. I think
that's the Chair's job. Prioritizing them
is another process.

/* End of meeting */