Chair: Jon Gunderson
Date: Thursday, April 13th
Time: 2:00 pm to 3:30 pm Eastern Standard Time, USA
Call-in: Longfellow Bridge (+1) (617) 252-1038
Chair: Jon Gunderson
Scribe: Ian Jacobs
Present:
David Poehlman
Jim Allan
Gregory J. Rosmaita
Harvey Bingham
Charles McCathieNevile
Regrets:
Mickey Quezner
Mark Novak
Kitch Barnicle
Rich Schwerdtfeger
Agenda [1]
[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0067.html
GR: Any example given for a self-voicing browser. Still seeking tech assistance for capturing voiced output.
GR: Send to list screen shot of JFW Window list.
Status: I have the screen shot. Will send.
Status: Started
Status: Sent to UA WG. Will send to EO tomorrow.
Done: http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0065.html 1b)
Action HB: Ensure that EO documents their commitment to to the FAQ.
DP: We might want a FAQ for the users.
JG, IJ: Let's wait for EO proposal before we draw up any other ones.
1.FTF for Evaluation and Repair Tools working group in Amsterdam
http://www.w3.org/WAI/ER/2000/05/agenda
2.Notice of Proposed Rulemaking: Electronic and Information Technology
Accessibility Standards by the United States ARCHITECTURAL AND TRANSPORTATION
BARRIERS COMPLIANCE BOARD. Comments will be accepted until May 30th
http://www.access-board.gov/sec508/nprm.htm
http://www.access-board.gov/sec508/overview.htm
IJ: Keep resolving those issues!
HB: I think we have to be careful about form submit buttons that aren't obvious.
GR: I think this should be addressed in the techniques document.
No objections to proposal:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0088.html
Action IJ: Adopt wording of proposal.
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#207
Refer to summary of 6 April minutes on "where we are":
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0037.html
IJ: I understand the open issue to be whether 2.1 scope should be reduced to content for humans or left at "all stuff".
CMN: Human-readable content through the UI is part of a minimal requirement for conformance to 2.1.
GR: I think the scope should be "all", not human-readable only.
DP: I'm still not sure what's lost if we don't include machine content.
IJ: I think that the UA should use machine content to do repair strategies, but that it should not be required to do so.
CMN: I think that if the user has access to all the content, then the user can make repairs the UA couldn't make. JG: Is this a requirement only for markup languages, or also binary stuff?
CMN: Good question. It's harder to use a GIF image in source mode. But I would continue to require them.
CMN: There's no requirement that if you make content available through the UI that you also have to make it available through some other means. There is no statement about how many times you must make content available.
CMN:
a) Everything has to be available.
b) Things for humans must be available through the UI (not through a source
view). In the real world:
c) There's no requirement for a source view.
It will meet requirement for things meant for machines. However, if all the information meant for machines is rendered somehow through the UI, then no other view required.
IJ: I disagree that the user needs to know that "id" is there.
CMN: Rendering is not sufficient. You need to make available the fact that the content is styled by "id". You need an interface that lets you do everything you can do with an id.
IJ: But the "id" value is not required. What about a processing instruction at the top of an XML document? I think that we're talking about processing, and the effect if what's important to the user, not the PI itself.
CMN: I would agree that that's an edge case.
IJ: What about the fact that all info is available through the API? CMN: Not sufficient.
HB: I want to be able to view all the content, including the META information.
JA: I think I agree with HB.
DP: I don't see the validity, for the general user, of having binary available to the general user.
JG: This machine stuff could be useful, but there's no guarantee.
IJ: Suppose a user agent doesn't support PNG, must it make it available?
CMN: No, only the URI to the PNG.
IJ: For those things not made available through the UI, what's the minimal way to satisfy the other stuff?
CMN: A source view would meet the requirement. But the minimal requirement would not be for a source view.
IJ: Why is this checkpoint different from other checkpoints that allow some information to be handled through an API?
CMN: We should require native support for access to all content.
GR: In the case of rendering things natively, whether you need to view binary: Lynx exposes the alternative or puts in a place-holder - you can turn anything it can't render natively into a hyperlink.
CMN: Lynx gives you access to applicable content, otherwise gives you access to things it can't deal with (through a link).
IJ: Should we adopt similar wording as ATAG about the "average user"? That is, that the user is not expert. I have a problem with P1 access to information that is not meant for humans and will not be useful to most users. I do agree with Charles, however, that if some of that "content" is not available directly to users, it may not be accessible.
DP: What does it mean to "make available" information?
JG: Originally, some things through the UI and some through an API.
IJ Propose: 2.1.a: Ensure that the user has access to all content meant for human consumption, including equivalent alternatives for content, through the user interface. Note: A source view does not meet this requirement. P1
2.1.b: Ensure that the user has access to all content meant for machines either by processing it according to specification or by making it available directly to the user through the user interface.
Note: A source view would suffice to meet this requirement.
IJ: Clearly 2.1.a a P1. I agree with the first half of 2.1.b as P1, but not sure about priority of second half since information is available through an API. I'm not sure that the source view would provide access to most people; I've heard people say that most users would not be able to use this information.
Consensus: The split is reasonable, as long as it covers the requirements.
GR, CMN: Unfortunately, people count the numbers of P1s. Also consistency with current
PR. IJ: I think both should be sacrificed for the sake of clarity.
JG: We've missed something if we've said that the other checkpoints don't cover the accessibility of the user interface and you need a source viwe.
IJ: This can be seen as a way to catch thigns that we've missed.
CMN: (Use case) I went to a Web site. The URI you could use to get to the site started with "javascript:". The only problem with my user agent was that it didn't support javascript.
IJ: If you don't support javascript, then applicability kicks in.
CMN: But it's in HTML, which is supported. The UA can either provide some form of access or tell me to buzz off.
IJ: Sounds like you're requiring minimal repair strategy is native support for source view.
JG: Sounds like what I'm hearing mostly is that 2.1.b is not to improve accessibility of the user agent, but to repair broken content or deal with (in)applicability. We have another repair checkpoint (2.3). Do we need another guideline for repair?
JA: UAs have already repaired broken content. It's one of their primary duties.
CMN: I think the document's already too big. I don't want another guideline.
Action IJ: Propose split to the list. Identify why and issue of priority.
HB: I think we have to be careful about form submit buttons that aren't obvious.
GR: I think this should be addressed in the techniques document.
No objections to proposal:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0088.html
Action IJ: Adopt wording of proposal.