Action Item: Cynthia to review Jason's message and respond
LR: Many authors create a Java applet, and require Internet Explorer.
Would 5.3 or 5.4 prohibit this?
CS: The grey area seems to be if I implemented my functionality via Java and called into another URL to pull in data, is that content or a user agent?
JW: UAAG has a definition of what a user agent is, and it is a much broader definition that people think. Whatever it is, we should be compatible with it. I think the definition is broad enough that it would cover such an applet.
Action: Jason to extract definition from UAAG and post it to the list, with his interpretation.
CS: There will be some techniques that cross technologies, e.g., if
you have flyout menus, there are things you need to do no matter what technology
you use to implement them.
JW: Supposing someone invents an XML language for one of these things, they will have the same issues.
CS: There are also issues that are specific to interactive content that are not an issue for static content. Maybe what we need to do is define guidelines for dealing with interactivity.
JW: Guidelines 2 and 3 are what we have in the area.
CD: But there are things covered in 5 that aren't covered in those sections.
JW: I'm concerned that web content is becoming interactive, and if we don't cover it we'll find ourselves in trouble.
CS: We agree that it needs to be covered.
JW: Is there anything significant that needs to be covered that isn't already addressed?
CS: I'll think about that, too.
JW: If the User Agent is designed to handle it, it is going to work.
CS: If the User Agent is designed to have hooks into the OS accessibility features, then anything you can do, you should be able to do accessibly. We need techniques for how to do that.
JW: Any assistive technology is considered part of the User Agent. If the content accesses those features directly, it still works.
CS: If that's the case, you may be right. That will still be problematic for authors who have a different conception of what a User Agent is, since they think a User Agent is a browser.
(ASWreads definition from User Agent Guidelines)
MM: User Agent is defined to be browsers, media players, and plug ins
CS: and AT, and ...
(ASW reads part of definition of content from UAAG)
JW: The meaning of "content" is up for discussion in a number of settings within WAI.
CS: It still doesn't answer the question of whether a Java applet is content or User Agent?
GV: If it comes from the server, it is a server agent. If you have to install it, it is a User Agent, since it stays after the page goes.
CS: So an applet is content?
GV: If it doesn't stay on your machine, it is content.
CS: Some Active X controls stay on your machine after you leave the page.
(GV and CS discuss security issues around installing controls downloaded as part of page.)
JW: Definition of content is open for discussion. Other groups are interested because they use the term as well. It is supposed to be discussed on the xtech mailing list. Interactive/non-interactive and code/mark-up distinctions don't seem like they are going to be decisive for what is considered content. I still feel it is a question of User Agent support. Issues: content vs user agent, what do we require of user agent support, and what requirements around interactive content need to be covered.
GV: If the server (that is, the page) is providing it, it is an action of the page author and the author is responsible for making it accessible. Another case: the author says you can't use this content unless you use this User Agent, and then the content is only accessible if the User Agent is accessible. Third case: if you are just building to a standard like HTML, and there are accessible User Agents in common use, you can assume that an accessible agent is being used and you meet accessibility by following guidelines. If there are a set of guidelines that you can follow, you can assume that you are accessible if you follow them. But since we will not make guidelines for any technologies that aren't accessible, this means we must point to an accessible browser for each of our technologies.
CS: There is a difference between making a poor guideline for someone else's technology, and making guidelines for a technology that you are responsible for.
GV: It doesn't matter whose technology if the guidelines don't actually make it accessible.
CS: The requirements on the technology documents require that at least the minimum level be addressed.
GV: An interesting point. If we made a clear set of requirements for the checklist documents, and you said that your content checklist conformed to the minimum requirements for checklists, then you passed. You pass this checkpoint if either all your technologies pass or if you link to a User Agent and the User Agent meets the UAAG guidelines. If you provide your own interface, it must meet UAAG guidelines. But I'm concerned that UAAG covers issues that don't make sense for an implemented user interface element.
GV: Is UAAG composed in such a way that you could address only the things that an implemented user interface should cover?
MM: The guidelines themselves have normative exceptions.
GV: Is there anything that would immediately disqualify something I wrote and built into a page?
JW: I don't think the content/software distinction is going to work. I don't think that we will solve this by referring to someone else's definition . A more interesting question is whether there are things that aren't covered by the current guidelines that will affect the accessibility of these things.
GV: If there is technology-specific checklist and you meet it, you don't need to worry about User Agent at all. If there is not a technology-specific checklist, you need to use a technology for which there is a User Agent that meets the User Agent Guidelines.
CS: I just looked up the Microsoft accessibility checklist, and it has 9 items. (Reads list)
GV: At least 4 of those are Windows specific. Which of those would cause the page to be read out loud for blind people?. None of them. These enable screen readers to read the content. But on another platform, you could do all those things and the content still wouldn't be accessible.
JW: We covered a lot of these already.
CS: We might look closely at the keyboard guidelines.
JW: This gets covered in the HTML/XHTML techniques. We should make sure we haven't missed anything.
GV: Which item in UAAG would we not have to cover? If we don't need it for custom user interface items, why does UAAG need it?
JW: You are relying on features of the User Agent, not replacing the User Agent.
GV: But no part of the function of the AT is in the User Agent requirements. So what part of the User Agent requirements don't we need?
CS: Assume for the sake of argument that we weren't linking to UAAG. What are we missing that exists in UAAG?
MM: UAAG doesn't deal with interfaces so much as the individual widgets themselves. The applet is both the User Agent and the content.
GV: Wouldn't UAAG and WCAG have to be satisfied then?
MM: When looking at design issues for cognitive disabilities, that won't be something UAAG defines. But looking at the accessibility of each widget in Java, that will be something UAAG addresses. There is some overlap, but in the more abstract elements of WCAG. If you design a user interface widget that is inscrutable but has an inscrutable accessibility hook, you may not have a UAAG problem but you may have a WCAG problem.
??: From the standpoint of the end user, if I come to a page with a Java applet, both the applet and what it displays are the content of the page. So WCAG applies all the way around.
JW: The issue in that case is what requirements would there be for the accessibility of that applet that aren't currently covered by WCAG, and should any missing aspects be added in or should we be referring to the UAAG to import the requirements by reference.
MM: Guideline 2 of UAAG addresses accessibility of content as defined by WCAG. If you did UAAG, you did WCAG.
CS: I need guidelines if I am writing a Java applet or Active X control. Where do I go to find out how to make it accessible.
MM: Java accessibility layer of Java environment
CS: WCAG can't point to them
MM: and neither can UAAG
CS: So if I want to make sure my complicated web site is compliant with WCAG, how do I know? It seems like we need to add more interactive pieces.
JW: From what Cynthia read, it doesn't seem like there was much, if anything, that was missing.
CS: We are light on guidance for interactivity, e.g., keyboard activated dialogs and menus.
JW: This brings us to guideline 2. What is missing that is not technology-specific?
CS: It seems like there isn't a separate normative document that covers interactive interfaces. UAAG has some coverage of this, but maybe not everything we want to talk about.
JW: A group of us needs to analyze what still needs to be covered.
CS: Add a couple of things, or triple the size of our document?
JW: We probably only triple the size if we start adding technology-specific information.
CS Action: compare WCAG to Windows accessibility guidelines
GV: What in UAAG would not apply to custom built interface elements built into the content. It needs to be clear that if it is built into the content, it is not a user agent, but user agent issues apply.
MM Action: compare UAAG to WCAG interactive user interface needs
JW: A thought: a checklist conforms to the guidelines, and content conforms to the checklist. So content conforms indirectly to the guidelines.
GV: We can't do that. We can't say that conformance is based on a checklist unless the checklist is normative.
CS: We can say that third party checklist must meet our conformance standards.
CS: We can't tell people that they aren't accessible if they use anything but W3C technology.
GV: We can say they aren't compliant in that case, but we don't want to. We don't want to say that using W3C is necessary for meeting these guidelines (even though it is a good strategy). The checklists are just easy ways of figuring out how to meet the guidelines. The checklists aren't mentioned in the guidelines.
CS: If someone creates some new technology and they publish techniques for how to make it accessible, the author can use this information to argue why he satisfies the checkpoints.
GV: Either you follow a checklist or in some other way demonstrate that you satisfy the checkpoints. We'll have to think about this.
$Date: 2003/02/07 00:28:19 $ Loretta Guarino Reid