W3C logo Web Accessibility Initiative (WAI) logo

WAI UA Telecon for September 1st, 1999


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


Agenda

Open Action Items

  1. JG: Draft outline for section 5.3.3 of techniques document.
  2. IJ: Run NN (and Mozilla) through guidelines.
  3. IJ: Issue 56 resolution
    a) Mention media objects as example in checkpoint 1.6.
    b) List as example in checkpoint 9.6
    c) Incorporate media objects into 10.5 and 10.6.
  4. IJ:
    a) Add links to WG page with disclaimer about volatility of Working Drafts and products.
    b) Proposed disclaimer to be inserted in evaluations.
  5. IJ Send proposal to WCAG to propose different wording on the requirement for text rendering by UAs.
  6. IJ: Create a list of metadata elements and techniques for HTML
  7. HB, RS: Look at techniques document.
  8. HB: Run pwWebSpeak (with Mark H.) through the guidelines.
  9. GR: Run Hal through the guidelines.
  10. DP: Technique 3.6 - Propose techniques
  11. DP: Run Jaws for Windows through the guidelines.
  12. KB: Fill in the table for UAGL and coordinate with Wendy Chisholm of Web Content
  13. GG: Review proposal for techniques for accessing content.
  14. RS: Coordinate review of HomePage reader.
  15. CMN: Send proposal to the UA list about including an implementation period as part of the recommendation process
  16. CMN: Propose something about schemas.
  17. CMN: Talk to Dan Brickley about document structure and site mapping. Will send a list of tools that make use of meta information to the list.
  18. JA: Compose list of metadata sources for CSS. (e.g., generated text)
  19. Marja: Compose list of metadata sources for SMIL.
  20. RS: Consider the "applicability clause" and propose rewording of the conformance statement for checkpoints.
  21. RS: Post list of checkpoints at issue to the list related to review of Home Page Reader.
  22. Reviewers: Read conformance section of guidelines before testing sub-grouping of checkpoints with current products
  23. Reviewers: Should be as specific as possible about product versions, os versions, etc.

Discussion

  1. REMINDER: Register for October F2F Meeting
  2. LAST CALL: Timing and document preparation
  3. Issue #79: How do specialized browsers like pwWebSpeak and IBM Homepage Reader conform to the guidelines
    http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#79
  4. Issue #77: Validate conformance categories
    http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#77
  5. Configuration Checkpoints for Guideline 9
    http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0127.html
  6. Issue #78: 78 Ian Jacobs Review requirements for window spawning
    http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0212.html

Attendance

Chair: Jon Gunderson

Scribe: Ian Jacobs

Present:
Jim Thatcher
Kitch Barnicle
David Poehlman
Gregory J. Rosmaita
Charles McCathieNevile
Harvey Bingham
Mark Novak
Judy Brewer
Marja Koivunen
Jim Allen

Regrets:


Completed Action Items

  1. JG: Draft outline for section 5.3.3 of techniques document.http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0309.html
  2. IJ: Issue 56 resolution
    a) Mention media objects as example in checkpoint 1.6.
    b) List as example in checkpoint 9.6
    c) Incorporate media objects into 10.5 and 10.6.
    Status: Done in 27 August draft.
  3. IJ: done
    a) Add links to WG page with disclaimer about volatility of Working Drafts and products.
    b) Proposed disclaimer to be inserted in evaluations.
    Status: Done in 27 August draft.
  4. IJ Send proposal to WCAG to propose different wording on the requirement for text rendering by UAs. done
  5. GR: Run Hal through the guidelines. http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0301.html
  6. KB: Fill in the table for UAGL and coordinate with Wendy Chisholm of Web Content http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0300.html
  7. RS: Coordinate review of HomePage reader. http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0234.html
  8. RS: Consider the "applicability clause" and propose rewording of the conformance statement for checkpoints.
    Status: Done in HPR review
  9. RS: Post list of checkpoints at issue to the list related to review of Home Page Reader.
    Status: Done in HPR review

Continued Action Items

  1. IJ: Run NN (and Mozilla) through guidelines. not done
  2. IJ: Create a list of metadata elements and techniques for HTML
  3. HB, RS: Look at techniques document.
  4. HB: Run pwWebSpeak (with Mark H.) through the guidelines.
  5. DP: Technique 3.6 - Propose techniques
  6. DP: Run Jaws for Windows through the guidelines.
  7. GG: Review proposal for techniques for accessing content.
  8. CMN: Send proposal to the UA list about including an implementation period as part of the recommendation process
  9. CMN: Propose something about schemas
  10. CMN: Talk to Dan Brickley about document structure and site mapping. Will send a list of tools that make use of meta information to the list.
  11. JA: Compose list of metadata sources for CSS. (e.g., generated text)
  12. Marja: Compose list of metadata sources for SMIL.

New Action Items

  1. JG: Include in RSVP a request for inidicating completion of action items
  2. IJ: Send a detailed call for review to the IG.
  3. IJ: In document, highlight existence of "native" and "applies to".
  4. CMN: Write a proposal for moving forward on this issue to the list.

Minutes

Agenda [1]: 1) Review of action items 2) Last call scheduling 3) Conformance [1] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0278.html

Agenda 1) Review of action items.

  1. JG: Draft outline for section 5.3.3 of techniques document.
    Status: Done.
  2. IJ: Run NN (and Mozilla) through guidelines.
    Status: Not done.
  3. IJ: Issue 56 resolution a) Mention media objects as example in checkpoint 1.6. b) List as example in checkpoint 9.6 c) Incorporate media objects into 10.5 and 10.6.
    Status: Done in 27 August draft.
  4. IJ: a) Add links to WG page with disclaimer about volatility of Working Drafts and products. b) Proposed disclaimer to be inserted in evaluations.
    Status: Done in 27 August draft.
  5. IJ Send proposal to WCAG to propose different wording on the requirement for text rendering by UAs.
    Status: Done in 27 August draft.
  6. IJ: Create a list of metadata elements and techniques for HTML
    Status: Not done.
  7. HB, RS: Look at techniques document.
    Status: HB has four pages written, pending.
    RS: Not done.
  8. HB: Run pwWebSpeak (with Mark H.) through the guidelines.
    Status: Installed, starting to review. Hope to do this week.
  9. GR: Run Hal through the guidelines.
    Status: Done
    http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0301.html
  10. DP: Technique 3.6 - Propose techniques
    Status: Not Done.
  11. DP: Run Jaws for Windows through the guidelines.
    Status: Not Done.
  12. KB: Fill in the table for UAGL and coordinate with Wendy Chisholm of Web Content
    Status: Done.
    http://www.w3.org/WAI/UA/NOTE-UAGL-impact-matrix-19990901
  13. GG: Review proposal for techniques for accessing content.
    Status: No information.
  14. RS: Coordinate review of HomePage reader.
    Status: Done.
  15. CMN: Send proposal to the UA list about including an implementation period as part of the recommendation process
    Status: Not done.
  16. CMN: Propose something about schemas.
    Status: One more week, otherwise will drop.
  17. CMN: Talk to Dan Brickley about document structure and site mapping. Will send a list of tools that make use of meta information to the list.
    Status: Pending.
  18. JA: Compose list of metadata sources for CSS. (e.g., generated text)
    Status: No information.
  19. Marja: Compose list of metadata sources for SMIL.
    Status: Not done.

    HB: Will this include SMIL "Boston" (the latest version of SMIL?).

    JB: Would be difficult since only a WD.

    MK: Ok for SMIL 1.0 only.

  20. RS: Consider the "applicability clause" and propose rewording of the conformance statement for checkpoints.
    Status: Done. (URL?)
  21. RS: Post list of checkpoints at issue to the list related to review of Home Page Reader.
    Status: Done. Included in the HPR evaluation.
  22. Reviewers: Read conformance section of guidelines before testing sub-grouping of checkpoints with current products
    Status: done
  23. Reviewers: Should be as specific as possible about product versions, os versions, etc.
    Status: done

IJ: People should send status info to Jon when they reply to invitation to meeting.

ACTION JG: Include this message in next call for participation.

Agenda 2) REMINDER: Register for October F2F Meeting

JG: Remember to ask for the W3C rate at the hotel. The registration page is up and running.

Agenda 3) LAST CALL: Timing and document preparation

JG: We are nearing, but have not entered last call. The original intent of the face-to-face was to address comments that came in during last call. But given state of techniques document and number of open issues, not ready to go to last call yet. Therefore, I'd like to discuss the impact on the face-to-face meeting.

DP: Have all the unfilled techniques been assigned?

IJ: No. We sent a call for attention to the UAGL list.

JB: Do you want to send to the IG?

Action IJ: Send a detailed call for review to the IG.

JG: What do people think about going to last call?

MN: I have mixed emotions. Recent issues raise some concerns. Also question whether we should have a face-to-face.

JG: I feel strongly that we should go to last call shortly after the face-to-face.

RS: I feel we need to resolve the conformance issue ("targeted agent") before going to last call. Otherwise, I think the guidelines are pretty good.

DP: I think we should tackle outstanding issues first. I'm not certain we could be ready for last call by the end of next week.

GR: I agree. In my evaluation, I emphasized checkpoints that might be better as techniques (e.g., following a link involves a fee).

IJ: (Review of process)

JB:
a) The sooner you finish the document, the sooner developers will use it.
b) If you wait, you are likely to have a better document. But don't wait too long since document may become irrelevant.

My preference, all other things equal, is to go to last call as soon as possible. But if you have open issues, don't go to last call yet. Another consideration is staff resources. AUGL and UAGL are running neck and neck. If they go to Recommendation in parallel, will make it tough on W3C Team resources. We don't know how the timing of this document is affecting developer browser release cycles.

JB: One possibility is to go to last call in three weeks, then have a 3-week last call. That may not be enough time to compile comments in time for last call. Strategically, you don't want to send doc out twice for last call. However, you can take extra time before going to Proposed Recommendation.

HB: A number of the major browser/assistive tech groups have had no input to this process.

CMN: In AUGL, we've had a similar experience. But we've approached developers lately who've said "We haven't commented but we're trying to implement them!"

JB: What's the strategic impact of waiting?

IJ: Let's get other developers on board during this interval before the face-to-face.

GR: Use evaluations as feedback to developers.

JB: But, until you say to someone "Last chance for comments", people may not react or be motivated.

GR: In some cases, we may still light a fire under developers.

JB: We tried this in AU, but had no impact. We tried last year internally but was a returnless effort.

JG: I don't think we'll get developers to jump to attention until we go to last call.

JG: I propose that we try to go to last call 16-17 October. We will revisit the question at the next teleconference. Judy, Jon, Ian will discuss resource issues offline.

JB: I've argued for moving to last call soon. If the WG feels that's ill-advised, please disregard my comments as needed.

Agenda 3) Issues #77 and #79: Conformance for some assistive techs.

http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#77
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#79

JG: RS has proposed a third conformance class.

JG: IBM HPR, Avanti, PWWebSpeak don't fit easily into dependent UA group. I'd like the dependent UA class to represent advanced features. We don't care whether these features are implemented in a browser or assistive tech.

JG: Biggest concerns with dependent UAs relate to compatibility guideline (6 in 27 Aug draft).

JT: a) What was the intent of the dependent UA category? Seems to be "everything but graphical desktop browser".

JB: What about text browsers?

IJ: You conform by meeting a set of checkpoints. That's all it means.

JT: I don't want Productivity Works to spend time putting MSAA into its specialized interface. We would have to in order to conform as dependent UA. They shouldn't have to based on their "targetedness".

JG: Checkpoint about communication between dependent UAs to promote communication between them. If that's the major issue, let's review it. Are there other checkpoints that don't make sense?

JT: There are others - because HPR is targetted to people who use speech and the keyboard, we shouldn't have to comply with 1.1.

CMN: The problem with the targetted approach is that users working together may have different functional needs. Graphical desktop browser is a targetted UA.

IJ: Have you seen "applies to"?

JT: No. That helps, but look at "low vision" requirements. We have to say "not applicable". Our graphical interface is not relevant to the evaluation.

JG: Issue: Which output of the tool do you evaluate? Primary or secondary?

JT: The visual user interface of HPR is irrelvant for the discussion we're having.

RS: The only reason for the visual interface is to help a sighted user work with someone who cannot see.

JT: Also for debugging.

DP: If a blind person is teaching a sighted person, the sighted person would still need an interface.

JT: HPR can turn on synchronziation for this purpose: cause Netscape to bring up the same page.

DP: My concern here: can I voice command input into HRP. That's a legitimate concern.

JT: Yes, through the keyboard API. You can use voice recognition, therefore, to activate keys.

KB: Will the font/color adjustments apply to Lynx?

DP: Lynx doesn't care about fonts. So no, doesn't apply.

JT: We have comparable requirements for voice (e.g., changing voice for links).

CMN: Lynx hands off issues of font size to the OS. But I agree that you can't style or control the presentation of a link w.r.t. an ordinary piece of text.

JT: For Lynx, there are no fonts.

IJ: There are colors, though.

JG: I'd like to move back to the question of PWWebSpeak and HPR in terms of conformance. Need to evaluate definition of "applies to".

CMN: If you take a given UA, you can say "This UA requires a minimal set of input/output." For HPR, the minimal output set is speech. MInimal input set is the keyboard. That is has added input/output is not relevant for conformance.

DP: There are one or two UAs that are uncommon in their special capabilities for specific audiences. I think we need only expand the definition of "applies" to be able to exclude device issues.

JT: I agree with this approach.

CMN: Do HPR need to apply to UAGL at all? Maybe they don't since they are trying to meet specific needs. We've been addressing "general accessibility" up to now. A UA that didn't allow that therefore wouldn't conform. I don't think this is a bad thing. In short, specialized tools may not need to conform to the same set of guidelines as a generalized tool.

RS: Braille devices are non-standard and HPR does not support them. We did not intend that HPR be used with a Braille device.

CMN: Braille is a standard device with an API

JT: Braille has a standard API?

CMN: It is a standard AT

JT: Is an important issue, but I don't think it is addressable. Braille is to nebulis. I don't think that trageted browsers should be required to support technologies like Braille.

JA: Joins

JT: Then bite the bullet and state that.

CMN: One possible outcome would be to drop the dependent user agent conformance clause. Dependent user agents don't conform unless they attempt to function more generally. I think, however, that it's still critical to explain how assistive techs will work with general tools that conform.

RS: And for dependent user agents, we would need guidelines for features relevant to a particular disability. What I have a problem with is "do so natively" definition. Do we need to redefine this for targetted UAs?

CMN: I think we should specify what we expect dependent user agents to do in order to interoperate with a conforming UA. But we should drop other requirements for targetted UAs.

IJ: We've had this discussion already at the beginning of 1999. It proved too difficult to break out the different functions, devices, content types into different documents or guidelines. We decided to keep it all in one document.

GR: I propose creating W3C Notes for particular slices. I second CMN's motion to drop the subclassing.

JG: Recall that the split was made, in part to allow consumers to ask intelligent questions about assistive technologies. I gather from previous discussions that assistive tech developers want to be able to conform to the UAGL. So benefits to consumers as well as assitive tech developers.

RS: The impact matrix is very helpful for figuring out what's important for a targeted agent. E.g., I'm building a speech output device on multiple platforms. I would want this type of of checklist. I would want to consider less the particular platform. If, on the other hand, I were building a speech synthesizer to run in the background would do something else.

IJ: We've already had a proposal (in January) to not have conformance at all, but just suggest profiles and have developers fill out the checklist.

DP: Screen readers are, can, and should be providing access through interfaces. My expectations are rising. I think there is a need for the dependent UA checkpoints that are in there that promote interoperability and cooperation.

KB: One fear about the impact matrix is that singling out a particular population will cause people to ignore important features for other users. In many cases, benefits are for multiple groups, even though there may be a particular population that would benefit most. In many cases, all users, and use at the same time by several people, needs to be considered.

MK: The matrix is kind of a "next phase" after conformance.

GR: I don't think that targetted information should be included in a document that addresses generality.

CMN: The impact matrix (assuming it's correct), allows you to say "I'm not interested in a universally accessible product" and you can be relatively sure to satisfy requirements. I don't think we should write a Note, however. It's a byproduct of the group.

IJ: I think our charter says that we must consider targetted user agents. Can't just dismiss them.

RS: My main issue is "applies to". Perhaps we need wording that some functionalities are not fundamental to accessibility, but are only meant for people "along for the ride."

IJ: I have problems with "along for the ride". A lot of people would say the same thing about documentation. But it's certainly vital to using software for many.

RS: I don't want to do major surgery on the guidelines. The area that needs focus is "native support." Don't change the whole document.

HB: Would it be worth having another reply (other than yes, no, not applicable) for checkpoints.

Action CMN: Write a proposal for moving forward on this issue to the list.

Action IJ: In document, highlight existence of "native" and "applies to".


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.