Re: Last call comments from WCAG working group

Wendy A Chisholm wrote:
> 
> Hello,
> 
> Here are the clarifications you requested.  I am only replying to issues
> that I raised.

My replies start with IJ:
 
> > > 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.

IJ: Ok.
 
> > > 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.

IJ: Cool
 
> > > 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.

IJ: Yes, but does the VM do any more than interpret byte code? Why would
the Java programs not be able to refer to OS functions (that just happen
to be reached through Java). I'm not sure I understand why Java's being
an interpreted language (by a virtual machine) means that there aren't
system conventions to take into account when you program with it.
 
> > > 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.

IJ: I think, then, that we should leave this checkpoint as is today. I
think
that until WCAG has a more complete model to present and request, we
should not
try to add it to UAAG 1.0. (This is fodder for future coordination.)
 
> > > 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).

IJ:  Two comments:

1) I don't believe that the paragraph you quote in 3.2 is meant to apply
to
APIs. It was meant for things like volume control, media players, etc.
that come
with the OS. I think that we should make clearer that we're not talking
about
APIs here.

2) Your proposal is still good advice for browser developers -- work
with 
   AT developers! --  but I wouldn't want to make "standardize APIs 
   when they are otherwise missing" a requirement for this document. 

Thanks Wendy,

 - Ian

-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783

Received on Wednesday, 6 December 2000 00:38:48 UTC