Re: Proposed matrix of which WCAG checkpoints are the responsibility of the authoring tool

In reading this, I am more convinced that it is the responsibility of
individual tool developers to develop their own matrix, and of the working
group to identify techniques which can be used by developers. Clearly there
can be better and worse implementations which staisfy the relevant
checkpoints, and factors such as the type of tool, the size of the
application, and others will have an influence on how a particular developer
chooses to approach a particular checkpoint. Some specific examples where I
might disagree with Phill's analysis for WCAG P1 and P2 checkpoints include:

(by WCAG checklist order, as the original table is)

In general, 5.2 addresses the User interface of the tool. Since that is
created in the first instance at least by the developer, I fail to see how it
is possible for it to be a responsibility of the author to ensure that WCAG
P1 practices are obvious. (I can see that strategies for doing so may not
exist in certain types of tool) Stricly speaking 5.2 does not apply to any
except WCAG P1 practises, although it is nice to see Phill has thought about
techniques for doing this in lower priority cases.

WCAG 2.1 Ensure information conveyed by colour is available without colour.

  This strikes me as separating structure from presentation, for example by
including the requirement in documentation about how to use colour, and in
the way that colours are applied. In checking, if a color span is
consistently used with no other identifying information it would sugest to me
a shared responsibility that the tool can alert the author to.

WCAG 4.1 identify changes in natural language

  This is a shared responsibility insofar as it is possible for a tool to
detect a change in language (which is a question of the state of the art and
the size of the tool).

6.1 Organise content to flow without style sheets

  The biggest problem I know of in this regard is markup generated by a
particulatr tool which uses CSS positioning and allows the order to be a
complete mess. I would argue that it is a tool responsibility in case of ATAG
1.3 and at least a shared responsibility in ATAG 4.1 (a suitable technique is
to provide a linear rendering of the content, unstyled).

14.1 Use clear language

  MS WOrd already provides checking for this using a couple of different
techniques readability indexing, spellchecking, marking up sentences that are
getting very long, etc. Some of these things are in other tools too.

1.5 Replace ASCII art with image or explain it.

  This would go in my both basket for ATAG 4.1 - there are cases where ASCII
art can be recognised, for example border layouts. Again, there are tools
that recognise carious "emoticons" - smileys and such, and can substitute
them (this is a case of macro programming in many cases)

11.4 If all else fails provide an alternative version

  Several developers have suggested doing this automatically as a
technique. It is not always easy to do, but given appropriate content it can
be a good answer, particularly where authors are going to use things like
horrible pixel-level table-based design in a version of their page when the
tool is capable of doing it accessibly.

3.2 and 3.3 - use headers, use list structures

  I would put these substantially in the Tool's lap for ATAG 4.1 - it is not
too difficult to test if Headers are badly nested, and if you try to import a
list marked with asterisks into Word it tries to make it a formal list
(although it oesn't have a decent list structure in its HTML output it does
in its own binary representation).

4.2 expand acronyms

  The tool has an important role to play in making it possible to do this (eg
in HTML prompt for a title attribute) and recognise things that look like
ACRNYMS - this is similar to spellchecking.

12.3 Divide large blocks of information

  This is a both - see my comments on WCAG 14.2 above.

13.3 Provide a site map

  There are already tools that do this!

13.4

  This can be tested by tools.

10.3 Provide a linear alternative for side-by-side layout

  This is a trivial task for tools. See comments on WCAG 11.1 above

6.5 Provide an alternative to dynamic framed pages

  This can be tool tested, and authors should be guided to do so (ATAG 3.2)

10.2 label form controls

  This seems an obvious one for ATAG 3.2 to be covered by the tool.

6.4 Make scripts keyboard-accessible

  In HTML this is a trivial case of putting appropriate triggers in (for an
onclick add a keyboard-based one, for example). Likewise, it is easily
tested.  ( grep "onclick" | grep -v "key" will give unix nerds a rough idea)

7.3 Avoid movement in pages

  Both

8.1 Make scripts and applets accesible

  For example, use Java Swing and provide hooks for the JAVA Self VOicing
Kit, rather than using the AWT and providing nothing.

9.3 Specify logical event handlers

  see 6.4 above, only more so.

Cheers

Charles McCN

On Fri, 3 Dec 1999 pjenkins@us.ibm.com wrote:

  
  
  This is a table of which WCAG checkpoints are the responsibility of the
  authoring tool, which are the author/users, and some are identified as
  both, meaning that the tool has some responsibility and the author has the
  rest in meeting the checkpoint.
  
  In doing the matrix, I noticed that two of the checkpoints did NOT really
  apply well to all of the WCAG checkpoints, namely:
  "3.1 Prompt the author for alternative information...
  "3.2 Help the author create structured content and separate it...
  
  Please review my definition of the legend and how I applied them in the
  matrix.
  
  It is even more clear to me that this level information, "which checkpoints
  are the responsibility of the tool",  is needed.
  
  P.S. This "data table" is not triple-AAA compliant, but it will work well
  with HPR...
  (See attached file: ATAG-WCAG.htm)
  
  Regards,
  Phill Jenkins,
  

--Charles McCathieNevile    mailto:charles@w3.org  phone: +61 409 134 136
W3C Web Accessibility Initiative                    http://www.w3.org/WAI
21 Mitchell Street, Footscray, VIC 3011,  Australia (I've moved!)

Received on Monday, 6 December 1999 01:48:17 UTC