On the phone: Eugenia Slaydon, Wendy Chisholm, Doyle Burnett, Ben Caldwell, Jason White, Loretta Guarino Reid, Bengt Farre, John Slatin, Lisa Seeman, Matt May, Cynthia Shelly, Lee Roberts
On IRC: MattSEA, bengt, Zakim, Ben, mvittoria, wendy, bazzmann
Roberto Scano, Gregg Vanderheiden, Avi Arditti
jw the success criteria are similar. they use terms such as "device indie". also cover user agent support.
jw when discussing 5.2 decided to restrict to backwards compatibility.
jw another checkpoint that precludes those situations (where UA support does not exist).
jw a success criterion in 5.3 which does that. we had agreed that we wanted to look at the UAAG conformance scheme to see if will work for our needs (in relation to this checkpoint success criterion)
jw is it appropriate to have a single checkpoint, how should it operate?
jw gv has asked if 5.3 is redundant.
wac not sure how apply UAAG to 5.3? thought it was XAG.
jw not only technology, but support for the technology.
jw how do we define what support we need from UAAG apart from backward compatibility.
jw the agreement we reached on 5.2 was that we require that some level of UA support should exist for the content.
jw thus, suggested that 5.3 should handle it.
ls if something is not designed to be accessible, but it is accessible.
ls might be better off using an open standard.
ls often open standard are designed to be accessible.
jw perhaps restrict 5.3 to the issue that 5.2 does not cover. otherwise, leave as is and add another checkpoint.
wac don't see the missing piece. see it covered by 5.2 and 5.4. still not sure how 5.3 fits in?
jw the last part of the SC of 5.3 - are implemented in user agents and/or proxies in the natural language(s) of the content
jw need to clarfiy what 5.3 means.
cs 5.2 was recently added?
jw no, rewritten.
cs not clear on what the problem with 5.3. it seems that it covers different things.
wac have to prove that there is support?
jw as part of the condition (baseline in 5.2), didn't want to allow the case that UA support didn't exist or didn't provide compatibility with assistive techs or other usage scenarios.
jw we didn't want to allow that at minimum level. support for techs you are choosing.
jw thus 5.3 should cover it. if we do cover it there, how define it? use UAAG profiles?
jw other issue, is it redundant?
ls if we don't have redundacy, people say, "i've done all that i can so this is good enough." redundancy prevents that argument.
wac it is not redundant. writing languages is becoming part of the authoring process. wcag ties these pieces together. writing languages is an integral piece.
cs agree that it is needed. it is the first step in building an accessible site.
cs you can tweak angle brackets on a bad technology and it won't help.
js agree. from another angle, the readability angle, we are writing for a wide audience.
js it is important that we are this explicit.
db it needs to stay. rather have redundancy rather than have a gap.
bc agree. important part of the process. you may come to that conclusion on your own, but good to make it explicit.
bf agree.
lgr xml guidelines?
wac if writing xml vocabulary, use XAG. success criteria language came from older version of xag.
cs when i wrote, level 2 criteria on 5.2 didn't exist. not sure they fit there. covered by 5.3. perhaps 2 imp is level 2 of 5.3.
wac standard test for a spec.
cs for a spec, sure. could have single imp that is available.
cs e.g. if an accessibility feature of html 4.01 is implemented only in 1 browser, use it.
ls e.g. accesskey, if used in one but not another, not breaking anything by using it (if only implemented in one browser).
ls if you choose a tech that only imp in one browser, then people can only use that browser. all else can't get it.
cs if foobar browser implements all sorts of features, e.g. aural CSS, it's a separate tech. what if only implemented in one browser? that one instance is really accessible.
ls usable through at least one tech, according to these things.
ls i do use ACSS. no one imps, but i hope one day they will. it can't be a bad thing. it's not breaking it for anyone else.
jw 5.2 defines that it is features that the content relies on to operate.
jw the 2nd level success criteria, these techs have been imped in more than one imp and around for a few versions.
cs i'm not arguing that they shouldn't exist. arguing should be in 5.3 instead of 5.2.
jw the argument was that in 5.2 they are requiring that the tech has been around for a while.
jw 5.3 has a different but similar requirement: the UA must support certain types of usage scenarios - no matter how long they have been around.
jw if you reached 5.2 at level 1, could be using techs that don't have suitable UA support.
cs "natural lang of content" in 5.3 but not 5.2. also "proxy" that could do translation and makes it acceptable.
cs both of those make it easier to meet the criteria, thus why ok with it at level 1.
cs less specific about how many, etc.
jw that's where UAAG came in. do we want to require that one or more (under 5.3) have to meet something in UAAG.
ls you have to. the user has to control the UA content.
ls can user control presentation?
mm that's the plan. a large chunk of the guidelines deals with that.
ls i found a screen reader that you can't actually use if you don't have vision.
cs talking about what the content has to do to comply. when talk about applets, activex controls, etc. the thing that is important is that they can be used via keyboard.
cs i haven't looked at ATAG or UAAG in a while, but not sure it i the same set of requirements.
jw those sorts of requirements exist in UAAG, but apply to imp of UA
wac brings up 5.4.
cs i'm more concerned about things that are rendered by UAs. that they play nice with accessibility OS features.
cs choosing to use foobar plug-in for fooML should play nice with OS.
mm guideline 6 specifically refers to plug-ins.
cs looking at the SC for 5.3 - is that what UAAG says? perhaps the first 4 are pretty much basic s/w accessibility guidelines.
mm it doesn't say it that way but it is contained in there. UAAG guideline 6 says, "..." reads.
cs even if it doesn't meet UAAG and it doesn't have 2 imps, doesn't mean not accessible.
jw that's the case we are intrested in. 5.2 is met at level 1. what are the requirements you meet before you can use the tech. (that's 5.3).
jw what are we requiring of fooMLtech?
ls if making a UA, does not have an interface for every ability, but for a range. if a tech supported by UA, how do we guarantee they are supporting people across the board.
ls there are some UAs created for one groups, others for other groups.
es even if you use a tech that is supposed to be accessible, if you use A in one it works in one UA but not in another.
es if look for it, no way to find those. it takes some trial and error to find what works. shouldn't we help people find those things?
cs probably a job for EO. that list changes over time. it can't be in a normative doc.
jw space in tech dtd.
jw i'm thinking about 5.3, and can think of 2 action items:
jw 1. we have vague discussion about device indie, it's not clear or testable. one approach that could be useful: go through rest of guidelines and look at what requirements do we place on the technology?
jw 2. issue w/last success criterion on 5.3 - something more stringent on techs before use them?
jw clarify the first part and clarify the last part.
zakim, who's here?
cs willing to work on it, but not for 3 weeks.
jw happy to look at first part, in shorter term (next week or two).
jw instead of device indie, support other parts of guidelines...
wac what about a voicexml app? is there a UA?
jw the server app is processing input and output.
cs almost certainly doesn't have device indie event handlers.
wac use keypad alone if can't voice.
cs use tty?
jw what require in terms of what it needs to support, how does that relate to rest of guidelines?
action: jwanswer "what require in terms of what it needs to support, how does that relate to rest of guidelines?"
bc we are talking about combinations of technologies. we can't run one technology at it (5.3). but can the set of techs you are using, meet the guidelines.
bc if one does not meet all the criteria, your combo does. e.g. an alt version.
bc if a new tech that supports accessibility only avail in one UA, don't think we want to preclude authors from using (in combo w/other tech)
db, cs agree
cs a and b need some definition. if device indie in glossary, link to. 'accessibility features' - a list.
jw i think about it, "what we mean is, if the tech include images, audio, multimedia...they together have to support text equivs to cover checkpoint 1.1. 1.2, etc."
jw they need to support structure (for 1.3). go through other checkpoints and identify what you are requiring of the combo of techs.
cs that would be long. could also be useful to have examples of a single tech and a group of tech that meet and dont meet.
db device indie is not on that list.
wac reminds people of the wai-wide glossary.
wac idea is to have definitions in that glossary and pull into WCAG when we generate it.
wac we ought to move forward on that. some discussion has occurred on the xtech mailing list:
jw - ... 2 do we want to say anything more specific about whtat the implementation has to be like
resolved: consensus to keep 5.3
jw reactions?
ls some resources are mentioned, some are fundamental. some are the other extreme, you could do well without having read them.
ls thought the distinction between them was fuzzy. e.g. "how people with disabilities use the web"
ls they a diff kind of doc all together. if people first go there first.
ls it's very much the other way around.
wac variety of roles and variety of documents thus variety of paths through the content.
ls emphasize "rely on these... find others useful."
ls some policy makers who like "accessibility in 10 points" ...
the "Advocate" is only e.g.?
wac "dave is a policy maker. his education is X. he works for Y" then we can keep dave in mind as we move fowrad.
db there were a couple other people who posted separately, hinting to similar circumstances. it's a matter of educating folks. what is laid out, gives info they wouldn't normally have.
js works well to imagine typical people. defining those readers is a good exercise.
jw something designing a policy, they come at various levels. some may be setting major policy, they are likely to go through technical requirements and decide on conformance profile.
jw someone who has an org who wants a policy will benefit more if they have good profiles that they can choose from that are regarded as being good for particular purposes.
jw an issue we had was "will we provide and maintain some example conformance profiles."
jw and the reasons may want to choose one of them. i don't think we have fully covered.
js you mean something like an equivalent of people profile but an organizational profile?
jw no, more like how UAAG uses the term. a conformance profile would say, "this content meets all min level checkpoints, and..."
jw if set a policy, require all content to meet minimum level and which require at level 2 or 3 - that's the info in a policy.
js may be useful to come at it from the different type of organizations and the terms that would be suitable to them.
js "i work for this type of org, these are the type that would be most appropriate."
wac right, some way for people to help them identify themselves (their situation) in the document.
jw right, in a separate document.
jw if using SVG, there are requirements under 1.3 that you can satisfy easily at non-minimum level. if not, much more difficult.
jw based on technologies and what your priorities are - meet at level 3 or 2. an issue w/conformance scheme so can update it - keep separate.
db not only do people who design web pages not know about disability, but they don't know markup language. be beneficial.
action db: come up with a profile.
jw issue about testable assertions in techniques. a dependencey that authoring tools group has on us.
action wac: write more examples of technology-specific testable assertions and the "2 layer" approach.
$Date: 2002/09/27 20:22:27 $ Wendy Chisholm