2.3 - who determines "accessibility" on non-W3C languages

The way 2.3 is worded today, it focuses on the markup language, not the
document, and the standard or spec for that markup language.  Who determines if
the language supported by the tool enables accessibility?  Is it sufficient that
the language, DTD,  etc. have some minor feature that enhances accessibility?

Phill's frustration comment:  The more I try to work on 2.2 and 2.3, the more I
think they are NOT checkpoints, but notes and explanations.  The only checkpoint
that can be in a W3C spec is a checkpoint that only includes W3C specs and any
other non-W3C specs that have been reviewed by the W3C to be determined as
"accessible specs" [Notes of which I know none].  I think we may be mixing the
priority of our desire to have accessible authoring tools with the priority of
the features that make an authoring tool accessible.  See also comment on 2.2 -
definition of "published specification"

Proposal: remove 2.2 and 2.3 as checkpoints because they are not verifiable. 2.1
would be re-worded as "Ensure that markup is generated in accordance with
applicable W3C Recommendations and Notes.  [Priority 2]

Techniques comment:  The FRAMESET example is poor.  FRAMES are part of a W3C
accessible standard.  Many accessible user agents [Lynx, HPR, WebSpeak...] can
handle FRAMES and don't need the NOFRAMES.  Adding title to frame isn't' even
necessary if the content of the frame is an html file since the user agent can
get the title tag contents from the html file that will be loaded into the
frame....  A CSS2 and JavaScript example would be more useful here since they
can be looked at as "creations or extensions" and have relevant accessibility
issues today and into tomorrow.

Most of the 2.2 and 2.3 techniques can remain under the new proposed 2.1

Phill Jenkins

Received on Friday, 1 October 1999 18:53:12 UTC