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