- From: Ian Jacobs <ij@w3.org>
- Date: Thu, 13 Apr 2000 15:40:37 -0400
- To: w3c-wai-ua@w3.org
WAI UA Teleconf
13 Apr 2000
Jon Gunderson (Chair)
Ian Jacobs (Scribe)
David Poehlman
Jim Allan
Gregory Rosmaita
Harvey Bingham
Madeleine Rothberg
Regrets:
Mickey Quenzer
Mark Novak
Kitch Barnicle
Rich Schwerdtfeger
Next teleconference: 20 April
Agenda [1]
[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0067.html
1) Announcements
1a) Progress
12.GR: Look into which checkpoints would benefit from
audio examples in the techniques document.
GR: Any example given for a self-voicing browser.
Still seeking tech assistance for capturing voiced output.
13.GR: Review techniques for Sections 3.7 and 3.8
Status: Working on a technique proposal.
14.GR: Send to list screen shot of JFW Window list.
Status: I have the screen shot. Will send.
17.JG: Identify the minimal requirement for each checkpoint.
Status: Started
18.HB: Take scoping issue of the current guidelines to the EO working
group
Status: Sent to UA WG. Will send to EO tomorrow.
20.MR: Talk to Geoff Freed about implementations that slow down
multimedia presentations.
Done:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0065.html
1b) No progress
1.IJ: Draft a preliminary executive summary/mini-FAQ for
developers. (No deadline.)
2.IJ: Propose three terms to the list: Document Source, Document
Object
and Rendered Content
3.IJ: The content/ui division in G1 needs to be fixed
4.IJ: Actions from FTF meeting
5.CMN: Find out from I18N how to generalize the accessibility
provided
by sans-serif fonts.
6.CMN: Propose a technique that explains how serialization plus
navigation would suffice for Checkpoint 8.1.
7.DA: Send name of new organization to list that was mentioned by
some
from the US Census Bureau
8.DA: Review techniques for Guidelines 7 and 8
9.DB: Get Tim Lacy to review G+
10.DB: Review techniques for Guidelines 3, 4, and 11
11.DP: Review techniques for Guidelines 1 and 2
15.JG: Write email to the list asking for information about which user
groups require the ability to slow down presentations
othewise access it impossible.
16.JG: Take conformance grandularity issue to the WAI CG.
19.MQ: Review techniques for Guidelines 9 and 10
21.RS: Take notification of focus and view changes to PF as possible
DOM
3 requirement.
2) On the FAQ.
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.
3) Announcements
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
4) Update on proposed Rec.
IJ: Keep resolving those issues!
5) Open issues after ftf
5.1) Issue 207
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.
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.
5.2) Issue 208
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#208
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.
--
Ian Jacobs (jacobs@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 831 457-2842
Cell: +1 917 450-8783
Received on Thursday, 13 April 2000 15:40:42 UTC