W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > October to December 1998

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

From: Ian Jacobs <ij@w3.org>
Date: Fri, 11 Dec 1998 21:18:28 -0500
Message-ID: <3671D274.E69F08AF@w3.org>
To: w3c-wai-ua@w3.org
WAI UA WG Face to Face
Cambridge, MA
11 December 1998

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

Olivier Borius (OB)
David Clark (DC)
Chuck Hitchcock (CH)
Jutta Treviranus (JT)
Kathy Hewitt (KH)
Daniel Dardailler (DD)
Glen Gordon (GG)
Bill Kilroy (BK)
Wilson Craig (WC)
Marja (MK)
Charles (CMN)
Denis Anson (DA)
Tom Wlodkowski (TL)
Chuck Oppermann (CO)
Harvey Bingham (HB)
Wendy Chisholm (WAC)
Markku Hakkinen (MH)
Judy Brewer (JB)

Agenda: http://www.w3.org/WAI/UA/1998/12/wai-ua-f2f-information

WC: Where are companies like Henter-Joyce being represented
in the guidelines? 

JG: Early on, the concept of independent vs. dependent user
agents. What should each type support.

DD: Prefer the distinction between "mainstream" and
"specialized". We should put most of our efforts into
ensuring the accessibility of mainstream browsers.
Specialized user agents already know what to do
(it's their bread and butter).

WC: There are inherent conflicts in defining both
assistive tech vendors and mainstream browsers as
user agents. 

DA: Does it make sense to say that the user agent
does the rendering and to say that the assistive
technology controls the user agent.

DC: Not always about providing the information,
but about providing the hooks so that assistive
techs can provide the information.

DA: Things that provide access to the rendered
information are assistive technologies. 

JT: Talking about rendering muddies the waters.
I prefer dependent/independent definitions.

IJ: Editors introduced distinction, but haven't
developed it sufficiently.

WC: Fix 1.1 (where terms used inconsistently).

DD: To me, Jaws or Webspeak are independent because they
have a knowledge of the markup. It's an implementation
detail that they don't parse themselves.

JT: I don't think the analogy is quite correct. 

CMN: We all know what we mean, and we want to use
the concept in the guidelines, but don't have a neatly
worded definition yet. 

CO: I like Glen's characterization the best. Assistive
technology sits on UA and provides access to it. How
it does it is irrelevant. Doesn't include PWWebspeak
because they can take care of themselves. Any screen
reader has to rely on underlying technology that
the user may or may not have. PWWebspeak provides
that technology (though it uses the IE renderer). But
PWWebspeak is a self-contained application. 

DD: There are two axes: mainstream vs. specialized
and dependent/independent.

JG: How can an agency claim conformance to these
guidelines? Perhaps specialized browsers would claim
conformance in a different way than mainstream

CO: This group not formed because we had a lot
of complaints about PWWebspeak.

DC: So what is our audience. What are they comfortable
with and what do they need?

DD: I agree with both Jon and Chuck. Why don't we
say up front that our primary audience is mainstream
browsers. Apply, of course, also to specialized
user agents.

JT: Guidelines may also be a blueprint for how
all types of user agents will communicate (interface).
Therefore important to define who's who and what
communication takes place.

DA: Significant different between mainstream browsers
and specialized. The guidelines should help UAs
be as mainstream as possible. 

CMN: Worries me to think that some browsers can be
used by everybody and some cannot.

JG: Need to identify classes of UAs so that we can
define requirements and responsibilities. Need to
formulate appropriate strategies and educate

/* Conformance */

IJ: Proposes a conformance in which 
  1) Conformance to three sets (Pri 1/2/3)

DA: I like the proposal that Ian doesn't like.
  1) Conformance to all Pri 1 first.

CO: Compliance important
  1) Techniques for developers
  2) Comply to guidelines
  Possibly conflicting goals.
  Concept of priority (if it were up to me). Either
  "required" or "recommended" (two priorities rather
  than three). You either do it or
  you don't. Give people notice by making a recommendation
  first, then a requirement later.
  I also advocate a series of WAI documents (say, every
  18 months).

KH: Define conformance in terms of Priority one items.
  They need to be relevant to industry. The document
  became unuseful. (Lots of priority ones, wasn't
  sure why so many Pri 1). Would think that the guidelines
  would be more of a bell curve: small set Pri 1, lots
  of Pri 2, fewer Pri 3. Need to be more careful about
  what we label Pri 1.

<span class="action">Action KH:</span> Send comments to list.</span>

CMN: One problem with the recommendation-to-required
  track is that this document is meant to address
  problems now. Document should say "You must do this."
  Whether now or later, it still must be done. It's 
  important now.

DD: Not just an issue of priorities. A lot list of
  Pri 1 may mean that the granularity has to change.

  I agree with CMN in theory. But there is also the
  market and the implementation has to be part of the
  loop. Guidelines can't be wildest dreams.

CO: We need techniques to be as specific as possible
  (lots of techniques ok, useful to developers).
  Want to be told which attributes of HTML need to
  be supported. Not just support HTML 4.0.

  (to CMN:) Technology changes. What may be a problem
  now may not be a problem in the future. "Don't use
  tables" may be true now, but in the future, may
  not be a problem.

IJ: Discussion of distinction between techniques
   in guidelines document vs. elaboration of
   techniques in techniques document. Conformance
   with respect to normative list of techniques
   as expressed in the guidelines document.

DC: Back to question of dependent/independent. Must
   describe Pri 1 techniques in terms of "alone" or
   "in conjunction with" other technologies.

CO: Apply priorities to problems, not solutions.
  That does not discount the fact that there are
  better ways than others to accomplish certain

DC: Want to avoid reverse engineering to get
  the job done. Don't want to force impractical

DA: Hook must be provided, but hook must also
  be used.

JG: W3C must educate so that developers are aware
  of these hooks.

WAC: Back to conformance...Have these discussions
  happened in other groups.

KH: (referring to DA's comment): Native vs. 
Assistive support. If we provide hooks, we've done
our jobs.

GG: Mainstream browsers may not do the right thing
for users. Not through fault of their own. Right
thing may not be clear. 

DD: Some people may not have opportunity to
get the technology.

IJ: Economics, bandwidth, platform, ...

CO: Cross-disability benefits of assistive
technologies. E.g., multiple table renderings could benefit
a wider audience.

JG: Summarizing
 1) Who's the audience for the document? Industry developers
    but also consumer groups (purchasing products that
    conform to guidelines).
 2) Pri 1's are most important for conformance.
    <span class="resolved">Resolved</span>: 
    Compliance/Conformance will be to
    Priority 1 techniques as expressed in the guidelines
    document. There is further work to establish
    what class of user agent must conform to which
    of those techniques.

    Add note: Guidelines are the goals. May be other
    ways to meet them, but these are the techniques
    chosen by this WG. In other words, you don't
    conform to "Accessibility", you conform to the

    <span class="action">Action editors:</span> Draft exact
    wording of this conformance statement.

    Microsoft agrees with reservations and waits to review
    pending proposal.

    JT (Chair of AU WG): Sounds good.
    WAC (Editor of PAGL): Sounds good.
    DC: Writing a spec and defining the bar
     for passing the spec are distinct.

    CO (to Denis): Difficult to say "We comply with
    a technique" since we may not agree with it or
    think we can do it better. (Comparison iwth
    Windows Logo guidelines). How do we identify
    the problems and fix them?

    JT: Is the word "technique" appropriate? Perhaps
    too strongly implies "how". Would "demonstrable
    outcome" be better? 

  3) We need to ensure that industry concerns 
     remain in the loop of decision-making.

DC: You can't design for all people. Trying to
  accomplish something for one group may
  contradict with the needs of another.


Accessible design principles and practices.

Technique 3.1.1: 

CMN: Change wording to "available through control
mechanisms that are not device-dependent."

DA: What if they use third-party assistive techs?
Does this count.

IJ: Recognizes that "all functionalities" is big.

KH: Please underline that access to a button
not important, but the functionality offered
by the UA is available.

CO: 3.1 Collapse all three.

IJ: 3.1.3 important on its own

IJ: "general principles of design" is vague.

CO: So is "is accessible".

DC: 3.1.2 raises an issue mentioned at the last
face-to-face. I'd like to see more about mnemonic
or simplistic or logical aids. These techniques
are oriented toward visual disabilities and we
must also consider cognitive as well. I also 
think it contradicts 3.1.1

WAC: What worries me about 3.1.1 is that the functionalities
must be <strong>readily available</strong>, not just
available. Customization is important and I should
be able to customize for all functionalities.

DA: Must be functionally accessible as well as
  just accessible.

KH: I agree in theory with the comment about "readily
  available" (you don't want to have to go through
  5 submenus). 

IJ: Users must be able to customize their environment.
    Also must have access to all functionality. Together,
    you get what you want.

DA: 3.1.3. Installation procedure must have equivalent
   accessibility as the application.
CMN: The installation procedure is part of the UA
and therefore are subject to the guidelines.

IJ: Is 3.1.2 useful?

DC: Strike it. Covered in 3.1.1

WAC: Part of 3.1.2 is:
   1) Use standard platform toolkits (so that
       screen readers pick up).
   2) Accessibility API.

CO: Why should standard platform toolkit be used?
DD: Use platform toolkits (which may be made
 accessible) for consistency.

WAC (modifying): Whatever tool you use, when you paint text,
it should be painted as text, not an image.

JT: Point Wendy making is that there are a lot of
 things not covered in 3.1.2 (including her point
 above). Standards will improve accessibility.

CO: Re "how text is drawn". Lowest level: pixels
   drawn. Higher level - glyph (still an image). 
   Higher level -index to glyph. Higher level - 
   Unicode reference. Always an image. Applications
   are starting to paint their own image, bypassing
   OS hooks. Difficult to define "how text is drawn".
   It's a moving target. 

   This is a very difficult problem: making a user
   interface and one that's accessible. Not the goal
   of this group (making content accessible). There
   are plenty of good references about how to make
   an interface accessible.

   Don't ignore the issue, just don't want to spent
   a lot of time on this issue. Use platform guidelines.
   Let's worry about HTML-specific issues.

CMN: Technique 3.1.2 circular with guideline.

WAC: The principles exist out there and we need
  to point to them obviously.

IJ: Careful - AU Guidelines will be referring to
 this document and how to make UA interface accessible.

WAC: We also refer to UAs in the PAGL.

/* Break */   
3.4 Provide documentation about accessibility features.

Ian: Comment about "is accessible" again. What does
"is accessbile".

WAC: Should this be in a central reference document?

JB: Two things we're planning: 
 1) Need for common definitions for all three documents
 2) Need for assistive technology document. (Publish
    as a W3C NOTE)

DC: In this particular instance, "alternative formats"
    would be more appropriate than "is accessible".

CMN: I don't agree.

DD: For 3.4 (1, 2, 3). Clarify online "product"

DA: For many products, the HOWTO install must be
 accessible before the software itself is installed.

IJ: "is accessible" used rather than refer to
specific formats or renderings.

GG: Comments refer to application as well as 
installation. Define as one unit up front.

CO: This is not an HTML issue, but a general
 application issue.
HB: Is there a convention that we could live
with (e.g., a README file). Appropriate for
UAs to depend on a simple text format.

IJ: Both documentation and installation are
important entry points and should be in the document.

JB: People frustrated that features not more
readily available, even if they exist in
a tool. People not very good at finding that

CW: Jaws installation - if all you have to do
   to install is put your CD in and hit enter,
   a braille one-liner. 

JG: Is there consensus that the techniques in 3.4
cover the issue adequately. 

HB: Time element. Installation is a one-time event.
Day to day use and accessibility in those scenarios
a very different thing.

TW: 3.4.4 is a priority 2. I have concerns about
that based on the education project we're working
with. Teachers deal with a lot of users, some
more savvy than others. This should be a priority 1.

DA: Look at the definitions of Pri 1 vs. Pri 2. If
someone shows you the features (even though you
don't read the documentation), you can still use
the features. Therefore should be a Pri 2.

TW: Problem with educators is that they don't know
about these features. And their students don't.
Too many people don't know someone who can
show them the features.

KH: I agree with Denis. Shouldn't the education role
  be carried out by the EO WG? Difficult to go
  into a class of functionalities and ask what meets
  an accessibility concern. There may be things users
  use to meet their needs that we might not think
  of immediately as "accessibility features".

Marja: Following reasoning of "someone else could do
it", all the techniques could be Priority 2. 
Very useful to provide scenarios (e.g., for blind
users). Show how features used in combination.

DD: How do we define accessibility feature. Is it
a view of the documentation or a separate part of
the document.

CMN: To follow up on DD - If your documentation is
incomplete, the tool is inaccessible. If complete,
but poor quality, doesn't mean inaccessible (just
poor). Telling people how to organize their
documentation is a hairy issue. Should be Priority 2.

MH: There needs to be some general scenarios about
how the tool can be used (whether or not you
have a disability). This would be very helpful.

IJ: Suggest integrating accessibility comments throughout
  documentation, but this would be a recommendation.
  Realistically, need to provide a separate section that
  gives a few of the most important entry points.

DC: We shouldn't make the decision about integration
or separation. Just to make the information readily
available. For 3.4.4 - don't talk about "a section,"
just readily available.

JB: HTML 4.0 different than a UA. Helpful in HTML 4.0
to sprinkle references. For a UA, however, very
useful to have a separate section. Readily available
is most important.

DA: Recall definition of Priority 1. Documentation
is a "difficult" issue, not impossible.

Section 3.5

How to let people know there are keyboard commands

CO: How is 3.5.1 different from 3.4.4?

JG: Former is specific instance of latter.

IJ: Highlight keyboard access since so important.

DA: Providing shortcuts in a menu may not be
so useful if you can't get to menu.

IJ: Use OS standard mechanisms.

Section 6.2

Use and provide accessible interfaces to
other technologies.

CMN: Techniques that begin "Otherwise" feel
like they should be collapsed.

IJ: Propose collapsing 6.2.2, 3, 4.

CO: 6.2.1 same as 6.2.5 (or could be made).
CO: 6.2.4 Pet peeve. Define "standard". Propose
  revise "use operating system-provided interfaces".

DD: Bugs in 6.2.3 wording.

/* Ian: move 6.2.2 to top of list */

Section 3.2

CMN: 3.2.1 and 3.2.2 are potentially in conflict.
What if conventions are inaccessible. Propose
mergining into one sensisble technique.

DC: (from on high of soap box): Don't forget
cognitive issues. 

JG: "mouse-only" to "device-independent".

IJ: "Wheverever possible". Fuzzy. Remove where
 possible, or enumerate.

DC: Command-line only interface would probably
be inaccessible in the broader scheme.

CO: 3.2.1 and 3.2.2 covered in 3.1. 

CO: 3.2.3. Microsoft has strong 
           disagreement with priority of that.

CO: 3.2.4. Good idea. Add comment - use the
platform-provided mechanism if available.

JB: Don't think 3.2.3 should be Priority 1.

CO: 3.2.5 
 We have a "restore defaults" button. This doesn't
 allow you to switch back and forth. Your settings
 are gone. Not too many applications let you do this.

CMN: Push 3.2.1 and 3.2.2 covered by 3.1. 3.2.3 could
 be broadened to allow users to configure control
 of the browser (Pri 1). More general than keyboard
 access. 3.2.5 is a Pri 3. Won't be strung up for
 not doing it. Don't see a reason for taking it out.

CO: Does "restore defaults" count for 3.2.5?

CMN: Not entirely.

DA: Microsoft's OS itself lets you do 3.2.5.

CO: Add to 3.2.5 "allow this by logging in as
 a separate user".

DC: Accessible command keys. 3.2.3 should be Pri 2.

CMN: Allowing reconfiguation of controls seems
a general high priority featured.
3.2.5-7 seem candidates to be collapsed.

/* Will discuss with editors off line */

CO: If the developer will do something different,
should be a different technique. When pieces
are included, push them into guidelines.

DA: If this section of the document is the only
place where keyboard controls are discussed,
must be priority 1. If discussed elsewhere more
specifically, could be pri 2 here.

CO: The ability to configure keyboard access for
every application is a worthy feature. Don't think
should be priority 1 technique since it doesn't
prevent access. Few people yelling at MS "Can't
use your browser since I can't remap the keys."

JB: Few cases where inability to remap would 
make access impossible.

CO: This is Bryan Campbell's big issue. He's a big advocate
of the ability to remap and we've discussed extensively.

JB: Chair, how do we proceed to establish the priority

<span class="action">Action CMN, CO, KH, DA:</span> Will
reexamine priority of 3.2.3.

Section 3.3

IJ: "equivalent textual representation" means "captions".
 Does this mean "alt text" as well? How to explain what
 this means to novice readers?

CH: Please clarify whether "equivalent textual
representation" also means "alt text".

<span class="action">Action editors:</span> Clear this

/* CO discusses rendering of dimensions of alt text
   vs dimensions of image */

WAC 3.3.7: Generalize scripts to programmatic objects
and include applets.

CO: In addition to scripts, add techniques related
to the loading and execution of embedded objects.

IJ: The definition of "programmatic objects" is

GG: Is the browser obligated to tell the server
 that it's not capable of loading the objects.

DD: Not an issue.

DD: 3.3.9. How is this different from 4.1.14.

IJ: Rendering different from ability to turn on/off.

WAC: Suggest referring to related techniques.

  3.3.2: Define "video". A lot done through embedded
   objects. The UA may not be aware of what's happening.
   In the case of animations, the UA is aware of this.
   (3.3.5, 3.3.6).
  3.3.3: UA not available of what's going on in an OBJECT.

MH: I have the same comment. From the user's perspective,
    animated gifs, etc. all considered "video". I want
    to turn off "moving stuff".

DC: Goes back to independent vs. dependent UAs. This
    is a guideline for dependent UAs.

DD: Qualify all of these with "when the user agent knows".
   Also, if you can turn off embedded content (3.3.7)  
   you accomplish the goal of turning of video effects.

IJ: Proposed: "Where knows" and give details in 
  techniques document (e.g., bgsound).

CMN: Version 2 of IE has menus "Play sounds", "Play

WAC: Knowledge about object types through MIME types.

IJ: That goes in the techniques document.

WAC: Propose "blinking, moving, or changing" content.

CO: 3.3.4. Does this include alt text? (see above)
    3.3.5. Make into "animated and blinking text".
    3.3.8. On/Off support for style sheets. Need
           to separate support for author and user
           style sheets. Don't think turning off
           is a priority 1.
    3.3.9. This is a rendering issue. Disagree with
           Priority and placement.

/* Lunch */

HB: Should turn/off be all or nothing? Would like
   to turn off images generally, but select one
   and view it. Add this to intro of section 3.3

DC: That would be a P2. 

DA: Features may interfere with "or enhance" (add this)
JG: Distinguish user from author style sheets.

WAC: 3.3.8 should be Pri 1 since style sheets can
do crazy things.

DC: Not a given who has final control (user or author).
Priority 1 is that user have final say.

DD: There are things you cannot change with a user style
  sheet but that you can turn off, e.g., with a button.
  E.g., knowing which property I've used to achieve
  a certain effect may not be obvious.

KH: Did some investigation about this for IE 5 and
  became clear that this is not a simple problem.
  E.g., positioning. If I turn off positioning when
  there are layering effects, what happens?

WAC: IE3 used to allow turn on/off. Netscape allows
you to do it. It's possible. Positioning without
style sheets means use document order.

IJ: UA shouldn't be responsible for choosing a
"next best rendering". Should just render in
document order in general case.

KH: What problem is solved by 3.3.9? Assistive techs
are solving the problem quite adequately.

JB: A lot of discussion about this at "Closing the
Gap". If you are using a screen reader, frame issues
may be solved by a screen reader.

WAC: Small screen issue. Learning disability problems
as well.

KH: I can understand cognitive issue. Mobility issue
solved with navigation. What is it priority 1?

MH: How do access keys interact with different frames?
  Can't access navbar type frame when focus in a separate

KH: Haven't tried this out.

/* Discussion postponed until CO returns */

JG: For 4.1, change to "override author styles
and adjust user agent defaults".

DA: If you use that language, would that mean that
using the "return to default settings" mean factory

IJ: "Default values" means the value when the UA
starts. Want to be able to change that dynamically,
without changing default value. (e.g., Using 27 point
font currently for the purposes of a projector,
but want 8point when I start up emacs tomorrow in
the office). Don't agree that should be "adjust"
UA defaults. 

DC: Change by profile?

CNM: Profiles are Pri 3 currently.

4.1.5/6: Change "foreground and background color" to
 "presentation" (e.g., could use underlining, different
  voice quality, background music, etc.)

CO: That's a big request. Configurability of the focus
   rectangle is a big request we get. Can use CSS
   to accomplish the goal of changing focus. /* Ian
   proposes discussing this in the techniques document */

   Propose separating techniques for different

DC: Make media independent.

<span class="action">Action Editors:</span> Propose
wording that is slightly more general, but doesn't
bind UAs for media types not supported. Move specific
examples to techniques document.

Re: 4.1.7 Is there a need to control background
images? Doesn't the ability to turn on/off background

Resolved: Add to 3.3 turn on/off background images
and remove from 4.1.

Marja: What's the fallback presentation?

CO: Good question! Rules as I understand them:
1) if no background image, is it set in HTML?
2) if set in CSS, use that.
3) otherwise use OS background color. This may
   be overridden.

DA: Foreground and background imaging must be 

JT: Whatever is done to establish background color,
    is this covered in the spec?

JG: Yes.

DA: 4.1.8. Users may want to control rate of
animation to have access to the information (and
not just turn on and off).

CO: I've spoken with several programmers about this.
In case of animated GIF, UAs know rate, can scale and
stop it. Changing frame rate not a Pri 1. Stopping
would be a Pri 1.

DC: Not sure I agree. If showing the action is
critical to getting the content, turning off
alone doesn't suffice. Information must be
conveyed elsewhere.

CO: I agree. Important, but not a must. Billboards,
for example that change quickly. 

WAC: For ads, I agree. But for information critical
to understanding (e.g., how to tie a bow-tie), I think
it should be a priority one.

DA: One of the applications of animations is to 
demonstrate processes. If the object is embedded,
the mainstream browser may not need to provide
the control. But the functionality must exist.

IJ: Proposed clarification: "When the UA knows
how to access the animation rate for an
object." (to 4.1.8).

CO: We're working on adding a metric related to
"reading rate".

IJ proposal:
  2) Add wording that control by rendering agent
  3) Add wording that control when UA has access
     to those particular properties of the object.

  1) Is animation rate the only issue?
     GH: People will need to start and stop
         as well.
     CO: Pause. Start means from beginning.
     HB: Need to be able to backup a little as well.

     CO: Proposed user interface for animations: allow
     tabbing to animations. Use keys to control
     animation. Also could have vcr-style controls
     (speed up, slow down).

     MH: How do users know what's what and what rules
     apply to different types of objects.

     DC: I think we're going too far down the 
     implementation path. Just allow users to have
     final control over active media objects.

     CO: That's a problem regardless today. 

     MH: The issue is consistency of controls. 
     Vcr-controls exist for other types of objects.

     DC: Is consistency covered by referring to
     OS standards?

     CO: Possibly. But real-audio may not use the
     same keys.

     <span class="action">Action editors:</span>
     Propose wording about (1) per image control
     [what priority] and global control [what priority]
     (2) control of rate Pri 1 (3) control of
     start, stop, pause, continue priority 2 (4)
     support by rendering agent.

     DA: Consistent controls would be a priority
     2 concern, not priority 1 in any case.

     IJ: Seems outside the scope of this group.

     DC: Careful about choosing priorities. Certain
     groups, but not others, may benefit/suffer due
     to priority choices.

Same issues apply to 4.1.9 as to 4.1.8.

Do same issues apply to audio issues?

WAC: For 4.1.12 change "a specific" to "among available

CMN: The user agent is the one rendering the information.

MH: Yes, but from the user's perspective, you share
the same view. Need consistency across media types.
HB: Should the user profile include information about
what users never want.

DA: Don't want to have to turn off styles when
racing against a seizure.

CO: 4.1.10 will be changed to include "when UA aware
of rate".

/* Note: CSS2 may be used to specify volume */

CO: Why is control of volume priority 1?

DA: Use the external volume control. 

JB: Not all boxes have a manual volume control.

CO: Shouldn't be a priority 1 since other ways
to get at content.

DA: The information would not be available to
   some groups.

CO: 4.1.12: Should be stricken.

CMN: 4.1.13 Need also to control pitch/tone. This is a CSS2
property as well.

CO: Is supporting "CSS2 aural" a priority 1?

CMN: If you're not using CSS to control them, but
still rendering speech, still need to provide
a means to control.

DC: Rendering agent is the entity that must be 

CO: Put in 4.1 : Here are the techniques for these
things. If you support these things, do them. 
Otherwise, don't have to.

IJ: We say that in techniques document.

CH: About speech. What does "support" for speech
mean? Rendering? Highlighting? Text to speech?

CO: "SAPI" is MS's speech API.

CH: What's the UA in this case?

CO: The browser is not aware of some of the things
going on.

MH: I'll speak for the UA... want to
be able to speed up, slow down, etc. But need
to be clear about recorded speech or synthesized
speech. Affects what you need to eo.

CMN: If call it techniques for automatically generated
speech, where browser is creating speech, and you want rate,
volumn, and pitch control, could put it into techniques for
rendered audio. Would provide the clarity.

DA: If talking about recorded speech, that's just audio.
Then could do pitch maintenance by audio playback.

MH: with pitch rendering

HB: user profiles may need to pass info to UA.

CO: I would shy away from profiles. Platforms should support
these things. These are cross-component issues.
Info should be sharable.

Proposed: Be able to change the pitch
of audio files. What priority?

JT: Would this exclude a group?

JB: Yes, e.g., those hard of hearing.

CO: I recognize its importance. But should it
be a priority 1.

WAC: Issue of captions again. Can't assume that
they will be provided. Will be helpful and
necessary if captions not provided.

DA: Recall that priorities not based on number
of people but on locking people at.

JB: You're locking out (1) aging population
(vision + hearing loss) and (2) deaf/blind
community with range loss. Yes, I believe it
locks some groups out.

CO: Each decision will lock out some community.
Have to make decision about benefitting greatest
number of users as well.

DD: Not all techniques are related to media perception.
Some are related to convenience, etc. So not true
that all would become Priority 1.

JB: Multimedia is a difficult area for the growing
Web. Also an area with not as much advocacy
from different groups. 

/* Where did 4.1.15 and 4.1.16 come from?
   IJ: Paul A. / Scott L */

CO: Several issues
    1) Need to control window size based on user need
    2) Need to control window position based on user need
   Should allow users to turn off automatically spawned

WAC: PAGL says don't use popup windows. But also relies
on UAs in the future to warn users.

DD: I consider 4.1.15/4.1.16 to belong more to the
section on the user interface. Distinguish that
which happens due to HTML from that which happens
due to interface (e.g., warning). How do you
warn users that a window will pop up? By popping
up a window?

CO: This is also a security issue. I want an option
that says "prompt me" when new windows are requested.
  Tech 1: Turn off entirely
  Tech 2: Prompt before.

Windows pop up all the time. UAs have to deal with them.
Don't make this a Priority 1 unless we tell vendors
of other applications to do this as well.

MK: Any way for UA to know which windows are available?

CMN: No "windows" menu as in Word.

CO: If a new windows popup, a few things happen
  a) Programmatic things happen. Screen readers have
     access to that information.
  b) In windows, you get info somewhere in the environment.

GG: I basically agree with CO assuming there's
an accessibility aid available. But if not, problem
not addressed.

CMN: Propose Pri 2 to 4.1.15/16. Also shift to section

CO: Proposed interface: Allow/Don't allow/Prompt.
Don't know that we would allow resizable.

CO: Spawning windows part of Javascript environment.
What can one do?

CMN: You can disable resize, scroll, etc.

DD: Style guide should say "If you press a button,
a dialog will appear". There's a convention in the
way menus are displayed to give clues to the user.
In HTML, value of "_blank" for the "target" attribute
means UA might open a new window. 

IJ: Add to techniques document - for target="_blank" UA
should inform the user according to the user's

JT: One reason windows are annoying is for people
with visual/cognitive limitations. Not necessarily
that they don't want them, just that they don't
want to be disoriented by them.

JB: These are not usability guidelines. These
are accessibility guidelines.

CO: Another real-world example - HTML in email
messages. Your browser is started up and
disorients as well.

IJ: How much should "usability" and "accessibility"
be mixed?

JB: Procurement requirements ususally based
on accessibility needs, not usability. 

/* Break 3pm  */

/* Daniel on minutes */

Table issues: please consult 9 Dec minutes.

JG: Issue is relationship to screen reader (read cross col)
    Issue also with Table used as layout tool
    2 kinds of Table: layout, tabular 
    Different levels of linearization are possible
    (based on presence of markup or not, kind of table)
    If not done native in the browser, the assistive
    technology can use an API to implement it (DOM, DHTML,
    MSAA). But APIs are not yet standard across browsers

CMN: Can also use CSS positioning

JG: Another concept relevant to table navigation is the
    point of regard. People want to move up and down,
    row or col, switch directions, etc.

IJ: Users want cell level access: reformating and navigation 
    are two ways of doing that. That's P1. More navigation
    improves contextual access (where you are, what column
    header is relevant). The goal is to define level of
    table access to prioritize and decide what's done
    natively or not.
DA: Surrounding information is more than header.

IJ: linearization is not the only way.

DA: linearization is sometimes not approriate (Statistics
    data for instance)

CO: Keyboard Navigation not the ideal solution
GG: Given the bits on the screen, wants the information
    in the structure, and the other way
IJ: mapping backward harder (DOM people working on it)
CO: Going from x,y to the element was added in DHTML.

MH: looking at daisy book, it's not just for table, need
    information of navigation significence.

DA: Navigation long table/document thru element is not
    adequate, you need to be able to go thru larger chunk.

IJ: lots of navigation schema in the guidelines:
    hierarchical, thru list, by link, etc. Not eveything is
    there , but there's lot.

DA: May want to navigate arbitrary element.

MH: in webspeak, we added the ability thru preference to
    declare which elements are navigable (maybe done thru
    some style sheet syntax)

JG: one question is what AT wants
DC: Search functionality gives an example of things where
    the browser 

DA: both cell rendering and and cell context information are
    vital, regardless how it's done.

CO: Some screen readers use API to provide cell by cell

IJ: still want to push the most important thing: individual
    cell information rendered as block, which sounds easy
    and already supported in the code.

CO: don't want to say it's easy when talking about about
    new development. 

IJ: CSS1 supports block display on all element
CO: maybe already solved
IJ: implementation question, not guidelines

DD: Jaws does table unrolling because IE doesn't do it

JB: how many screen readers do table unrolling

JG: overall, what strategy will solve accessibility the best
    way: done by browser or done by AT ?

WAC: IE Powertool is an in-between approach that works fine.

JG: similar to running a user script on load that would
    improve the layout

DA: issue of who would write the scripts
JG: WAI may help?

CH: I favor nagivation and native linearization thru simple
    user action

GG: like the idea of running script doing linearization
    that user or AT could fire.

JT: responsibility is shared between browser and AT

CO: maybe have two different techniques: P1 make cell
    information available, P2: Provide this information
    natively and possibly navigation as well.

JT: General navigation issue: Keyboard-based selection
  of anything in an HTML doc that isn't a link/active

/* Ian on minutes */

DD: CSS has the 'display' property with 'block' value.  From
the CSS2 spec: "Conforming HTML user agents may ignore the
'display' property." In the WAI guidelines, we could make it
a (Pri 1) requirement. Thus, for table linearization,
simple application of CSS.

CO: CSS is always a great way to implement stuff.

CO: Re selection copying. We get this request all the
time. Two ways: 1) Search for particular text. 
2) Save page as text file, open in text editor
to use selection copy.

MH: Word 97 has feature on scrollbar to allow
navigation by element.

DA: Point of highlighting text is not to retype it.
If you have to copy to find box to highlight and
then to copy is pointless.

/* On W3C post-REC support */

1) For WAI in general, there has always been
a recognition of the need for promotion and
encouragement of implementations based on
accessibility improvements. WAI IPO set
up for this reason, among others.

2) At W3C in general, movement to improve 
post-Recommendation follow-up and promotion.
Historically, advocacy done by other organizations.
But now W3C management feels the need to
support "life after Rec". In particular, the CSS
Working Group has pushed hard by creating
(or monitoring the creation of)  test suites,
validation tools, etc. the SYMM WG is in a similar
position of monitoring support.

JG: Would WAI be responsible for educating assistive
technology developers?

JB: Could be part of WAI's responsibility. Also
push to have assistive technologies move towards
standardization of interfaces.

CO: Agree that our job would be easier if there
were standard interfaces to plug into. What more is

JB: Not everyone uses Windows. To answer Jon's
question, yes, could fit into WAI's scope. However,
not only WAI's responsibility.

CO: There are similar standards on Unix/Apple systems, but
few tools that require it.

JG: Provide code for platforms.

JB: It could be well within WAI's scope to educate
developers for important accessibility issues. We
don't have the ability or role to enforce. The WG
must bear that in mind when writing the guidelines.
No guarantee from W3C to enforce.

CO: Lack of participation from other browser manufacturers
is indicative of the uphill battle.

DC: Must be as frugal as possible with our priority
1s. We have to be realistic if we want these guidelines

CO: Discussion on the IG list lately about the PAGL
being too much.

HB: Any time a Pri 1 shows up. How do we justify it?

JB: At WAI EO WG meeting this morning, discussion about
the "AIEE, it's huge!" thread on the mailing list.
Upshot of discussion in that group: the stuff in the PAGL
needs to be there. The detail needs to be there. The
PAGL WG used to have a checklist and this would be
valuable again. We want the content, but need different
ways to slice it.

KH: My personal opinion that the guidelines represent
a wish list more than industry reality. Would like
to reduce number of Priority 1 items. If Pri 1, should
a tech be native if affects a large number of users?
No one wants "all the stuff" pushed on them, either
mainstream browsers or assistive techs.

DC: Laws vs. Regulation. We're doing regulation without
  defining the basic laws. If we come up with the laws
  that have to be met ...

JB: I'm concerned about the analogy you're proposing.
This is not a legal or regulatory environment. This
is a voluntary, consensus-based WG.

IJ: Not "wish list" but expression of accessibility
requirements. Industry concerns are built-in by
virtue of this discussion.

DA: I agree with DC that we must be frugal with
our Priority 1s. But don't want to fall into the
trap of "easy vs. hard." The issue is "accessible
vs. inaccessible".

JB: I too like "Frugal with Priority 1". We've been
talking about screen readers a lot, but there
are other disabilities involved that would not
have screen readers.

CO: Process questions
 1) Yes, this WG should be collecting, validating,
  and quantifying data. And then working with developers
  saying "here's the wish list, what's practical?" 
  "If you don't this, you're impacting this set of people."
  Look at 5.1.3.: Provide user with info about number of
  tables in a document.

  JB: If we create a wish list first and browser
      manufacturers say what's practical, then browser
      manufacturers could say "zero", and others will 

  IJ: Describes how stuff gets in the document. Editors
      take what shows up on the list. WG is responsible
      for reviewing the document. Editors do the best
      they can to glean information and proposed text
      from the list. And we announce changes at publication.

  CO: What's happened is that someone says something and
      it goes into the document.

  DA: As part of the WG, you can say "I don't think
      that should be a priority 1 technique" and start
      a dialogue about how people or groups of people
      might be shut out.

  JB: If an item comes in from the list is it automatically
      a priority 1?
  IJ: No. It may be if similar techniques are rated that
  JB: This process is *not* clean and easy. The result
      should be a list of requirements that are realistic.
      Life gets harder towards the end of the document.
      The WG cannot put off the prioritization of the
      techniques any longer.

  JG: Do we have the techniques that we want?

  JG: We've talked about tables and navigation. How
      would we rewrite guidelines?
  IJ: Providing "cell level info" is not enough. It's
      just part of the document like any other piece.

  DC: Is our purpose to provide a developer checklist
      or to have general working premisses we want
      followed. I say this because the last draft
      too ambiguous and we decided we wanted it more
      broken out since that would make it more quantifiable.
      Now, broken out, people are protesting it's too
      specific (or long). This indicates we have opposite
      and conflicting goals.

  JT: We had the same discussion in the AU group. We
      shouldn't be too draconian to allow vendors to
      distinguish their products. We should say that
      this is what we need and why we want it. We will
      know that you've met this need if this happens.

  JG: How do we do this for tables?

  CO: Three levels

   1) Requirements gathering and prioritization.
      WG solicits input, does usability studies. Gets
      input about what problems exist. This WG presents
      some information that I don't hear from users.

   2) Potential solutions and triage of requirements
      Work with developers here.

   3) Actual solutions
      This is announced in developer press releases
      after the product comes out.
   I think the WG doesn't work enough at Level 1. The
   goal of the WG is to produce a document at Level 2.

     1) Pri 1: Access to table information
     2) Pri 2: Unrolling of tables

   IJ: Chuck, why didn't we hear the requirements that
    you've gleaned. 

    1) Lack of time
    2) Discouragement because ideas have been booed down.
       In general, chorus of boos when MS makes proposals. 
       E.g., my developer says it's hard to unroll 
       tables in code. A limit to how much arguing 
       one wants to do.

   JB: UAGL WG has not been chartered to do usability
       studies (nor has funding). Also, if you have
       your own collection of barriers, please share
       these with the WG.

       Dave made important points about "back and forth"
       editing - more specific to less specific. But
       CO's proposal would slow us down again. I know
       a lot of people would like to finish quickly.

       For tomorrow's discussion, people are encouraged
       to speak to as much detail as possible.

       I think that CO's comments can still be resolved
       with some refocusing of the document. I hope they
       do not reflect complete dissatisfaction with the

       DA: About the ease/difficulty of unrolling tables.
       Distinguish barriers to implementation from 
       barriers to accessibility. Unless you're coding,
       you don't know the barriers to implementation. But
       we can't say "that's not a problem" if people
       don't have access.

       DC: My one concern about the Priority approach
       does not take a cross-section of different 
       disability populations. Focuses on the most vocal
       groups with the largest number of users. That
       concerns me.
       JB: Please note that cross-disability was called
       for last week. Also for people to examine 
       priority levels. I hope we will also get more
       participation out of this.

       JT: Re linearization of tables - The need is
       not linearization.


Received on Friday, 11 December 1998 21:19:22 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:21 UTC