Roberto Scano, Gian Sampson-Wild, Jason White, Loretta Guarino Reid, Wendy Chisholm, Paul Bohman, Lee Roberts, Andi Snow-Weaver, Cynthia Shelly, Bengt Farre, Avi Arditti, Kerstin Goldsmith
Gregg Vanderheiden, John Slatin, Doyle Burnett, Eric Velleman
Issue: What if something is designed so that it ONLY works on a device for which there is no Assistive Technology. Can the content be "accessible" if it meets the guidelines but only runs on a device for which there is no Assistive Technology and therefore cannot be accessed? Do we cover this somewhere?
resolved: list this as an issue. might be handled by WAC's action item concerning baseline UA. don't handle in current draft. ok to move forward as is.
defn: A keyboard interface is the point where the application accepts any
input that would come from the keyboard (or optional keyboard).
detailed enough? possible to do w/out being os specific?
resolved: adopt this proposal. list issue in bugzilla.
action: bc pull together pieces for 1.5 and propose to list. insert flags for issues.
Lee worked on this from a devs point of view.
question: how provide guidelines for interactive?
already saying use well documented apis.
but doesn't mean that you'll use it accessibly.
where does uaag refer to wcag?
question: remove ref to UAAG?
a sample example: UAAG is a car and WCAG is the internal accessories... WCAG cannot goes without UAAG, but UAAG can work without WCAG :)
resolved: don't remove ref to uaag. it gives ua a good structure for stating our assumptions about user agent support. however, we should be able to state in a way that someone doesn't have to read UAAG to understand (but can if they want to).
also, uaag and wcag are a part of the same project (WAI) and they must have references
question: do we want to eliminate 5.4?
question: how do other applications like java, pdf, flash fit into UAAG
for example, flash is an object that could have an alternative version
how do you get in idea that if you can't get custom content accessible, provide alternative if we remove 5.4?
5.3 is somehwat focused on XML but a lot of the ideas could be generalized
implication is that we've covered a number of issues around server-side content by focusing on what the final product looks like
lr signs up to work on server-side techniques.
proposal: remove 1e
could point to uaag and declare profile.
http://www.w3.org/WAI/GL/WCAG20/#wcag-possible-lang
UA usually take care of e, not always.
activex control. uses os functions.
if use os, then crossed the line into UA
java calling windows accessibility stuf.
point E is inside also 5.4...
"are implemented in UAs" - put in b?
b says "include accessibility features..." later it is using them.
xml includes accessibility features, those maek use of OS features.
suggestion for point 1b: "include accessibility features in the natural language(s) of the content" so we can remove point 1e
action: wac ask ian where activex controls live. wcag or uaag?
action: cs rewrite 5.3 by next week.
resolved: wording already adopted in current draft.
diff between feature and benefit.
e.g., cc/pp.
http://www.webopedia.com/TERM/f/feature.html
feature= A notable property of a device or software application.
action: lr write use case about company creating an app that uses word and excel. we can use to help us determine what is in and out of scope for WCAG 2.0.
resolutions:
"available"? If accessibility features are not available, can I use the
technology or not?
is it confusing to leave in protocol even if we don't have an example of one that has accessibility features?
confusing or forward looking?
forward looking.
4.1 - new proposal. not many comments. can we put latest proposal into next draft?
the clarity of explanations were getting less clear. perhaps go back (i.e., leave out parantheses?)
action: avi make edits to 4.1 (get rid of parantheses).
proposed: big elephants discussion
$Date: 2003/02/28 23:33:34 $ Wendy Chisholm