W3C logo Web Accessibility Initiative (WAI) logo

WAI UA Telecon for September 29th, 1999


Chair: Jon Gunderson
Date: Wednesday, September 29th
Time: 12:00 noon to 1:30 pm Eastern Standard Time
Call-in: W3C Tobin Bridge (+1) 617-252-7000


Agenda

Review Open Action Items

  1. JG: Run pwWebSpeak (with Mark H.) through the guidelines.
  2. JG: Propose techniques for rendering of frames
  3. JG: Contact DP about particpation
  4. JG: Contact GG about particpation and review of conformance proposal
  5. IJ: Find out about MS review of document before F2F and their participation in the meeting.
  6. IJ, MRK: Send reference on SMIL note to UA list
  7. IJ: Make these editorial changes about continuous equivs for audio captioning and descriptions
  8. IJ: Link to "altifier" from Techniques document.
    http://www.vorburger.ch/projects/alt/
    Link to ER tools page from techniques.
    http://www.w3.org/WAI/ER/existingtools.html
  9. DP: Technique 3.6 - Propose techniques
  10. DP: Run Jaws for Windows through the guidelines
  11. GG: Review proposal for techniques for accessing content.
  12. Working Group: Review IJ proposal for changes in conformance for discussion next week
  13. GR: Write a proposal to address issues about spawned windows.
  14. MR: Working on SMIL techniques in addition to SMIL access note.
  15. MR: Coordinate with Geoff Freed so that issue related to aalternatiove content is sufficiently addressed in PF.

Annoncements

  1. Call for Face to Face meeting agenda items
  2. WAI Authoring Tools guidelines in last call until October 4, 1999
    http://www.w3.org/TR/1999/WAI-AUTOOLS-19990903/
  3. DOM Level 2 is in last call until October 8, 1999
    http://www.w3.org/TR/WD-DOM-Level-2/

Discussion

  1. Issue #89: Discussion of Ian Jacobs conformance proposal based on Interoperable User Agents and Non-Interoperable User Agents
    http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#89
  2. Issue #78: Review requirements for window spawning
    http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#78
  3. Issue #85: Priority of checkpoint on language support
    http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#85
  4. Issue #86: Should Guideline about support for W3C technologies be broadened or narrowed?
    http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#86
  5. Issue #87: Proposed wording change about user-control of highlight rendering
    http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#87
  6. Issue #88: Proposed wording change for checkpoint on access to selected content.
    http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#88
  7. Issue #91: Proposed reformulation of frames checkpoint
    http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#91
  8. Issue #92: Proposed checkpoint about form orientation
    http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#92
  9. Issue #93: Proposed modification to definition of "applicable checkpoint"
    http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#93
  10. Issue #94: Reenforcing the the use of standard keyboard APIs in guidelines 2
    http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#94

Attendance

Chair: Jon Gunderson

Scribe: Ian Jacobs

Present:
Rich Schwerdtfeger
Mark Novak
Kitch Barnicle
Gregory J. Rosmaita
David Poehlman
Jim Thatcher
Denis Anson
Marja-Riitta Koivunen
Charles McCathieNevile

Regrets:
Jim Allan
Markku Hakkinen


Action Items

Completed Action Items

  1. JG: Contact DP about particpation
  2. JG: Contact GG about particpation and review of conformance proposal
  3. IJ: Find out about MS review of document before F2F and their participation in the meeting.
  4. IJ, MRK: Send reference on SMIL note to UA list
    http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0397.html
  5. IJ: Make these editorial changes about continuous equivs for audio captioning and descriptions
  6. IJ: Link to "altifier" from Techniques document.
    http://www.vorburger.ch/projects/alt/
    Link to ER tools page from techniques.
    http://www.w3.org/WAI/ER/existingtools.html
  7. Working Group: Review IJ proposal for changes in conformance for discussion next week
  8. DP: Technique 3.6 - Propose techniques
    http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0416.html
  9. MR: Coordinate with Geoff Freed so that issue related to aalternatiove content is sufficiently addressed in PF.
    Status: DOne, according to private e-mail from Al Gilman

Continued Action Items

  1. JG: Run pwWebSpeak through the guidelines.
  2. JG: Propose techniques for rendering of frames
  3. GG: Review proposal for techniques for accessing content.
  4. GR: Write a proposal to address issues about spawned windows.
  5. DP: Run Jaws for Windows through the guidelines
  6. MR: Working on SMIL techniques in addition to SMIL access note.

New Action Items

  1. IJ and JG: Send a proposal to the ua list for resolution of the conformance issues related to assistive technology

Minutes

Agenda [1]

[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0427.html

1) Review of action items.

  1. JG: Run pwWebSpeak (with Mark H.) through the guidelines.
    Status: Not done.
  2. JG: Propose techniques for rendering of frames
    Status: Pending.
  3. JG: Contact DP about particpation
    Status: Done. He'll try to join today. Will be at ftf.
  4. JG: Contact GG about particpation and review of conformance proposal
    Status: Done. No news back.
  5. IJ: Find out about MS review of document before F2F and their participation in the meeting.
    Status: Pending. Waiting for MS to call back. Dick will participate in part of the meeting. Someone else from MS will also participate. Both will review next draft.
  6. IJ, MRK: Send reference on SMIL note to UA list
    Status: Done.
  7. IJ: Make these editorial changes about continuous equivs for audio captioning and descriptions
    Status: Done.
  8. IJ: Link to "altifier" from Techniques document.
    http://www.vorburger.ch/projects/alt/
    Link to ER tools page from techniques.
    http://www.w3.org/WAI/ER/existingtools.html
    Status: Done.
  9. DP: Technique 3.6 - Propose techniques
    Status: ?
  10. DP: Run Jaws for Windows through the guidelines
    Status: ?
  11. GG: Review proposal for techniques for accessing content.
    Status: ?
  12. GR: Write a proposal to address issues about spawned windows.
    Status: Pending.
  13. MR: Working on SMIL techniques in addition to SMIL access note.
    Status: ?
  14. MR: Coordinate with Geoff Freed so that issue related to aalternatiove content is sufficiently addressed in PF.
    Status: ?

2) Announcements:

3) Conformance.

Interoperable proposal:
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0365.html

Ian's summary:
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0433.html

Jon's proposed terminology:
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0436.html

DA: I'd like to argue that all user agents should be interoperable even if designed for a particular funcational need. Some users have several disabilities.

RS: Developers want to support many groups. Don't have resources however, and you shouldn't be penalized for getting products out to users.

IJ: Types of interoperability

We agree less as we go down the list.

JG: I think we're having a problem of terminology.

IJ: See the summary. I think the goals of the WG are contradictory and leading to issues.

JT: But Assistive Technology developers want to be able to claim conformance.

RS: If your Desktop Graphical User Agents (DGUA) targets the general public, they should be accessible to the general public. You want to say this rather than make targeted ATs comply.

CMN: The difficulty is that you have to say when a UA targets the general public or a particular user group. They could say that they're not meant for the general public. They're only meant for people who want a basic graphical interface who rely on the mouse and who rely on the keyboard for some things. This happens to satisfy many needs of the deaf community.

JR: I think MS would get shot down for this. Consumer pressure could force conformance as a mainstream browser.

RS: These companies are spending a lot to make their products accessible. They wouldn't do what you're saying.

DA: So when we split, we run into logical problems. That's because we're trying to be general and specific at the same time. Would it be a problem for specialty browsers to not be 100% conformant?

IJ: I.e., use the checklist for them. I don't think "80% conformant" makes sense.

CMN: So combine the models: conformance means you do everything. Use the impact matrix for specialized tools.

JT: So you won't allow the AT developer to use the label in a practical manner.

KB: If I'm a purchasing agent for the dept. of defense that says "HPR" conforms and "IE" conformance, why would I choose one or the other?

JG: Most AT costs money. Most desktop browsers are free.

KB: Purchasers need more information than just conformance. How to tell purchasers what/where more information is required?

IJ: If you're only meeting 30-40% of the checkpoints, then the guidelines really aren't applicable to your tool.

CMN: HPR provides some basic graphical rendering (through NN). But we don't want HPR to have to fix NN to conform to the Guidelines. Also, speech output will be part of the OS in a few years.

JT: We're marketing to people who want speech. There's only one area of interoperability where I'm uncomfortable marking "N/A": providing access to other AT. Should be stronger still.

CMN: I think there's very solid consensus that there's a class of tools that needs to provide accessibility for everyone (either do it accessibly natively or by providing information to others).

JG: I sent to the WAI CG a proposal about external bodies verifying conformance.

DA: In our particular need, the conformance label doesn't have a specific meaning. If you're a non-visual browser only, conformance means one thing. If you have no mouse, you may conform somehow else and yet you use the same label "conforms".

JT: AT people want to be able to identify important checkpoints for them. I can say that I can conform already by checking of a certain number as "N/A".

CMN: Part of the interoperable question is that if you remove it, you have to specify carefully what you do. (Note: Tools need to handle tables themselves.) The EIAD browser (for people with some cognitive impairments) is highly regarded (and expensive) and has a touch screen interface. People who have brain injuries often has mobility problems as well. Should EIAD provide an API for their touch screen interface? EIAD doesn't support the keyboard API. Is it necessary that they support the keyboard API so that people can use it?

JG: If they're not supporting the keyboard, then they shouldn't have to. You say you support the touchscreen (and should do so accessibly).

(Digression into discussion of the keyboard, checkpoint 2.1)

(Back to conformance).

IJ: Let's look at these two questions:

KB: What does (b) mean? Few ATs will conform alone.

DA: Most ATs add functionalities to mainstream browsers.

DP: PWWebSpeak runs alone.

JG: Don't know about Avanti.

GR: I had proposed that we do away with subclasses and address "user agents".

DP: This troubled me as well a while back.

GR: I think mainstream browsers, more than HPR, would want the marketing force. HPR already has the target audience on board already.

JG: If something claims conformance, there will be base-level conformance.

JT: There are a number of content guidelines that are implemented in ATs only. Need support from ATs for these.

GR: I think that's a self-fulfilling prophecy.

JT: The only difficult line is on interoperability.

DA: The basic guidelines are for base functionality. The mainstream graphical browsers must provide a way to provide all of this access. When we use something like HPR, this is an add-on that is providing some of the non-native functionality. We're treating the HPR erroneously as a mainstream browser as soon as they do graphical rendering.

RS: I like the suggestion of breaking it up between AT and graphical desktop. How about this:

DA: Don't make a lower priority, but narrow it. If you're rendering information provided by a mainstream browser, you need to communicate back to the browser what you did with it. The AT communicates back to the underlying UA what has happened (e.g., linearizing graphically). You don't have to deal with keyboard control since the underlying browser does that.

GR: If you use JFW and modify the page, and the page gets modified, the changes are lost.

DA: When we talk about interoperability, we need to talk about it bidirectionally.

CMN: An assistive technology does need to provide interoperability (e.g., by relying on interoperable interfaces provided by the browser).

DA: In short: interoperable associatively for some functionalities.

JT: I don't want priority differences, I want the guidelines to say that these checkpoints are for mainstream UAs only.

KB: I lean towards variable priorities.

MN: I don't think we should have checkpoints and then say that they don't apply. I'd be in favor of going back to define the base functionalities. We need access to content.

KB: Struggling over the conformance issue is not as important as ensuring functionalities are provided. Allow HPR to say how they work with mainstream browsers.

CMN: I believe (and I think consistenly) that the answers to Ian's two questions are yes (clearly) and "this isn't a requirement, but if we can write the document to allow it, that's great."

GR: Let's function on base functionality. I agree with Mark and Denis - I'd rather do away with the split and define what it is that the UA must do to be useful.

DP: In general, I think it's more important to deal with the basic issue of helping developers achieve accessibility. I don't think conformance by ATs should be a priority.

RS: I think it's import for ATs to be able to conform. It's also important for ATs to have a reasonable bar to conform to. E.g., as a blind user, I need a "where am I" functionality. I think that this WG includes experts that identify user needs. Having guidelines for an AT to follow is a good thing to have. We should have an interoperability guideline that's for mainstream only.

JT: We need to encourage ATs to do more things. Some division is a good thing.

DA: To conform, a UA should do all of the checkpoints. The checkpoints are useful to ATs and ATs add functionality to the underlying browser. Unless the UA is claiming to provide universal access, the AT shouldn't try to conform.

MK: I think browsers should conform. For ATs, there are a lot of points that need clarification. That should be the next step for targeted user groups. They should take the guidelines and build specific guidelines from them. So no special conformance for ATs. They should use the impact matrix.

IJ: I think that conformance by ATs is less of a priority than other issues. If that needs to be removed as an obstacle to advance, then let's remove it. But I'm not insensitive to the marketing requirements of AT developers nor to their participation in the group.

KB: I think we're moving closer (notably by removing distinctions for a number of checkpoints).

RS: Is there consensus that we have dependent and desktop UAs?

CMN: There is a terminology issue, but the issue is deeper than a terminology issue.

IJ: The issue is "Who is conformance for besides graphical desktop browsers?"

JG: Consensus today is that conformance is for mainstream.

GR: For ATs, use the impact matrix plus some note on usability.

GR: I think the terminology should be used cautiously since lynx or w3 may not fall under the name. You might just say "User Agent Guidelines..."

CMN: Allow a different institution (e.g., RNIB) to define their own conformance statement, based on the UAGL impact matrix.

IJ: Distributed conformance may confuse people.

JT: I think that the impact matrix won't work for us to be able to claim conformance. You can't say that the interoperability checkpoints don't apply to some disabilities. I'm willing to say that the guidelines apply to mainstream only.

RS: I wouldn't mind having checkpoints, but maybe we don't have to conform.

GR: I wouldn't support conformance based on the impact matrix alone. It would be the basis of more formal statement built on top of it.

Action Ian and JG: Write a proposal to the list.


Copyright  ©  1999 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.