Re: Last call comments from WCAG working group

Hello,

Here are the clarifications you requested.  I am only replying to issues 
that I raised.

> > 4. Section 1.2 should refer to AERT rather than ATAG.  AERT is being
> > incorporated into ATAG-TECHS.
>
>I don't see any references to ATAG in section 1.2 [1]. There
>is a reference to AERT already. The only reference to ATAG10
>is in the "Related resources" section.
>
>[1] http://www.w3.org/TR/2000/WD-UAAG10-20001023/#scope

Typo in our comments. It should refer to ATAG rather than AERT.  AERT is 
being incorporated into ATAG-TECHS and thus not a document on its own 
anymore.  Ref to ATAG is appropriate, ref to AERT is not, other than as 
historical.

> > If these
> > do not use standard devices correctly, what else am I to use?
>
>We discussed this as part of issue 323 [3] at our recent
>face-to-face meeting. We resolved to "Change 1.2 to require
>implementation of available standard accessibility APIs, and
>where these APIs do not provide required functionality (by
>this document), support standard device APIs."  Would this
>address your issue?

yes, that should do it.

> > 12. Several checkpoints refer to using operating system conventions.  What
> > about a user agent that is written in Java?
> > In that case it is up to the
> > virtual machine to use the system conventions.
>
>Is that entirely true? I thought that the virtual machine's
>job was to interpret byte code, but that you could write
>programs to do whatever you want. I am not a Java
>programmer...

The virtual machine interprets byte codes into something the OS can 
understand.  The VM is operating system specific.

> > 16. Is there a way to make checkpoint 2.6 more general, perhaps to allow
> > for standardized classes or standardized elements?  Null alt-text is just a
> > way to standardize saying, "this is decorative."  The WCAG WG has been
> > discussing others.  Could we leave this more open or do you want to be very
> > specific?
>
>Can you provide examples of other cases?

We have shied away from this issue, but it keeps coming up so I expect 
we'll have to do something with it some day:  standardizing class names to 
provide semantic meaning to an element or group.  For example, labeling a 
table as layout or something like that.  The null alt-text is basically a 
way to say "ignore this image since it is purely decorative."  Some people 
want to add similar "semantics" to other objects.

Using the MAP element is a way to group navigation links, fortunately, this 
idea was incorporated into the X/HTML spec.

> > 33. I think section 3.2 will encourage multiple solutions rather than
> > pushing people to better the "standard."  In other words, instead of
> > "foundation classes" on Linux that support accessibility, we'll end up with
> > several sets of classes that will end up driving AT
> > developers crazy.
>
>Need more information.
>
>Section 3.2 is about using OS features as part of
>conformance claims. I'm not sure I understand your
>comment. Also, do you have an alternative conformance scheme
>to suggest? Please note that the Working Group has worked
>extremely hard to come up with this conformance scheme and I
>don't think the WG will readily change it without a very
>concrete counter-proposal.

It was my understanding of this section that if a standard accessibility 
API does not exist for an operating system, that the developer must create 
and use their own.  This would cause an AT developer to learn a different 
API for each browser on a platform that did not have an accessibility API.

<blockquote>
Developers are encouraged to adopt operating system conventions and 
features that benefit accessibility to meet the requirements of this 
document. However, if these features are not accessible, developers must 
provide an alternative accessible solution.
</blockquote>

For example, say the NewWebOS (fictional) does not have any operating 
system conventions and features that benefit accessibility.  Browsers Y and 
X run on NewWebOS and want to conform to UAAG 1.0.  These browsers use the 
system's paint methods.  These methods draw text pixel by pixel.  What is 
the alternative accessible solution that the browsers provide?  They will 
have to write their own API for an AT to use to get text.  If X and Y do 
something different, AT developer Z will have to learn both of their methods.

This happens today and thus why JAWS works better with IE than with 
Netscape - JAWS has more access to what IE knows and does.  I thought one 
of the goals of encouraging the use of system APIs is that the AT 
developers will only need to learn the standard API and not all of the home 
grown variations.

In the case where an OS does not have standard APIs with accessibility 
features we need to encourage developers to push the OS for a solution 
rather than create their own.  Perhaps until the OS provides a solution 
they can provide a kludge,but in that case they should also work carefully 
with AT developers.

Thus, I propose (and this needs work):
<blockquote>
Developers are encouraged to adopt operating system or language conventions 
and features that benefit accessibility to meet the requirements of this 
document. However, if these features are not accessible, developers must 
work with assistive technologies on that platform (or language) to provide 
an alternative accessible solution and should work with the operating 
system manufacturer or other third parties to create accessibility 
conventions and features for that OS (or standard API -  in the case of Java).
</blockquote>

I don't know how browser manufacturers will feel about this, but I do think 
we should rely on the OS or language as much as possible to provide 
standard features that ATs can hook into.  That's what Active Accessibility 
and the Java Accessibility APIs were all about.

If you can find another way to clarify this or if you don't think it needs 
clarification, I'm fine with that.  But this was my interpretation 
(or  misinterpretation, as the case might be).

Thank you,
--wendy
--
wendy a chisholm
world wide web consortium
web accessibility initiative
madison, wi usa
tel: +1 608 663 6346
/--

Received on Tuesday, 5 December 2000 23:01:37 UTC