- From: Ian Jacobs <ij@w3.org>
- Date: Mon, 11 Oct 1999 20:50:31 -0400
- To: w3c-wai-ua@w3.org
User Agent Accessibility Guidelines Working Group
Face to Face at Microsoft
11 October 1999
Jon Gunderson (JG, UIUC, Chair)
Ian Jacobs (IJ, W3C, Scribe)
Kitch Barnicle (KB, Trace)
Hans Riesebos (HR, ALVA)
Harvey Bingham (HB)
Mark Novak (MN, Trace)
David Poehlman (DP)
Glen Gordon (GG, Henter-Joyce)
David Clark (DC, CAST)
Judy Brewer (JB, W3C)
Wilson Craig (WC, Henter Joyce)
Jim Thatcher (JT, IBM)
Rich Schwerdtfeger (RS, IBM)
Gregory Rosmaita (GR)
Charles McCathieNevile (CMN, W3C)
Dick Brown (DB, Microsoft)
Mickey Quenzer (MQ, Productivity Works)
Tim Lacy (TL, Microsoft)
Legend:
a) Comments followed by initials in parentheses.
b) Editorial requests/comments in [E].
c) Action items preceded by Action:
Agenda [1]
[1]
http://www.w3.org/WAI/UA/1999/10/wai-ua-f2f-199910.html#agenda
Reference document:
http://www.w3.org/WAI/UA/WAI-USERAGENT-19991005
1) Introductions.
2) Review of action items
1. JG: Run pwWebSpeak through the guidelines
Status: Contacted Productivity Works
to finish the review .
2. JG: Contact Lakespur Roca related to posting
for review of keyboard support
http://lists.w3.org/Archives/Public/w3c-wai-ig/1999OctDec/0015.html
Status: Done.
JB: Lake couldn't come to the
meeting. However, could participate
by phone. Has comments on the usability of
the guidelines.
Action Ian: Follow up with Lake on usability questions.
3. JG: Contact MR about SMIL techniques
4. JG: Review RS comments on current working draft and update the issue
list
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0063.html
Status: Done.
5. IJ: Contact Microsoft about participation at
F2F meeting in Redmond
Status: Done.
6. IJ: Contact Marja about writing a proposal for
what should be changed related to checkpoint 2.1 issues
Status: Done.
7. IJ: Split Checkpoint 1.1 into support device indepdence
and use standard APIs. Clarify
that not all APIs required. Results dependent on Rich
proposal.
Status: Done.
8. IJ: Propose a checkpoint like the ones for form about
table summary information
(checkpoint 9.9 and 9.10)
Status: Done
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0092.html
9. IJ: Change title of Guideline 7 to reflect more than just w3c
technologies accessibility:
Done: "Implement open specifications and their accessibility
features"
10. IJ: Add checkpoint 6.6 to guidelines 7
Status: Dropped.
11. GG: Review proposal for techniques for accessing content.
Status: Dropped.
12. GR: Write a proposal to address issues about
spawned windows.
Status: Pending.
13. DP: Run Jaws for Windows through the
guidelines
Status: Done.
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0095.html
14. MR: Working on SMIL techniques in addition to
SMIL access note.
Status: Not done.
15. RS: Propose rewording of Checkpoint 1.1
Status: Not done.
IJ: I proposed something.
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0092.html4
IJ: Refer to Rich's response:
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0096.html
3) Process Review: Where the UAGL are/Schedule.
a) Last call.
i) Contact chairs of dependent WGs (e.g., DOM)
ii) External reviews.
JG: Some ideas:
Peter Korn, Earl Johnson, T.V. Raman, Lake Rocca,
Curtis Chong, Jim Fructerman, Joe Sullivan,
Mike Paciello, Håkon Wium Lie, Real Networks.
JB: Plan to contact people 4 times to ensure
they do the review: before, when it goes to
last call, during last call, at the end of last call.
JG: Coordinate through the chair (cc JG, IJ, JB).
IJ: Please send names to the list.
Action JG: Talk to WC offline about contacts.
Action HR: Find information about European contacts.
b) Proposed Recommendation. Start organizing press
release/testimonials.
c) Recommendation:
i) Includes Guidelines/Checklists/Impact Matrix
ii) Publish the Techniques Doc as a Note.
JB: I recommend that the Techniques Doc be
as stable as possible during Proposed
Rec: strength of it will support Guidelines.
Recommend pointing more visibly to it
[E].
IJ: We'll have no time to work on Techniques
during review period.
iii) Documentation of minority opinions/issues of
concern (e.g., conformance).
iv) Press release/Testimonials.
JB: Please coordinate Testimonials through
the W3C Team (IJ, JB). We strive for
diverse testimonials (large org/small
org/i18n). Since Authoring Tool
Guidelines will be going to PR also soon,
need to consider distribution as well.
RS: Is there a template?
JB: Yes, I can make this available soon.
I prefer to send to individuals rather
than just linking from Web.
SCHEDULE:
a) Go to last call: Start 29 October / End 1 December
JB: This is risky since right before AC meeting.
b) Go to Proposed Rec: 15 December (latest)
c) Go to Rec. Approximately: end of January.
JG: I think it would be helpful to have a
face-to-face to process last call comments.
GG: Who else is interested in this process? Will
new people come out of the woodwork during last
call?
CMN: Yes.
JB: The last call announcement does wake people
up. It's a lot better to get the criticism during
last call, not Proposed Rec.
WC: When you solicit input from people who haven't
been involved to date, don't you risk derailing
the process?
GR: We hope the document is strong enough to
educate new readers. If it doesn't, we have a
serious problem.
JB: I agree with Gregory. The document needs to be
able to stand up to public scrutiny.
GR (to WC): If you are going to canvass ATIA
people, show them how to find the minutes and the
mailing list archives, the issues list, and the
search engine.
DC: Need to get promotion/implementation
commitments as well?
JB: UAGL WG should track who is committed to
implementing all/part of UAGL. Note that not all
commitments will be public.
4) Issue 78
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#78
IJ: The SMIL WG said "You can't just turn off
spawned windows since you won't have access
to some content.
GR: Instead of on/off, allow the users to control
window spawning. Cascade:
a) Minimal: Nothing
b) Notify.
c) Prompt the user to continue
d) Allow the user to configure the previous
prompting options.
JT: How do you present the information if not in a
spawned window?
GR: A system message is different than a new
content window. System dialogs don't cause the
same problems.
RS: Like tip of the day.
DC: Are we not differentiating windows of the same
application from windows of different
applications? Or are they one and the same?
MN: It depends on what you're opening. Use the
same cascade as is used by systems in general
(e.g., you're leaving secure site).
HB: We haven't articulated how user preferences
in profiles would fit in.
GG: I think that announcements are too onerous.
DP:
a) First question is what kind of window are we
talking about? I think this functionality would be
great, but not always necessary. Perhaps it
belongs in the techniques instead.
b) As for GG's comments, I think that everyone
should have this control in their browser. This is
a usability issue.
CMN: I agree with GG that this may be too
onerous. It may not be an optimal solution
anyway. The problem we're trying to solve is
trying to reduce disorientation when too many
windows on the screen. Having a history that spans
several window instances would solve the
navigation problem.
HR: My concern is with profiles. I don't like the
interactive solution (at least for some users).
IJ: I agree with Charles.
GR: The specifics of the mechanism belong in the
techniques document.
DB: There is precedent in Windows for opening new
windows or not within the same application (e.g.,
directory view).
DP: Internet Explorer provides option of opening
pages in same or separate window.
MN: Just a note about about using history - may
not work if new process started.
IJ: Refer to Al's counter-proposal:
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0272.html
RS: One of the problems I'm having is the
definition of "spawned window".
GR: Another possibility is to reword the
checkpoint: ask for user control of notification
of spawned windows.
JG: Spawned window: a window created by the user
agent process.
DC: User notification vs. User control. I agree
with statement earlier that user control goes
further into new functionality. I'd be in favor of
taking out the control part and strengthening the
notification part.
RS: One way to address this: When a created window
has not been initiated by the user (e.g., create a
new browser window, help window, etc.).
IJ: Relates to checkpoint 10.1 as well: "Provide
information about content and viewport changes (to
users and through programming interfaces)."
KB: Users really are initiating, e.g., by
following a link. I don't know that following a
link will get PDF or PS, or whether will open in a
new frame.
GR: In the definition of user-initiated, need to
cover event handlers and scripts from HTML 4.
DB: Should authors give hints?
IJ: WCAG says this, but this is expected to
be a UA functionality.
HR: What does the user *expect* to happen?
This may not be related directly to automated
or configured behavior, but user experience.
JT: Sounds like spawned windows means
UA-controlled windows.
Resolved: "spawned window" means windows created
natively by the user agent process.
DC: What about other disabilities than users with
blindness? Any spawned window of the same class
needs to have the same functionality.
GR: If the UA generates a new instance of itself,
it must retain the configuration.
GR: Note: you don't want to have to turn off
scripting in order to keep windows from popping
up.
DP: Turning off scripts is not enough. The browser
is aware that it has to load a plug-in. We need to
distinguish between plug-ins and other
applications here.
JT: These are usability issues, not accessibility
issues.
GG: The accessibility issue is the knowledge that
the spawning is happening. The usability issue is
control.
GR: I think that in addition, the user agent has
to inherit the configuration of the parent
viewport.
RS: Proposal:
a) Define "spawned content window": A viewport
created by the UA process that
displays content."
b) Allow the user to control spawned windows
initiated by the user agent.
NOTE: For example, in HTML, opening a
document in a new target frame, author-supplied
scripts. In SMIL 1.0, show="new".
KB: What does "control" mean? What does
"user-initiated" mean?
HR: There are two levels of spawned windows:
a) Author-specified
b) User agent-specified.
GR: When following a link, the user-initiated
action is following a link. Not opening a window.
RS: Define "user-initiated/author-initiated/UA-initiated"
Proposed:
a) Define "spawned content window": A viewport
created by the UA process that displays content."
b) Allow the user to control the spawning of
viewports other than those created as the
expected result of a user action.
NOTE: For example, in HTML, opening a
document in a new target frame, author-supplied
scripts. In SMIL 1.0, show="new".
KB: I have a problem with the word "expected". Who
decides what's expected?
DB: What does "control" mean? It implies more than
notification.
RS: Push that to the techniques document.
CMN: What's the minimal requirement.
WC: I have a problem with the concept of
"control". How about confirmation/denial of
spawned windows.
CMN: Does the user have to be able to have new
windows spawned?
HR: I think we're still in G4: Turn off features
that may impede accessibility.
JG: Is the minimal requirement a prompt? Or do we
want to allow turning on/off.
DB: If it's notification, this goes in the
orientation guidelines.
RS: I think this is a usability in addition to
accessibility. You want to be able to shut off the
notifications.
DB: Note the difference between the feature and
the prompt. Say explicitly that you want both:
a) Turn on/off feature
b) Be prompted for the feature.
GR: What we want: (a) notification and (b) some
level of control. The form of control is for the
techniques. In Windows, prompt with the option to
turn off the prompt.
DB: Examine priorities: notification higher
priority than control.
Resolved:
a) Define "spawned viewport": A viewport
created by the UA process that displays content."
a2) Define UA-initiated and user-initiated.
b) Add comment about UA-initiated spawned viewports
to 10.1 about notification. [P1].
c) Allow the user to control UA-initiated spawning of
viewports. [P2]. Move this checkpoint to G5
on control over styles.
NOTE: For example, in HTML, opening a
document in a new target frame, author-supplied
scripts. In SMIL 1.0, show="new".
DB: Perhaps say "When possible..."
d) Add techniques (e.g., Al levels)
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0272.html
a) on/off
b) this time only
c) from now on.
e) Combine this one with 5.17
(control viewport size/position, P2.)
----
5) Issue 85
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#85
IJ: Priority of rendering according to natural
language markup.
JT: No UAs read the markup today.
GR: Base functionality: (1) what the UA has to do
to make the document accessible and (2) what the
UA has to communicate. For "lang" in HTML, this
could cause a font to be used.
GG: If I as a dependent-UA don't have access to
the markup, I'm prevented from doing the right
thing because I don't have the information.
JT: But the current checkpoint says render, not
expose.
IJ: It's meant to be about rendering. The exposing
part is covered by another checkpoint (the DOM
checkpoint).
GG: I side with Jim. This is not an accessibility
issue.
GR: I don't agree.
DP: Thanks to CMN for reinforcing the
discussion. We're not talking about flags, we're
talking about rendering content.
JB: I think of this example: user able to
understand multiple languages, document includes
text in multiple languages. You do need dynamic
swapping.
RS: Is this a general usability issue or an
accessibility issue?
JB: I think it's accessible. If I am sighted, I
know the difference between different font
families. If I don't have access to the visual
clues with my screen reader, then I can't parse
mentally.
RS: But what if I don't have the fonts.
JT: How does a graphical user agent
notify the user of language changes. You're
proposing adding content, which I don't think
is appropriate.
GR: Just because the issue is one of usability
doesn't mean that it's not one of accessibility.
CMN: If you can't find a technique for a
checkpoint, that means that the checkpoint may be
poorly phrased. The technique that comes to mind
for me is to insert content that indicates
"Japanese" or "ja". Is what's required here
notification of the language or identification of
the characters. Visually, you indicate the
characters.
DC: Is this a requirement for the UA or the
assistive technology. Can you conflate this into
ensuring that all inherent markup is communicated
to any AT?
JB: In response to Jim's comment, if the markup is
improperly used, what should the UA do?
JT: Another technique - a kind of tool tip that
indicates a language change.
HB: Note that Unicode characters unmarked up may
indicate language change.
IJ: I'd like to get back to the accessibility
issue: what's the priority of this for providing
access to content?
HR: I think it's important to know when the
language changes, not just when rendering is not
possible.
CMN: What's the P1 requirement? As a sighted user,
you recognize the characters used. "BAHASA" is not
an English word, but Malay. They use the same
(Unicode?) characters.
IJ: I would prefer to address explicit markup
only, not Unicode characters unmarked.
DP: I support P1 because it will be impossible for
some people to access content if its not rendered
properly.
Straw poll: P1 - 6
P2 - 6
IJ: I'm relying on WCAG, but I can't say P1 or P2
based on my knowledge.
RS: If you want to support the Guideline, what's
the technique?
WC: Can we split: P1 to notify. P2 to render.
JG: Note that AT can get the information through a
P1 checkpoint already.
JT: This is not a synthesizer information - this
is a user agent issue.
JB: Users need information that content is not
being rendered by the UA. Easy for sighted users,
not as easy for users with other output.
JG: I propose that we leave this checkpoint as a
P1 for now (since P1 in WCAG) and ask for input
during last call.
JB: Sounds reasonable. I think this is an area
that has not been discussed in depth in other WGs.
In terms of accessibility to different languages,
people have not spent as much effort on
this. Let's ask I18N IG for input.
JT: Final word: recall that these checkpoints are
for the general purpose UAs. Who does this help if
you're not sighted?
/* Lunch */
Mickey Quenzer (MQ) Joined meeting
Resolved:
a) P1: Render according to language identification.
b) P3: For identified but unsupported languages,
notify users of changes in language (when configured
to do so).
6) Issue 86
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#86
HR: Risk of conflicting open specifications.
JT: These are WAI Guidelines, why would we talk
about other specifications?
DC: If we broaden the Guidelines unduly, we run
counter to the WCAG (which says use W3C
specifications).
JG: So we wouldn't include something like SAMI?
CMN: The checkpoint about using W3C specs sends a
message. But a UA can render other specs, so the
other checkpoint (7.1) should apply to them.
HB: Note that "supported" is undefined?
IJ: "implemented"?
Resolved: Checkpoints 7.1 and 7.2 ok as is.
Action Ian: Repropose Guideline text.
7) Issue 87
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#87
IJ: Proposed "adjust" instead of "control".
Resolved: Define "control" as "choose preferred
behavior from predefined options".
8) Issue 88
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#88
JT: If you can't select specific elements, do you
have to satisfy the checkpoints where this is
required?
IJ: I think this is right.
ISSUE: Do we need to require UAs to provide a
structured selection mechanism?
/* Demo of Amaya's structured selection mechanism:
hit Escape to navigate up in the tree and modify
the selected content */
IJ:
a) Functionality of structured selection (Not
covered in UAGL).
b) Highlighting of that selection (UAGL covers)
c) Communication of that selection (UAGL covers)
(Is it interpreted as content or as a path?)
d) Functionalities provided based on
selection. (UAGL includes)
JT: I don't think checkpoint 9.4 is for general
purpose user agents.
IJ Proposes:
a) Delete checkpoints that refer to selecting
specific elements (links, tables, forms).
b) Add a checkpoint to require a selection of
mainstream UAs (without specifying structure or
unstructured).
JT: You don't usually select with the keyboard in
graphical browsers today since there's no carat.
MN: In DOM2, every element will be able to be
focussed.
JG: Two issues - the UI issues and what the
underlying technology allows you to do.
Do we want to require UAs to allow (device-independent)
structured selection?
JB: Note - where are we putting checkpoints that
get dropped because they are for ATs?
JG: We don't have a repository for them.
JB: I think we need to preserve them somewhere.
JT: Propose a P3 checkpoint for useful information
on those elements that can be selected.
RS: How would you render (as speech) status
information?
DP: My screen magnifier does this very well in the
status bar.
(List of checkpoints that require a user
selection: 3.2, 6.2, 9.4, 9.5, 9.6, 9.9, 9.10,
9.11, plus proposed table checkpoint from Ian.)
MQ: In the future, there will be other devices
doing "Internet stuff". If you're using a speech
browser over the phone, these functionalities
become more important.
RS: I think ATs should be providing these special
functionalities. The only time it should be
required is when no other means is available
(e.g., when you're browsing over the phone).
JT: "Where am I" function in a small device may be
difficult to activate when there are few keys available.
DB:
a) Browser must not block available of info
b) It would be nice if the UA did these things,
but not a requirement.
c) Configurability in this case is nice.
DP: Has there been thought about a separate
document describing requirements for what ATs
should do with information that's made available
to them?
JB: It would be a great shame if the expertise of
this WG were to evaporate without a trace. If
there's no commitment of the group to follow up on
the AT half of the picture, I have more misgivings
about removing the dependent UA-related
checkpoints.
DP: Delete the checkpoints in question. Put them
along with the impact matrix. Create a Note for
ATs.
DC: Put the AT requirements somewhere else in the
document.
RS: You shouldn't make the UA have to render the
content. What you want to accomplish is to make it
possible for a dependent UA to get at the info.
IJ: But where do you draw the line on
functionality? This has been the project of the WG
for 1 year and a half...
MN: I share a concern about dropping several
checkpoints suddenly. Note that AT developers are
in the business of providing solutions that
mainstream browsers do not. I'd like to see us
raise the bar for mainstream browsers. In mind,
there is no dependent UA. I don't want to put the
AT developers out of business, but I want
mainstream browsers to accomplish the same task.
JB: I like the Note idea.
IJ: I propose we put the AT-related checkpoints
in an appendix in the GL document.
JB: I like this idea.
DB: Re where to draw the line for what should be
required of a mainstream UA? I don't think that's
it's reasonable to ask a graphical UA to render
all information available graphically through
other output means. But they shouldn't block that
information.
DP: In the near future, mainstream browsers will
talk. Need to take that into account.
GR: I agree with Mark and Dave. We should aim for
what's the base functionality of a user
agent. What is the minimum required for getting
information? For communicating to other programs?
I don't perceive this as "raising the bar" but
rather setting up the bar knocked down by
mainstream UAs. All adaptive technology has been
compensatory - functionality that was overlooked.
CMN: I agree with GR, but said with the
W3C-approved lingo. We keep missing this point:
there are ways that mainstream browsers already
achieve the goal we're striving to achieve.
RS: The bar has been raised by the DOM2 - making
the selected element information available in a
platform-independent manner.
GG: I feel like this WG is preaching to the choir.
The groups that really need to make the changes
are not in these proceedings; the effort is theirs.
Publishing this document as a Recommendation will
not suddenly raise the bar. Therefore, I'd put the
emphasis on communicating with other software.
JT: I Propose moving these checkpoints to P3. The
most important checkpoints are P1 and P2.
IJ: Proposed
a) Move dependent-UA checkpoints to an informative
appendix of the Guidelines.
b) Add checkpoint about requiring a selection
(structured or unstructured).
c) People will review the next draft and decide whether
the split is ok.
/* Break */
JB: What if you are an AT developer and you look
into the appendix and see a smattering of
information (i.e., not a complete listing).
GG: Even a bunch of points is useful. I suspect
that AT developers would not be unhappy with a
grab-bag if the points stand on their own.
GR: I propose that the impact matrix should be the
basis of a map to requirements for specific
requirements.
DP: I agree with GR.
DC: If we put information in the appendix, we
might be able to add more content for other
disabilities not currently in the guidelines.
JT: As for point (b), is a selection feasible?
IJ: Yes, Amaya does it, for example.
CMN: Netscape lets you in composer view.
DC: A hack: mouse keys.
JT: But I think that the "natively" requirements
throws that out.
GR: I would like to see Ian's proposal put into
the next draft. Then we ask developers to review
the draft.
Resolved: Adopt Ian's proposal
Action Ian: Put into next draft.
DB: Need clarification of 9.5 that this applies
when there is appropriate markup indicating the
link requires a fee.
DP/JB: User agent is the last line of defense.
/* Tim Lacy of Microsoft joins the meeting */
9) Issue 91: Proposed reformulation of frames checkpoint
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#91
4.12 Allow the user to choose between a frameset or its
alternative supplied by the author.
Note. For example, in HTML, allow the user to
choose between a frameset or a NOFRAMES
alternative. The ability to control frames is
important for users with screen
readers and users with some
cognitive impairments.
GR: What's the priority of the proposed text? I
propose making this a priority 1.
IJ: I agree. Note that this proposal is a
particular case of providing access to alternative
context.
DC: Add "rendering" to the checkpoint text.
JT: NOFRAMES content may not provide an
equivalent alternative.
GR: It's true that many NOFRAMES act as
commercials to go get new browsers. But I think
that's due to no good implementations of the
element.
DC: I think this should be a priority 2 since the
page is not unusable in frame mode. It's more
difficult to use, but not totally unavailable.
CMN: Often the most effective way of making the
content of a frameset available is making it
available in another place. I don't think
contradicts what we're saying.
DB: Why is this one more important than other
similar checkpoints in the document? For example,
does the rendering of images make it impossible to
get at content. (4.1).
JT: I think we can delete 4.12 because of 3.1
GR: Don't replicate the whole document in a
NOFRAMES, use the navigation page as an index to
the main content, and put that in NOFRAMES.
TL: I think that's a good idea - you avoid content
replication.
GR: 4.12 is about access to content but also
navigation. 4.12 bridges two checkpoints (access
to content and navigation).
CMN: I think the navigation point is important and
needs to be covered separately. I agree with deleting
4.12 but ensuring that it's covered (since
commonly done wrong today) clearly elsewhere
(e.g., techniques).
Resolved:
a) Delete 4.12.
b) Mention frames in 3.1 Note on access to
content
c) Put Ian's Note in 8.1 on frame navigation.
9) Issue 92: Proposed reformulation of frames checkpoint
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#92
IJ: Form orientation.
GG: Hotkey access is important.
IJ: Covered elsewhere (G1 and G2)
Resolved: Move this to "AT appendix" (for review).
9) Issue 93:
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#93
IJ: New definition of applicable.
DB: Risk of discouraging UA developers (e.g., for
style sheets) by saying "you can comply more easily
by not implementing a language than by trying to
implement part of it." For instance, if a UA tries
to implement speech but doesn't do everything
perfectly, should they be penalized?
KB: This is related to the issue of browsers that
only comply to a few checkpoints and the others
don't apply. We didn't resolve how to address
that.
DP: We can't force browsers to implement features,
however.
MQ: WebSpeak has a lot better compliance than
other browsers in handing off processes. If we're
talking about browsers needing to handle content
in order to comply with W3C, this is important.
CMN: A UA could try to comply by handing off your
HTML rendering to someone else.
IJ: Seems like a stretch to create a new
technology just to avoid accessibility features.
DB: I think you have to consider the practical
side of taking the guidelines to the developers.
MQ: A number of multimedia players think they will
be able to comply as browsers. WinApp is just a
player, but its accessibility stinks.
KB: I think that for purchasing, in addition to
conformance information, vendors will need to
provide supported feature information.
JB: I agree with Kitch. I think it's also real
life to think that developers may go to lengths to
avoid implementing accessibility features that
seem onerous.
IJ: That sounds like the original proposal + a
requirement to provide information about what
features are supported. But vendors do this anyway
when they advertise their products.
DB: Style sheets benefit accessibility. How to you
reward people who attempt to implement them?
CMN: CSS is the applicable W3C technology for
controlling style. But there's a higher level
requirement elsewhere (independent of style
sheets) to control text size.
IJ: If you support CSS, you satisfy a bunch of
checkpoints immediately.
KB: I'm comfortable with Ian's proposal, but I
think the conformance issue is still complicated.
We need to educate purchasers so that people can
purchase appropriate software to meet the needs of
users.
WC: Once you conform, the rest is marketing. The
purchasing decision is made on relative
functions.
DP: I share KB's concern about marketing.
a) Can we use impact matrix for marketing?
b) Will we keep a database of conforming software?
JB: If this WG doesn't have consensus about a
conformance statement, I don't think the document
is ready to go to last call.
GR: Create a support matrix - show what you will
satisfy by implementing a particular spec.
CMN: Create a checklist ā la the Authoring Tool
Techniques.
http://www.w3.org/WAI/AU/WAI-AUTOOLS-TECHS
JT: In some cases, we don't have much to
say about a particular checkpoint.
/* IJ discusses two structures for techniques
document: semantics-based and list-based */
DB: I think developers will prefer (short) lists.
GR: Amen to what Dick said. Also, the numbering
system used in the techniques document should
match up to the numbering system used in the
guidelines document. Mixing the numbering systems
is confusing.
CMN: One reason we don't have enough techniques is
that we don't get proposals from the WG. In AU,
checkpoint-by-checkpoint techniques list was
conducive to coming up with techniques.
DC: I think it's inappropriate to compare WCAG
Techniques with UA/AU Techniques.
IJ: I hear people arguing that the list-view is
useful. Are people convinced that the thematic
view is not useful?
TL: I want to reinforce that developer thrive on
lists. I also support Ian's proposal above. I
don't think that a development group will *not*
implement a language based on how hard it is to
make it accessible. By the time you get to a
developer, broad decisions have already been
made. In this context, charts and tables (in
techniques document) are crucial.
TL: A common question from the program management
house: what will this cost in test and
implementation time? Management will ask
developers "What will it take to implement 1.1?"
"What will it cost to implement this feature?"
Big thick documents scare off readers. Checklists
would be an inappropriate tool for answering
questions about implementation time. In that case,
there will be need for more information.
HB: Checklist valuable for Q.A. people as well.
To determine whether a checkpoint has been
satisfied.
IJ: This sounds exactly like the Techniques
document.
JT: Techniques are suggestions, but not final
words.
DP: Checklists might even lead to standardization.
HR: Beware of deviating from accessibility
conformance to general quality conformance.
GR: Use the AU Techniques style. But include a
link to the narrative information (which is separate).
DP: I get lost in multi-dimensional spaces easily.
WC: I think the WG should not focus on
techniques. Let the developers come up with the
techniques. I think it's pretentious of this WG
to propose techniques.
CMN: I agree. However, this WG must come up with
at least one technique for each checkpoint. If you
can't come up with a technique, that's
problematic.
RS: I agree with CMN. We should focus on the
guidelines. We can't list all the protocols and
formats in a single table and show which
checkpoints apply (there are too many). You won't
cover all the techniques. So let's finish the
techniques document quickly, and get it out.
However, need to fill in what's missing to
substantiate the guidelines.
IJ: So three issues:
a) Structure of techniques document. I propose to
"flip" it based on WG input today.
CMN: Make the checkpoint the bulk of the
techniques document. Send them off to the
appendix.
Action Tim: Get feedback from MS IE Team on
usability of 5 October Techniques structure.
Compare to Authoring Tool Techniques at
http://www.w3.org/WAI/AU/WAI-AUTOOLS-TECHS/
b) Suggestion to WG:
People can propose "tables" for the Techniques
that help developers by, e.g., listing which
checkpoints must be satisfied for a particular
language.
c) Resolved: Implement Ian's proposal on applicability.
9) Issue 95:
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#95
/* Ian shows W3C Talks as an example of wanting to
select from among available style sheets */
DB: Why distinguish author from user style sheets?
DB: Proposed: Allow the user to select from available
style sheets.
Resolved: Add this checkpoint as a Priority 2.
/* Adjourned 5:38 */
Received on Monday, 11 October 1999 20:49:26 UTC