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

Raw minutes of 16 November UAWG face-to-face at AOL

From: Ian Jacobs <ij@w3.org>
Date: Thu, 16 Nov 2000 17:57:41 -0500
Message-ID: <3A146665.B9B5A786@w3.org>
To: w3c-wai-ua@w3.org
Hello,

Minute are available in HTML form [1] and are
quoted below as text.

 -Ian
-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783


               Minutes from 16 November UAWG face-to-face at AOL

   Nearby: [1]Agenda  [2]Meeting page

      [1] http://www.w3.org/WAI/UA/2000/11/ftf-agenda.html
      [2] http://www.w3.org/WAI/UA/2000/11/ua-meeting

Participants

   At AOL: Bijal Shah (Netscape), Debbie Fletter (Accessibility point
   person at AOL), Jon Gunderson (Chair), Denis Anson, Eric Hansen, Rich
   Schwerdtfeger, Al Gilman, Ian Jacobs (Scribe), Harvey Bingham, Scott
   Totman (AOL)

   Phone: David Poehlman, Mickey Quenzer, Jim Allan, Gregory Rosmaita
   (after lunch)

Introduction

   JG: Please note that if we don't have implementation experience, we
   will have to spend time at Candidate Recommendation status

   EH: I would not want the document to get stale in CR for 6 months.

   RS: This is a complex document. Few UAs will conform when the
document
   becomes a Recommendation. If there are really sticky issues, we
should
   push them off to the next version

   AG: A guidelines document is somewhat different from a lower-level
   technical specification. It's not clear that W3C understands how to
   handle guidelines entirely. I think it's ok to have some checkpoints
   be future-looking.

   DA: We need to remember that this document is to promote
   accessibility, and we shouldn't sacrifice accessibility in order to
   get the document out faster.

   JG: If we know about a problem but don't have solutions, we may want
   (in another document) to spend time in CR to get developer input.

   MQ: It is possible to note in the document which issues are important
   but not entirely implemented yet.

Issues

  [3]Issue 321 Equivalency relationships and the wording of checkpoint
2.3

      [3]
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#321

   Refer to [4]email from Al on bindings.

      [4]
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000OctDec/0312.html

   JG: I think there are two things going on in parallel
    1. WCAG says to create, ATAG says help people create them, UAAG says
       make them available
    2. Hierarchical definition track and use of precise language.

   DP: Ascii art as braille is not very helpful

   EH: WCAG requires text equivalents for non-text content. But
generally
   speaking, an equivalency target doesn't have to be accessible.

   AG:
    1. It is critical that user agents implement the format. Talking
       about author's intent is problematic (and how to capture it in
the
       format). We want the user agent to inspect the markup and to
offer
       substitutes. But the user agent needs to give the user the
       ultimate choice.
    2. I think we are in agreement on requirements, but not language.
       There are some cases where polarity is clear (e.g., IMG/alt). But
       in the discussion of equivalence, we are also addressing the case
       (e.g., SMIL), where the "ruling" case is not clear.

   JG: I think in PF they are moving away from specific markup to more
   general solutions that also benefit accessibility.

   EH: I think that some requirements such as making all alternatives
   available (including those that don't have clear accessibility
   imlications such as alternative languages) fall under checkpoint 2.1.
   I think that the definition of equivalency is an assertion about
   accessibility of pairs of content.

   RS: I think the bottom line is text equvalents.

   AG: Because of cases like smil, where the accessibility impact may
not
   be in the markup, if you don't capture the general case in the UAAG,
   you miss the special case of accessibility. I think that alternative
   languages is an accessibility requirement.

   EH: Refer to my comments to the SYMM WG (Member-only?) about needing
   additional markup to identify accessibility content explicitly. If
the
   markup is insufficient, you can't have rationale support for
   accessibility.

   AG: I think that you should make the link to accessibility not in the
   definitions but in the checkpoints or at the guideline level.

   EH: If you unbind the terms from the accessibility implication, the
   WCAG definition of non-text element falls apart. It doesn't handle,
   e.g., ascii art and scripts. These consist of text characters but are
   "non-text elements". So if you define text element as only being
   composed of text characters, you break the WCAG definition. If you
are
   willing to tinker with WCAG language, you can shift the accessibility
   criterion to other definitions or spell it out in the checkpoint.

   AG: Fuzzy definition not a big problem for WCAG because they are
   speaking to the human author. If there were something that the UA had
   to do automatically in software, we would have a problem since the
   definition is not good enough. But we don't have that problem for
   alternatives.

   IJ: But we do for 1.5, for example.

   AG: But then you can talk to authors again (the UA doesn't have to do
   anything).

   RS: We need to be able to have access to the equivalent so that we
can
   render it in other modes. In the UAAG, we have no control over what
   the author did. I think we should refer to WCAG and address the
   problems there.

   DA: I think our problem here is that we are talking about things with
   linguistic content.

   EH: Another way of talking about text elements is that it has a
   quality of "rendering independence". The trimodal approach is not
   totally open, not total independence.

   AG: I think the improvements that we're talking about are good and
   should be in WCAG 2.0. But for UAAG 1.0, you need to move forward.

   EH: I wouldn't use the word "equivalent" however - I would use
another
   term.

   IJ: We already proposed "alternative"

   AG: Check out how ATAG uses "alternative". That should work.

   /* AG notes that people are reading glossary entries as definitions
*/

   IJ: So rationale for broader 2.3:
     * Some languages have inadequate markup
     * Some languages are designed to use more general markup
       (equivalents not just for accessibility)

   Resolved:
     * Broaden 2.3 to include all recognized alternatives. This is
       broader than WCAG requirements to ensure that the user has
access.

   Action IJ, EH, AG: Propose new definitions for terms in question
   (equivalence, text element, etc.)

  [5]Issue 322

      [5]
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#322

   Refer to issue 321.

  [6]Issue 323 Using accessibility APIs rather than standard APIs to
make
  non-W3C based content accessible

      [6]
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#323

   RS: I think you can differentiate standard APIs used for keyboard and
   mouse access to support physical disabilities from the actual
   rendering to the screen (e.g., in the case of Java or vector
   graphics). The accessibility API provides the same information in a
   better format than the output API.

   IJ: Note that 1.2 still helps ATs that use an offscreen model. Be
   careful about removing the requirement to use the standard output
   APIs.

   RS: MSAA and Java are about device-independent access (at the
   component level), access to pre-rendered content. They do not support
   the standard OS features for mobility access - that's the role of the
   application.

   JG: We can split 1.2 into input APIs and output APIs (support for
   higher-level first, otherwise standard output APIs).

   AG: So ATs that don't implement MSAA lose.

   RS: There are cases where MSAA doesn't support all text. They're
   fixing this.

   IJ: Note that in Princeton we explicitly decided to require all
   standard APIs, and suggesting higher-level APIs (not requiring them).

   RS: Only recently did MSAA add access to element content. The Java
   approach: we knew we had to run across several operating systems, so
   we created an API to access text independent of platform. In that
   particular case, you have a solution that is the "only solution" for
   that platform.

   Proposal: Change 1.2 to be "Use accessibility APIs, or if you don't,
   use standard device APIs".

   RS:
     * Use the accessibility APIs for the target platform (e.g., Java,
       Windows, etc.)
     * Where those APIs don't provide access to all content, use the
       standard system APIs for output (e.g., drawing text) or when they
       do not support the system APIs for mobility access. For Java, you
       would have to do this for mobility access features, system
       high-contrast settings, and fonts.
       DA: MSAA doesn't handle mobility access features: sticky keys
       RS: For input: MouseKeys, SerialKeys, StickyKeys, RepeatKeys,
       BounceKeys, ... For output: high-contrast and font size, font
       family.

   AG: There's an issue about the integration of input functionalities
   with output functionalities.

   RS draws a diagram showing input that goes through device-independent
   layer, then system access feature layer. Output goes through system
   access features layer first, then device independent layer.

   RS: UAs must:
     * Not circumvent the standard device-independent later.

   JG: So we are saying:
     * Don't circumvent standard input device APIs.
     * Use accessibility APIs, or std output device APIs where they
don't
       do the job.

   RS: Support accessibility APIs plus the DOM. Where they don't support
   text, use system APIs. Note that lots of people implement the
   accessibility APIs.

   AG: If the UA supports two ways to get at the information, that's
   enough.

   RS: Support system access features (e.g., sticky keys, etc.) [Covered
   by 5.9].

   RS: JDK 1.4, when it comes out, will support all of DOM Level 2.

   AG: Distinguish three classes of API: MSAA/Java (access), DOM, device
   APIs.

   Resolved:
     * Change 1.2 to require implementation of available standard
       accessibility APIs, and where these APIs do not provide required
       functionality (by this document), support standard device APIs.

   AG: Make clear that information available as text must be available
as
   text to the ATs (bits written to the screen don't count). Make the
   text case a clear example.

   IJ: Note that the Note needs to be edited in light of this. And the
   part about not bypassing the standard output API is deleted.

   AG: I think that the fact that the spec supports access to
information
   through both the access level and at the DOM level is part of the
   reasoning why all of the info needn't be available at the device
   level.

   RS: Need to ensure that there's documentation about how to have
access
   to these APIs.

  [7]Issue 324 How do developers interpret the phrase "appropriate for a
task"
  in checkpoint 6.2

      [7]
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#324

   /* Scott Totman arrives */

   IJ: Are we, in effect, requiring all conforming user agents to
   implement one or more W3C specs?

   JG: People can create xml interfaces to documents in formats that are
   not in a w3c format.

   IJ: How do you reduce the instances where UAAG requirements need
   interpretation?

   DP: WCAG requires use of accessible formats. Adobe is trying hard to
   make a user agent that is responsible for rendering their content. I
   think they fall within our purview, but their format may not fall in
   the scope of WCAG.

   RS: Note that the latest release of MSAA doesn't support access to
   tables.

   JG: Recently I was playing with SPSS (a statistics package) and you
   could output the results as HTML. One idea is to require output in at
   least one W3C format.

   IJ: That makes it an authoring tool.

   AG: Is a piece of software that doesn't implement at least one W3C
   spec really a Web app?

   AG: One approach is to say that we don't have enough experience with
   the accessibility process for PDF (e.g., WCAG 1.0 doesn't cover) and
   therefore that shouldn't be our focus today.

   HB: XSLT could be a valid way to get around this, but even after the
   transformation you might have an inaccessible result due to lack of
   information in PDF to begin with.

   RS: We are starting to see formatting objects on the Web...

   AG: I agree with Ian - to what extent can we write this document to
be
   format-independent, and to what extent should it push people to use
   W3C formats. This is a balancing act we are stuck with. I think it's
a
   practical problem that for W3C formats, we have access to the specs
   and it's easier to be clear about general principles. Yes, we'd like
   to write functional requirements to help Adobe promote accessible
   practices, but it's not so clear that we are in a position to write
   general, clear requirements.

   AG: The realities that we're looking at are like APIs: W3C formats
are
   like APIs - they deliver the best engineered solution today for
   accessibility. We should have something in here to promote those
   formats.

   HB: We have problems of W3C Recommendations are in conflict.

   IJ: Note that "available" has some wording around it in techniques
   about implementation schedules.

   AG: You shouldn't have to go to the Techniques document to get this
   information.

   JG:
     * If you use W3C specs, conform to them.
     * If you don't support a W3C format, support an accessible format.

   EH: We could say that we don't have specific criteria for identifying
   what is "appropriate for a task" and leaving as it.

   HB: These specs need to be open.

   IJ: I have a problem saying "accessible spec" since we don't have a
   spec that explains what that means.

   AG: You need the format plus the software. You can say in a Note that
   the developer needs to implement functionalities in the manner of W3C
   specs.

   EH: This reminds me of our discussion about the scope of our repair
   requirements. When you talk about outputting PDF as HTML, that's a
   repair functionality.

   AG: Support format that can conform to WCAG.

   IJ: Issues at stake:
    1. P2: Implement formats that allow WCAG-conformant content
    2. P2: Conform to implemented W3C Recommendations
    3. Note: Support deprecated features (legacy requirements)
       AG: Developers will do this anyway because of user base.
    4. Note: Implement the latest version (improved accessibility, we
       hope) that includes accessibility features.
       RS: Support the version that has the latest accessibility
features
       (which may not be the very latest version of the spec).
    5. Note: Define "available" a little better
       IJ: This seems to come down to time schedules.

   AG:
     * Conform
     * Use w3c formats
     * Use formats that enable wcag-conformant authoring

   Action IJ: Draft new language for 6.2

   /* 12:30 Lunch */

  [8]Issue 325 Checkpoint 5.5: API notification of content change in one
  viewport that causes change in another

      [8]
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#325

   Resolved: This is covered as part of 5.5. Include as a Note or
   technique.

   AG: The example is in the DOM Level 2 Mutation events module.

   JG: MSAA is another example: it sends events to ATs when content
   changes.

   RS: The association between viewports is not part of DOM Level 2.

  [9]Issue 326 What if the standard APIs do the wrong thing?

      [9]
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#326

   Resolved [10]per 323.

     [10] http://www.w3.org/WAI/UA/2000/11/minutes-20001116#issue-323

  [11]Issue 327 Add requirement for support of charset expected of each
API?

     [11]
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#327

   AG: Proper character encoding is required for proper text handling.

   AG: This could be a requirement that is included in a general
"conform
   to specs" requirement. Otherwise, I think this needs to be a separate
   requirement for handling text properly, and that is very important
for
   accessibility.

   Resolved: Include a P1 requirement for proper support of character
   encodings for each supported API. You can't break text.

   Action IJ: Get wording from Martin for this requirement (e.g.,
   "conform", "implement", etc.)

  [12]Issue 328 Checkpoint 4.12: "Words" per minute bounds do not scale
  internationally.

     [12]
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#328

   IJ: One option is to make the bounds informative for English.

   GR: If we do, we should get input from non-English speech engines to
   suggest other bounds.

   GR: Some speech synthesizers allow rate control in terms other than
   "words per minute"

   /* Question of 5% increments */

   MQ: With JFW, you can use page down (granular navigation)

   MQ: Some of this depends on hardware (e.g., incremental changes)

   DP: I think it would be a clear requirement for software synthesizers
   to provide different granularities of rate control.

   DP: Now that my technology allows me to change rates, I do this quite
   often.

   Resolved:
     * Requirement: Allow the user to configure playback rate according
       to the range offered by the speech synthesizer.
     * Informative:
          + Rate depends on language
          + Provide some example ranges for English and other languages
          + Tell people that for ease of use, need to have granularities
            for control (e.g., big jumps or small jumps, ability to
            change rate on the fly).

  [13]Issue 329 Checkpoint 2.7: Clarification required about boundaries
of
  "recognized but unsupported"

     [13]
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#329

   Refer also to [14]issue 362

     [14] http://www.w3.org/WAI/UA/2000/11/minutes-20001116#issue-362

   IJ: Top down:
     * Is perfect support for a language that the user doesn't
understand
       an accessibility problem?
       DA: This could be a problem for users with cognitive
disabilities.
       One idea is to allow the user to say "don't give me content in
       these languages".
     * Support for language, but resources not available
     * Support for language, but language specified by author unknown
     * No support for language

   IJ: There are different issues for graphical rendering and speech
   rendering. For graphical, encoding (should be) sufficient to tell UA
   which character (though UA may not have glyphs). For speech, need
more
   than encoding information, need natural language information.

   Apparent requirements:
     * Alert that there is lack of support for content in some language
     * Indication in context of where lack of support occurs
     * Skip over content in a language that isn't supported

   IJ: (Phill Jenkins comment #3): Why is this an accessibility issue?

   AG: This is an issue for speech users more than cognitive users (due
   to serial access).

   IJ: (Phill Jenkins comment #4): What if UA/AT doesn't know what
   languages are supported?

   AG: They can allow pass-through if they want. This is user control -
   the user needs to be able to say "don't pass this off".

   Resolved: Delete "marked up in a recognized but".

   Notes:
     * This is one switch, not a per-language requirement
     * There may be cases where the conforming UA supports a language
and
       a speech synthesizer does not, or vice versa.

  [15]Issue 330 Definition: Natural language / Writing system / Script

     [15]
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#330

   Resolved:
     * Add "script" to the glossary. Point to Unicode definition.
     * In checkpoint 7.5, talk about script, not natural language.
     * In checkpoints 2.7 and 8.5, leave natural language

  [16]Issue 331 Add a requirement for configurability based on natural
language
  preferences?

     [16]
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#331

   AG: This would be nice to have, but may be too big a new requirement.
   This is all available in CSS2, by the way.

   Resolved:
     * Add notes to checkpoints for speech rate and text rendering (4.1)
       indicating that the developer should consider per-language
       configurability.
     * In definition of profile, mention per-language profiles.
     * The WG recognizes that per-language configurability is a
usability
       gain.

   GR: We should talk to the I18N WG at the plenary in 2001.

  [17]Issue 332

     [17]
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#332

   Proposed: A P1 requirement that the user must be able to choose from
   all available dictionaries and to override author-specified and user
   agent repair of unmarked up natural language.

   JG: HPR 2.5 already does this. I suspect that JFW does this as well.

   IJ: For graphical rendering, NN lets me choose encodings.

   AG: Lynx allows you to force encodings as well.

   EH: Is this a requirement just for users with disabilities? Or does
it
   affect everyone equally? Not sure that this should be a P1
   requirement.

   EH: I don't think I support the P1 level because, in part, we should
   be expecting WCAG-conformant content.

   MQ: I don't think this is a P1 requirement. It's not a disability
   issue.

   RS: I don't think that this is a P1 requirement.

   IJ: Who feels that this is an accessibility issue specifically: AG,
   DA, GR, DP.

   Is not an accessibility issue: BS, ST, RS, MQ, HB

   EH: I could support a P3 requirement, but not if several types of
   support are required (charsets, etc.)

   GR: We do have a requirement for access to all content.

   IJ: Strong support for speech P2 requirement for dictionary
selection:
   DP, GR, DA, AL

   Mild support: EH, IJ

   No/Low support: Everyone else...

   IJ: Note that 4.14 is about configuration, not control.

   Resolved: P2 requirement for configuration of preferred dictionary.

   JG: I think we should spend more time on this in the next version of
   the guidelines. Also, current technology is already doing this.

  [18]Issue 333 Checkpoint 4.2: Clarification required about what "all
text"
  means

     [18]
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#333

   Resolved: This is a clarification and the WG supports the proposal:
     * The UA may use another font family for text content that can't be
       rendered in the user's preferred font family.

  [19]Issue 334 Checkpoint 7.5: Input to search capability not always
"plain
  text" (may be speech, braille)

     [19]
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#334

   IJ: I think that this is not a search functionality (string
matching),
   but an input method issue (that will vary greatly).

   JG: We require standard I/O, so I think this is covered.

   AG: There are technologies like SoundEx that do phonetic matching,
but
   we haven't include such a requirement in this document.

   Resolved: This requires a clarification - matching within the
   character set of the document. For information about input, refer to
   the API checkpoints.

  [20]Issue 335 Checkpoint 9.5: Need to consider international input
methods in
  single-key requirement

     [20]
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#335

   JG: We don't have a requirement for single-key character input.

   Resolved: No change to requirement. Perhaps add clarification that
9.5
   is not about character input.

  [21]Issue 336 Checkpoint 9.2: Delete "accessibility" from "OS
accessibility
  conventions"?

     [21]
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#336

   EH: Change this to P2 and saying more strongly "Do not" instead of
   saying "Avoid".

   JG: Note that 5.8 is a P2 to use OS conventions.

   DA: You should be able to provide other input configs if they are
   better.

   GR: There are two things going on:
    1. Avoid conflicts with system conventions
    2. Don't mess with bindings explicitly for the purpose of
       accessibility.

   IJ: We might add at the end of the checkpoint "for input".

   EH: You can better justify the P1 by narrowing the scope this way.

   AG: My problem with saying "for input" is that you are creating a
   total input/output division and that's not how GUIs work. You
   shouldn't interfere with some output features either (that may work
   with input configs, e.g., sound sentry).

   AG: It's important to support conventions of the OS even if they are
   not specifically for accessibility (e.g., F1 bound to help) - that
   standardization promotes accessibility.

   RS: The default input config should respond to OS accessibility
   conventions.

   JG: Might add a note to 5.8 that using the std keyboard config
   promotes accessibility.

   EH: Is there a danger that access features might be so broad as to
   impose burdens on AT developers (who would have less space to work
   in).

   Resolved:
     * In 9.2, change "avoid" to "do not provide" (or some similar
       wording that conveys a "must" requirement).

  [22]Issue 337 Conformance: Implementing the standard API for the
keyboard
  "after IME"

     [22]
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#337

   AG: I think that on some platforms, there may be several APIs for the
   keyboard.

   IJ: Then use the plural in 1.3.

   Proposed:
     * Change from singular to plural in 1.3 (standard APIs for the
       keyboard).
     * Add note to highlight the international scenario.

  [23]Issue 338 Editorial: Edits to Guideline 1 prose re: easy access

     [23]
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#338

   Resolved: Incorporate editorial change.

  [24]Issue 339 DOM Level 2 requirement for HTML since returned to
Working
  Draft

     [24]
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#339

   RS: Proposed:
     * Use DOM Level 2 Core for access to HTML content. No HTML module
       support in UAAG 1.0.
     * When DOM Level 2 HTML module becomes a Recommendation,
       publish a new UAAG that includes an HTML module requirement. This
       avoids forcing user agents to implement a DOM Level 1 HTML spec
       with known bugs.
     * If DOM Level 2 HTML module goes to Rec before we go to PR, then
we
       will include that requirement at PR.

   Action IJ: Talk to the Director about this proposal

  [25]Issue 340 Editorial: Use "refer to" for references, otherwise
"see" for
  informative cross-refs.

     [25]
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#340

   Resolved: Adopt the proposal

  [26]Issue 341

     [26]
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#341

   Refer to [27]issue 329

     [27] http://www.w3.org/WAI/UA/2000/11/minutes-20001116#issue-329

  [28]Issue 342 Editorial Checkpoint 3.7: Clarification to checkpoint
wording

     [28]
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#342

   Action IJ: Deal with it.

  [29]Issue 343 Editorial: Checkpoint group header for multimedia
checkpoints
  v. continuous-time

     [29]
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#343

   Action IJ: Deal with it.

  [30]Issue 344 Conformance: Delete reference to Internet Media Type

     [30]
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#344

   AG: I think that in the content type section, it's useful to talk
   about trimodal rendering

   Resolved: Delete the reference to RFC2046. These are about data
types,
   not the user experience.

  [31]Issue 345 Checkpoint 1.1: Is requirement concrete and observable?

     [31]
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#345

   JG: We've had three comments on this one:
     * Greg Lowney: Problem with all-or-nothing approach
     * How do you observe that requirement has been met?
     * Part about re-implementing input methods is still unclear.

   JG: Some options:
     * Leave as is (with clarifications)
     * Narrow the scope to core functionalities (as we have done for
       keyboard bindings)
     * Delete

   DA: Consider voice input: Naturally Speaking is close to hands-free.
   ViaVoice requires some mouse/keyboard input.

   JG: Full voice input may not be in scope for this document.

   JG: We wanted keyboard access for all functionalities. If we reduce
   the requirements for other input devices (mouse, voice), we will
   address some requirements from users.

   IJ: Is full functionality through the mouse an accessibility
   requirement?

   DA: Yes. Some people only have access through head pointers (and
   cannot use voice input).

   JG: You can exclude voice from your conformance claims.

   IJ: It might be useful to have a "voice" content label (but that
would
   the the first input in this section, so I'm not so sure...)

   GR: I would prefer to see 1.1 stay as is. In the conformance claim,
   have the developer have to specify which input APIs are supported.

   AG: It's P1 to have all functions available through an API. If you've
   got the keyboard API there, the fact that you add another interface
   that does some of the functions should not degrade you from having
   Single-A conformance.

   RS: If the OS is controlled by voice, your application should also be
   controlled by voice, period. If it's controlled by keyboard and
mouse,
   then those should be the input APIs.

   IJ: That's covered by checkpoint 1.2.

   Some ideas:
     * Require everything through the keyboard API (including cursor
       motion, double-clicks, etc.)
     * Demote 1.1 to P2 for mouse, voice, other input APIs. This assumes
       that you can emulate everything through the keyboard API.
     * Narrow scope of 1.1 to certain functionalities.
     * Allow conformance for input methods other than the keyboard
       (namely pointing device and voice).
     * Note that people can make conformance claims with other software
       such as an onscreen keyboard.
       JG: HotMetal provide integrates an onscreen keyboard.

   AG: A voice browser running at the end of a telephone is not really
   the focus of these guidelines.

   DA: Keyboard APIs already let you do mouse things and vice versa.
   There are examples of full mouse accessibility through the keyboard
   API.

   JG: Our goal with 1.1 is to access functionalities of the UA. The
APIs
   used to do that are not as big a deal.

   EH: What if we limit the scope of 1.1 to keyboard and pointer API.

   EH: What about this: All functionality has to be available through
the
   keyboard or mouse API.

   GR: Proposed: Leave 1.1 as is, but add that to conform you may
require
   emulation via a standard API.

   RS: Not required, here's an example: you may do voice recognition,
but
   be able to do some things in a device-independent manner. If you
claim
   support for a specific input modality, then the user with a
disability
   should expect that all functions are available through that modality.

   JG: Introduce modality in the section on conformance. Talk about the
   checkpoints you must satisfy to make a claim for that modality.

   EH: I hear:
     * Rich wants to talk about devices/modalities in 1.1 and APIs in
       1.2: if you allow voice input, you must allow control of all
       functionalities through voice.
       AG: This is about the user, not the API.
       AG: You could satisfy 1.1 for three modalities by implementing
       just one standard API (for the keyboard).
       IJ: It sounds like 1.1 is about native user interface and 1.2 is
       about APIs.
       DA: You should not be able to conform for voice modality if you
       don't allow access to all functionalities through voice.

   Resolved:
     * Edit 1.1 to talk about input modalities (not APIs) in the
       conforming user agent's user interface. Leave as a P1
       all-or-nothing requirement.
     * For increased conformance granularity, include in the conformance
       section the ability to claim conformance for individual
       modalities. Keyboard is a required modality always. The other two
       in UAAG 1.0 will deal with are pointing device and voice.
     * There is no longer need for clarifying language about
       keyboard-support-through-the-mouse-and-vice-versa.
     * Remind people that they can conform with several components.
Received on Thursday, 16 November 2000 17:57:42 GMT

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