/* Loretta reads success criteria and issues */
CS The first sounds like 3 success criteria.
LS Why do you have to avoid deprecated? You can conform to the spec, and older one.
JM But they will be outdated.
LS That will be taken care of in other guidelines, like separate style and presentation. Why do we need that?
GSW I agree. I've had sites targetted at older browsers and they don't handle the newer features.
LGR I think that is the issue - what about backward compatibility.
JM Or explain in the metadata if they have taken a conscious decision to use deprecated elements.
PB Seems like an issue...even if use deprecated they can use to previous specs. So, valid but outdated. Do we want to require the current specs?
JW You could use an earlier version of the spec.
PB Validate to published grammars.
CS Netscape HTML with extensions is full of things that are not accessible.
GSW Other guidelines pick it up.
LS In WCAG 1.0 - says conform to W3C specs. May seem snobbish, but seems very practical. If obscure authoring techs won't pick it up. Making it advisory...we lose that.
LGR Only restricting to W3C misses many other languages.
CS Many other standards bodies.
JW Use widely published specs...related to 4.1
LS but it's become advisory.
GV If we say "use things that are widely avaialable, used with AT, ..." you have to define exactly what that means. Can't be some of the AT, it has to be all of them. That's why we went back to the UAAG.
JW Also checkpoint 4.4 and those issues.
PB Using according to spec means you may or may not be using the accessibility features. Use the accessibility features and use to spec.
JM They are two separate things. If accessibility features are optional but we want to require, should that be in 4.1 or 4.2?
GV The checkpoint is "Use according to spec and include accessibility provisions." Therefore change the checkpoint so we can include appropriate success criteria.
KB Two different checkpoints.
LS I don't think we should require people to use accessibility features. You could have a simple page that is so simple you don't need the accessibility features.
GV Put the word "applicable".
KB If there is another problem, it will be caught, but if you have an option to include a module for accessibility, that's where you
WAC Isn't this what 4.3 is about? Also, using the checkpoints and guidelines - isn't that how to use the accessibilty features?
GV let's take a step back and look at all of the 4's. What are we trying to achieve.
JW 2 or 3 notions under 4, they overlap. ensure interoperability, used to spec so work w/variety of UAs and ATs, backwards compatibility.
GV Interoperability, use according to spec then other people can write things that work with them. then AT - even if you use the spec, may not be accessible. haven't defined work with AT, although UAAG is the best that we have to define that. backwards compatibility also not just backwards compatibility but devices that don't support all of the features. At some point we said we don't expect page authors so that they write the page so that how old and terrible the tech is, it will work with it. there is some responsibility of the author, but also that the user will outfit themselves with tools. there is some limit to going back. that gave us the question, what is the min. tech we expect the user to have?
JW That changes over time. Thus, my proposal re: 4.4.
CS I don't think it is seriously defective.
JM Does anyone?
LGR Compatibility with AT will be an issue.
JM Baseline will also crop up.
CS We need to tackle that.
JW re: 4.2 possible options: reword 4.2 to include accessibility features. or reword 4.3: use accessibility features of techs and do so appropriately. then proper features for user interfaces and UAAG, might become a success criterion. or add an additional checkpoint.
PB It meets the..if the markup conforms to schema/dtd/or other spec. get rid of "use of structural elements...."
CS I would keep that. e.g. in HTML you could have a valid doc that doesn't use h1 elements structurally.
LS Didn't we use to have one... [inaudible]
KB Use H1 for headings is part of spec but not part of schema. Use according to spec is wider than validating. Make it clearer. Emphasize talking about whole spec
PB I agree with that. Then, reduced to 2 points. In favor of dropping deprecated and accessibility features. Unless you make them as a separate bullet point.
JW In any of these, we'd have to write it so that it is applicable to technologies wider than markup languages.
CS We broke it up into markup and api, and an issue for protocols.
BF In terms of 4.2 success criteria, relies on 4.1 - docs have to be publicly available. Is it part of 4.3? What happened last time?
GV 4.1 was removed and replaced by 4.S1. 4.1 was ...
BF Perhaps we need it.
CS Why was it removed?
GV It says "choose techs that support these guidelines" - either it says "follow the guidelines" or it tells you "you need to choose techs that could follow the guidelines, but then you don't need to." Therefore, 4.1 didn't add anything, and the success criteria didn't help either.
CS It seems usable and testable. I'm not sure I agree.
GV a gif violates this. You can use alt-text to make it accessible, but it does not meet any of the specs in 4.1.
CS I'm trying to remember why we brought this into being. Intended to encourage people to use techs whose designer considered technology.
WAC Right, this is about using technologies that have considered accessibility. It replaces "use W3c techs" from 1.0. The success criteria are from an old version of the XML Accessibility Gudielines. Last week didn't think we could require people to do and thus became advisory.
CS Use SVG instead of .gif. More accessible.
LS Backwards compatibility issues.
KB Use only?
CS Choose not use. When evaluating which technologies to use, look at accessibility.
MS Yes, an important requirement.
JM To put success criteria on it will be difficult.
CS Everything we have involves trade-offs.
GV We also want to find what it is that would make pages accessible, rather than what path they should use. "Achieve the following" rather than "use the following." Therefore it is good advice, but if the page is accessible whether they did or not is not the critical piece.
LS 4.S1 - alternate renderings has accessibility. Therefore, haven't we covered.
CS Perhaps it is advisory. However, normative vs advisory is conformance. We talked about modularizing. It could be testable.
GV You could never include unless you selected everything else.
CS not sure 4.2 w/out 4.1 makes sense.
MS I agree completely. You could put into one checkpoint.
CS It was one checkpoint.
JW No one has proposed a substitute for 4.1 that would not be redundant.
CS I could work on it.
GV How resolve if can't use gif?
WAC success criteria make it clear that this applies to markup and apis.
LS However, should use svg instead of gif.
JM Lack of support.
CS HTML and gif meet these requirements.
GV ....
JM The way it is used, in combinations, it can be made accessible. This would apply to other combos.
GV alt-text/longdesc does not provide an equivalent to the info. Text description does not convey the richness of info available in the photo/image, etc. We're not talking about absolute accessibility, we're talking about some level of accessibility.
JW Combinations of technologies - they must together be accessible. Seems similar to "multiple versions of content." Set forth requirements that combinations should satisfy. Either as checkpoint or statement outside of checkpoints.
WAC Believes that is an underlying assumption of all of the checkpoints. HTML is rarely used alone.
CS Collections of technologies working together.
MS Provide an example.
GV If you have created an accessible page, 4.1 and 4.2 are moot. It's accessible so you must have done that. If you did 4.1 and 4.2, but didn't make it accessible, then no value to anyone w/a disability. But if you do 4.1 and 4.2 first, you are more likely to succeed. Therefore, not a checkpoint but a process point. "To make this accessible, start off with selecting technologies...."
CS Web sites are living things. It is an ongoing process. Always adding new functionality, and technology.
JM Even before adding new tech, at beginning of the process, select the right technology.
ASW If someone comes to these guidelines before choose a technology, they need to know what they are.
JM Many people don't consciously choose technologies. They will default to what their tool gives them. They may stay with transitional html or whatever version of acrobat is installed on their computer.
JW Regarding the redundancy question - the issue of interoperability with standards compliance, UA, AT, not sure it's covered by anything in 1-3. You could have something that follows many of the checkpoints in guidelines 1-3 and still be inaccessible.
CS The checkpoints under 4 are at a different level. others are in the code, these are what the code does in the world.
LS We're looking at the guideline as something given to a qa guy. We want to move away from that. Move towards modular conformance. We might have modules in different places in the work flow, at different stages, and for different people (who's doing what). A module for program manager, another for graphics, another for text, etc. We have no reason to assume that the same person will read all of the modules. then we don't have to assume linearality.
JM Are you saying that guideline 4 falls on that account. How could it be retooled?
LS I'm saying 4 is ideal for it.
CS Perhaps the redundancy isn't so critical. In modularized world, there liekly is overlap.
JM I'm less concerned about redundancy than gaps.
GV Each of checkpoints in 4 get at different issues. 4.1 doesn't have anything to do with the guideline - for compatibility and interoperability...it's the only one like this. 4.1 got morphed (from "use w3c techs.") We want something in AT - related to perceivable. We should either find the essence of compatibility/interoperability it goes someplace except under 4.
CS I thought it was saying "choose techs that support interoperability and compatibility."
GV Yes. 4.3 - design interfaces compatible...4.1 is choosing tech...4.3 designing interfaces.
CS 4.3 inside browser, 4.1 inside head.
GV If we do reword it, then if you choose things that are typically interoperable, then they will be able to get at it.
Action CS: rewrite 4.1 - along the lines of, "Checkpoint 4.1 Choose technologies that support interoperability and compatibility." and also include something in 4.2 along the lines of, "Include accessibility provisions where applicable."
JW PB suggested ammendment to 4.2, however what cynthia is doing will incorporate into 4.1.
GV suggest CS look at 4.2 and 4.1 together. "Include accessibility provisions."
JM Use accessibility features when applicable, but what about things such as "tabindex." Could use it, or not.
KB Accesskey.
GV Where applicable. If access feature breaks it, it wouldn't apply there.
JW Backwards compatibility separate from the types of technologies.
GV CS, perhaps the way to do that, write an exception statement, "an exception is where the access features breaks older browsers until..." It drives programmers nuts to see a rule that they can't follow. Please think about success criteria.
WAC and GV will not be there.
JM I have ideas about 3.3 to send out.
JW On agenda for next week.
$Date: 2002/02/21 22:38:17 $ Wendy Chisholm