REF 4.3 needs to be rewritten.

REF  4.3   -  4.3   needs to be rewritten.


 

4.3 seems to have gotten off track someplace along the line.  I think we
have now a combination of a whole bunch of different edits.    This may have
happened when I did the last re-org.  Sorry if that is so.

 

The guideline itself talks about "technologies used for presentation and
user interface support accessibility or alternative versions of the content
are provided that do support accessibility".  This is a good concept and
basically says that if technologies (particularly non-standard technologies)
are used which were not designed to be accessible and are not accessible,
that some other form of the functionality is provided.  Thus, if one wants
to put special controls or scripts or applets or whatever technology into a
page, then that technology needs to be accessible or the same functionality
needs to be provided in a accessible form.

 

This concept isn't really covered anywhere else in the proposal.  The rest
of the proposal specifies pieces of accessibility, such as availability of
text or keyboard operation.  However, there's nothing that actually
precludes the use of a keyboard to carry out tasks that require eye hand
coordination or simultaneous visual tracking, for example.

 

I do not think that this item, therefore, should be deleted, however, many
of the items under it should be dropped.  They don't seem to get at the
problem.

 

For example:

*         Device independence is covered under the keyboard function and
does not need to be repeated here.  

*         Including accessibility features is ambiguous.

*         Having publicly documented interfaces for interoperability is of
no value if it is a one-of-a-kind interface and/or if there is no assistive
technology for it.

*         Etc.

 

I think this one might be summed up with a single, simple success criteria
which is the one which is currently listed as the second success criteria.

 

I therefore suggest that we explore collapsing this entire checkpoint down
to the single success criteria which is number 2 and then having some best
practice or "plus conformance" items below that.

 

The only plus conformance that we have currently that would be useful is
"accessibility conventions of the mark up or programming language (APIs or
specific mark up) are used.

 

The "testing" item could be listed in a best practice, but I would not put
it in a "plus conformance" category since testing with individual pieces of
assistive technology and consumers is very expensive and usually only
involves testing with 1 or 2 popular pieces of AT and testing for only 1 or
2 types of disabilities.  Meaningful accessibility has to be done
systematically, not by post facto test and patch.

 

However, best practice does always include having some sample of people with
disabilities actually try to use the pages in order to test whether or not
your process is any good.  Thus, it would not be a success criteria, but it
would definitely be best practice.