2 new people today
BC Have worked with Trace for a while.
BF WAAC group a browser for disabled people. Concerned about content of document for symbol users.
JM I saw Giorgio yesterday from UsableNet - they want feedback on their web site.
LGR reads through the 5 criteria. (Refer to LGR's email sent on 22 January 2002)
GV It seems that if you've done the guidelines you must have met this. If you didn't then you chose technologies but you could have and didn't. Someone could later comply. Success criteria seem to be walking back and testing "were you able but didn't follow other guidelines?" Worry that we have some that are specific and some that are general.
LGR It's evaluating the technology not someone's use of it.
JW A history, not a defense, is there were requirements in 1.0 about use of W3C specs and choice of tech. An issue that arose after 1.0 was other techs that would also meet accessibility technologies. This checkpoint tries to generalize the point.
GV If I am serving a page that uses a technology called "Pizzazz" (made-up for example) I could have a link to this and to an accessible page. Could serve it or link to it. In one case I have an accessible page that fails to meet this guidelines in the other I have an inaccessible page, but could serve accessible info. Does "use technologies" mean that all of the techs I've chosen are accessible, or that if I want to I can?
JW A number of people who thought a checkpoint along these lines was a good idea. How would you reword it to avoid the objections just raised? It seems redundant if it asks people to implement the guidelines and doesn't seem to have much effect if the web site has some technology that would apply. The entire site could be provided in that technology.
GV I thought it was a good idea to have this thought there, but 2 things have happened in the meantime: e.g. we have a variety of technologies we're trying to support. Where not accessible include another version on the page, e.g. pictures. Pictures are not accessible unless you provide an alternate form of the picture, i.e. alt-text. Perhaps this isn't a checkpoint but "other pieces of good advice."
JM Do we have a growing list of recommendations like that?
GV We have not started the list yet, but perhaps this is a good place to start.
WAC We don't currently have a 14.1 from 1.0 (if all else fails...) although if we do what gregg says and boil down to elements, then 1.1 and other checkpoints might cover. However, an important piece of 4.1 is that if you are designing your own language, the XML Accessibility Guidelines become techniques for that.
LR If we take this out, then we don't say "build an alternate to flash"
WAC 4.3 also covers this - use technology accessibly.
JW 4.3 success criteria also overlaps with 4.1.
GV A place for notes?
WAC Authoring is likely to include creating languages in the future.
JW Right, the split is not as significant as it used to be.
GV Let's see what conclusions we can draw. Is the checkpoint as written too restrictive or always met?
WAC It does seem informative, but some of the success criteria go into 4.3.
GV Which 4.1 success criteria move to 4.3?
WAC These are from an older version of the XAG. Since 4.3 is "design" part of design could be designing the language. Thus one success criteria could be conform to XAG if designing your own language.
ES If you get this far, then you've already chosen your language.
GV That assumes that the guidelines are ordered based on how someone will go through them. If you do nothing at all, you could provide a text page in the future that could conform.
JW 4.3 does not suffer the same problems as 4.1.
GV If we move it into advisory, then you should use techs that facilitate implementation.
WAC If in success criterion, then not advisory.
GV OK for XML, what about other apps.
WAC Should also include linke to UAAG if designing plug-in or other interface.
JW Info stored w/out info can't put in in transformation. Accessibility can reach into structure of content in a database. On the one hand we cover user interfaces themselves in 4.3, however we haven't covered the other aspect which people may not be aware of.
WAC Good distinction between client-side and server-side. Could capture web services and server-side techniques. We have techniques but no clear point to link to the server-side techniques.
GV advisory like S1.
WAC A checkpoint like S1. The bullets underneath are success criteria.
GV With an if, perhaps.
JW There is always the possibility that my web content might be designed not to deliver to me, but to other content providers and then to the user. Then, how do the guidelines apply to my content even if delivered not directly to users. The answer is that my data format and content itself has to meet accessibility requirements even if they are behind the scenes to someone who constructs the user interface from it. It ought to be captured somewhere.
GV Not sure that is always correct. Images of text that could be changed into text on the fly. Do we want to write a requirement...you already have to provide the requirement, you must have it stored someplace.
WAC The relationships are the requirement. One person may provide the image, the other provide the description. All that needs to happen is to provide the relationship. Then whoever assembles it can pull the pieces together to make something accessible.
JW
WAC Perhaps do server-side techniques to figure out what required before we figure out if this is advisory or not, or what is required or not.
GV Want to go back to idea of S1. "If you server different content for different users then at least..." Some of the points under S1 are too general for success criteria.
JW Perhaps instead of 4.1 need, whether in conformance or special section of the guidelines, clarification of those issues and how content can apply under different circumstances. Does anyone volunteer to do some work on this point?
Action GV and JW: try to draft a checkpoint along the lines of S1.
GV What about 4.3?
WAC ala the minutes from 17 January 2002, PB had 4.2 and KHS had 4.3. I don't have any other comments other than what I've already said.
GV Comments on 4.3?
ASW If using a tech that has the capability of being made accessible, and use it according to spec, but not supported by ATs, have you met the checkpoint? It is capable or already supported.
JW One thing could be to modify slightly, "it uses standard interfaces which offer accessibility and can be supported by ATs"
WAC 3 years ago, if I used tables with headers, scopes, etc. but it was not considered "accessible" although the potential for accessibility was there. Fast forward to 2002, some would consider it accessible because some handle those attributes.
GV If you make up your own interface you should follow UAAG 1.0, that's concrete. When it says, "device independent access must be provided" where's the definition? Or what about "Accessibility conventions are used." is there a reference for that? If we do, then maybe that ought to be the checkpoint. "Device indie are used." then define that. No one can define "compatible with assistive technology."
JW Perhaps take 2 actions: 1 - define or explain what the characteristics are that make an interface accessible (that are not covered elsewhere), 2 - add an advisory that says "in doing this you should strive to make it compatible with as many ATs or make it follow UI and programming conventions that make compatible with as many ATs as possible." The checkpoint appeal to general principles of interoperability.
WAC Have they met the checkpoint?
LR no.
JM No. People need to take whatever measures necessary to make it work.
LGR This reminds me of the "how far back" do you go.
JM I'm talking about current - accomodating the failings of the most up to date version as opposed to Netscape 2.
LGR If there is one AT taht supports the element, would it pass?
ASW There are 2 issues: new technologies, like Java. Robust accessibility API but not AT that really supports it. Other hand, MSAA, use a custom windows control, the AT probably wouldn't work w/out a script to enable it.
ES I ran into this problem b/c I was required to make an accessible PDF form. Everything I've read is that there is not a UA that will handle. It will support it in the future. I did everything I did, but have I met it? As far as I can tell, yes.
LGR There will be bugs in any given implementation.
JW If someone has decided to use a technology, then if they have done it in an accessible way, even if it is not supported by ATs or UAs then it is a good thing to have done. It should be legit for someone to say that due to constraints that's all they can do. It's a question that lies outside of the guidelines. Should be able to distinguish in conformance claim of those instances, we leave the question of what is required morally or good practise out of it.
MM This sounds to me like transitional vs strict implementation of the guidelines. Using a tech that I'm required to use, and I have the opp to hack it up so that things on the decline are able to utilize it rather than thinking forward and coding to the specs, putting onus on developers of ATs and UAs, then more content out there that supports, always code towards future. The content has more permanence than any technology. If you create a spec that rewards the future, have more people pushing forward.
WAC Then need to educate users so they can go to UA and AT devs and tell them what is needed (i.e. conform to UAAG).
GV If we look at 4.3, what is it that we know? what conclusions have we come to? w/4.1, we decided it should move to an advisory. With 4.3 we seem to conclude that we don't want to tell people that they need to be compatible with ATs since we don't mean 1 or 2, but we mean all but we don't have a way for someone to test against all. Therefore, "design to AT conventions" although they haven't been defined. Therefore, do we have an advisory? Move into requirement if and when we can come up with the AT conventions make it a requirement.
WAC I believe this comes from UAAG. It's pretty clear.
GV Is the checkpoint, "You must design user interfaces to be compatible with UAAG."
JW That could do it.
WAC Might be circular reference to UAAG.
GV Keep the last success criterion?
WAC That's our 14.1, if all else fails...therefore think we need to keep it.
GV That could be the only success criteria.
JW 2 success criteria: 1. Conforms to at least level A, 2. OR if not possible, provide the same functionality in an alternative interface that does comply. Might be redundant. Instead perhaps refer to checkpoint that discusses alternate forms.
GV I believe it should be there, it is talking about a particular thing on the page, if you have a custom control.
Action JW and GV: Draft new text for 4.3.
Action Everyone: Look at the comments made on 4.2 and 4.4 before next week and see if similar arguments will apply. Show up with suggestions, e.g. "How about we do X."
Next week's agenda: 4.2 and 4.4, if time cycle back to 3.3 and 3.4.
$Date: 2002/02/15 16:52:33 $ Wendy Chisholm